From nobody Thu Sep 10 14:52:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E611B3D3B for ; Thu, 10 Sep 2015 14:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB7kBoGqR4K5 for ; Thu, 10 Sep 2015 14:51:58 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B221B3D19 for ; Thu, 10 Sep 2015 14:51:58 -0700 (PDT) Received: by iofb144 with SMTP id b144so77923896iof.1 for ; Thu, 10 Sep 2015 14:51:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Egd4m5fWbBVMvTrN5WZhpA30f1/wgpOvXjtyFweZyOU=; b=B3VH9Spdpi4OkNDj1QKOeHDptnDGvHgp9yhicf3c3UPrZ17NTDPVP1hSGv0iDLZn1A wrudB6rFEXl2BuTLSKuXSRm0PB2lyhcu+qIZO22do8yCnZqAuXmmeUDBXzH/1H/8DgXV Uis7SOmBtwY126Q2up9Cxa7QmaGm62cYPdqtuF0wuHDf5YDl6g5DZqQsdXlfWWS6kn2J rxjTK42r0i2p8lrTVfugrdVDfhbhLLlyBhCQTxspGAPuAW3g1dsCPejlrisoUBW8r1Bz ke2iRiZj/rmBTmU4BMJUmsDdnsI67VLRegLG6sGsSprbIfE/+XdVtn5PMWz6aOywyYFr 7ILQ== X-Gm-Message-State: ALoCoQn1sWLu6AjsV7TuGWDjqzUHZ6G+OcEYkwVaOejn3HG1pfsgjR6nAd0Dwc5qwHtdBt40WLSP MIME-Version: 1.0 X-Received: by 10.107.41.211 with SMTP id p202mr50359002iop.132.1441921917896; Thu, 10 Sep 2015 14:51:57 -0700 (PDT) Received: by 10.50.91.8 with HTTP; Thu, 10 Sep 2015 14:51:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Sep 2015 14:51:57 -0700 Message-ID: From: Jeremy Palenchar To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1141f38ab5e83b051f6b9b8f Archived-At: Cc: SCIM WG Subject: Re: [scim] Proposed resolution for externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 21:52:01 -0000 --001a1141f38ab5e83b051f6b9b8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am resuming work on my SCIM client and have a comment relevant to this email. I thought it best to reply here instead of starting a new thread. Please let me know if you would prefer I start a new thread. I would very much like to suggest that the Service enforce uniqueness on the [externalID] per client tenant. Here is the scenario: I have a user in my client system that is provisioned into multiple SCIM Services. I also set [externalID] =3D myLocalID for each User. I keep a mapping in my client of the user to his [id] in each Service. I keep the mapping so that every time I want to do an update I do not need to search the Service by [externalID] to get the Service [id] before PUTing the update using Service\User\[id]. Everything works fine as long as the mapping information remains intact in my system. I can ADD and PUT changes all I want. My concern comes if the local mapping store is lost or corrupted. In this case, I may try to ADD a resource when I should be doing an Update (Client doesn't know the user already exists). In my perfect world, the Service would enforce uniqueness on [externalID] and prevent me from creating a duplicate user in their Service. In this way I could fail gracefully and call back with an Update for the existing user instead of creating a duplicate. Thoughts? -Jeremy On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt wrote: > WG Members, > > Morteza and I had a good talk on the phone on today=E2=80=99s informal WG= call (we > did not have quorum), I think we may have a good proposal on externalId f= or > your consideration. It does not address everyone=E2=80=99s needs but it a= ddresses > the concerns about externalId within the scope of our charter which is > provisioning. > > Below is some modified text for the externalId attribute. > > It keeps the definition the same, but makes clear who gets to assign the > value (besides an arbitrary SCIM client). > > Please see the text below, the changes are in UPPERCASE. > > Proposed text for externalId: > > externalId > A String that is an identifier for the resource as defined by > the PROVISIONING client. The > "externalId" may simplify identification of the > resource between PROVISIONING client and service provider by > allowing > clientS to use a filter to locate the resource with AN IDENTIFIER > FROM THE PROVISIONING DOMAIN > , obviating the need to store a local mapping between > the PROVISIONING DOMAIN'S identifier of the resource and the > identifier used by > the service provider. Each resource MAY include a SINGLE non-empty > "externalId" value. The value of the "externalId" attribute is > always issued by the PROVISONING client and MUST NOT be specified b= y > the > service provider. The service provider MUST always interpret the > externalId as scoped to the client's tenant. While the server > does not enforce uniqueness, it is assumed that the value's > uniqueness is controlled by the client setting the value. See > Section 9 for additional considerations regarding privacy. > > > If any one has any objections or amendments, please let the group know by > the end of the week. > > I propose to post this change to the draft early next week. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1141f38ab5e83b051f6b9b8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am resuming work on my SCIM client and have a comment re= levant to this email.=C2=A0

I thought it best to reply h= ere instead of starting a new thread. Please let me know if you would prefe= r I start a new thread.

I would very much like to = suggest that the Service enforce uniqueness on the [externalID] per client = tenant.

Here is the scenario:

=
I have a user in my client system that is provisioned into multiple SC= IM Services.=C2=A0=C2=A0I also set [externalID] =3D myLocalID for each User= . I keep a mapping in my client of the user to his [id] in each Service. I = keep the mapping so that every time I want to do an update I do not need to= search the Service by [externalID] to get the Service [id] before PUTing t= he update using Service\User\[id].

Everything work= s fine as long as the mapping information remains intact in my system. I ca= n ADD and PUT changes all I want. My concern comes if the local mapping sto= re is lost or corrupted.

In this case, I may try t= o ADD a resource when I should be doing an Update (Client doesn't know = the user already exists).=C2=A0

In my perfect worl= d, the Service would enforce uniqueness on [externalID] and prevent me from= creating a duplicate user in their Service. In this way I could fail grace= fully and call back with an Update for the existing user instead of creatin= g a duplicate.


Thoughts?
=
-Jeremy



On Wed, Oct 1, 2014 at 11:4= 7 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
WG Members,=

Morteza and I had a good talk on the phone on today=E2= =80=99s informal WG call (we did not have quorum), I think we may have a go= od proposal on externalId for your consideration. It does not address every= one=E2=80=99s needs but it addresses the concerns about externalId within t= he scope of our charter which is provisioning.

Below is = some modified text for the externalId attribute.

<= div>It keeps the definition the same, but makes clear who gets to assign th= e value (besides an arbitrary SCIM client).

Please= see the text below, the changes are in UPPERCASE.

Proposed text for externalId:
<= div style=3D"margin:0px;font-size:11px;font-family:Menlo">externalId
<= div style=3D"margin:0px;font-size:11px;font-family:Menlo">=C2=A0 =C2=A0 =C2= =A0 A String that is an identifier for the resource as defined by the=C2=A0= PROVISIONING client.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 "externalId" may simplif= y identification of the=C2=A0
=C2=A0 =C2=A0 =C2=A0 resource between PROVISIONING clien= t and service provider by allowing=C2=A0
=C2=A0 =C2=A0 =C2=A0 clientS to use a filter = to locate the resource with AN IDENTIFIER FROM THE PROVISIONING DOMAIN
=C2=A0 =C2=A0 = =C2=A0 , obviating the need to store a local mapping between
=C2=A0 =C2=A0 =C2=A0 the = PROVISIONING DOMAIN'S identifier of the resource and the identifier use= d by
=C2=A0= =C2=A0 =C2=A0 the service provider.=C2=A0 Each resource MAY include a SING= LE non-empty
=C2=A0 =C2=A0 =C2=A0 "externalId" value.=C2=A0 The value of the= "externalId" attribute is
=C2=A0 =C2=A0 =C2=A0 always issued by the PROVISO= NING client and MUST NOT be specified by the
=C2=A0 =C2=A0 =C2=A0 service provider.=C2= =A0 The service provider MUST always interpret the
=C2=A0 =C2=A0 =C2=A0 externalId as = scoped to the client's tenant.=C2=A0 While the server
=C2=A0 =C2=A0 =C2=A0 does = not enforce uniqueness, it is assumed that the value's
=C2=A0 =C2=A0 =C2=A0 uniqu= eness is controlled by the client setting the value.=C2=A0 See
=C2=A0 =C2=A0 =C2=A0 Se= ction 9 for additional considerations regarding privacy.

If any one has any objections or amendments= , please let the group know by the end of the week.=C2=A0

I propose to post this change to the draft early next week.

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


--001a1141f38ab5e83b051f6b9b8f-- From nobody Thu Sep 10 18:09:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFC71B321A for ; Thu, 10 Sep 2015 18:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KgBDfvudHQW for ; Thu, 10 Sep 2015 18:09:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513E71B4080 for ; Thu, 10 Sep 2015 18:09:51 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8B19oPd010197 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Sep 2015 01:09:50 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8B19nWL017096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2015 01:09:50 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8B19ntw024674; Fri, 11 Sep 2015 01:09:49 GMT Received: from [25.89.102.100] (/24.114.22.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Sep 2015 18:09:47 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-1113C498-AE72-466A-ABC7-FDC43826B750 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Thu, 10 Sep 2015 18:09:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: <95F75355-03F8-4F47-811C-EC9E3FA233EB@oracle.com> References: To: Jeremy Palenchar X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: SCIM WG Subject: Re: [scim] Proposed resolution for externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 01:09:54 -0000 --Apple-Mail-1113C498-AE72-466A-ABC7-FDC43826B750 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Externalid is to allow a client to set an id unique in its own domain.=20 It may not be true that externalid is unique at the sp. If the sp forced uni= queness on this attribute it would cause bigger problems for many clients be= cause they would be unable or unwilling to change the value that they are pl= acing in externalid. which is already unique to them.=20 A better approach is if the client can choose a naturally globally unique va= lue like a guid or find a second key to establish the sub-domain of users wh= ere externalid is unique. Eg email.value ew "@example.com" Phil > On Sep 10, 2015, at 14:51, Jeremy Palenchar wrote: >=20 > I am resuming work on my SCIM client and have a comment relevant to this e= mail.=20 >=20 > I thought it best to reply here instead of starting a new thread. Please l= et me know if you would prefer I start a new thread. >=20 > I would very much like to suggest that the Service enforce uniqueness on t= he [externalID] per client tenant. >=20 > Here is the scenario: >=20 > I have a user in my client system that is provisioned into multiple SCIM S= ervices. I also set [externalID] =3D myLocalID for each User. I keep a mapp= ing in my client of the user to his [id] in each Service. I keep the mapping= so that every time I want to do an update I do not need to search the Servi= ce by [externalID] to get the Service [id] before PUTing the update using Se= rvice\User\[id]. >=20 > Everything works fine as long as the mapping information remains intact in= my system. I can ADD and PUT changes all I want. My concern comes if the lo= cal mapping store is lost or corrupted. >=20 > In this case, I may try to ADD a resource when I should be doing an Update= (Client doesn't know the user already exists).=20 >=20 > In my perfect world, the Service would enforce uniqueness on [externalID] a= nd prevent me from creating a duplicate user in their Service. In this way I= could fail gracefully and call back with an Update for the existing user in= stead of creating a duplicate. >=20 >=20 > Thoughts? >=20 > -Jeremy >=20 >=20 >=20 >> On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt wrote: >> WG Members, >>=20 >> Morteza and I had a good talk on the phone on today=E2=80=99s informal WG= call (we did not have quorum), I think we may have a good proposal on exter= nalId for your consideration. It does not address everyone=E2=80=99s needs b= ut it addresses the concerns about externalId within the scope of our charte= r which is provisioning. >>=20 >> Below is some modified text for the externalId attribute. >>=20 >> It keeps the definition the same, but makes clear who gets to assign the v= alue (besides an arbitrary SCIM client). >>=20 >> Please see the text below, the changes are in UPPERCASE. >>=20 >> Proposed text for externalId: >>> externalId >>> A String that is an identifier for the resource as defined by the P= ROVISIONING client. The >>> "externalId" may simplify identification of the=20 >>> resource between PROVISIONING client and service provider by allow= ing=20 >>> clientS to use a filter to locate the resource with AN IDENTIFIER = FROM THE PROVISIONING DOMAIN >>> , obviating the need to store a local mapping between >>> the PROVISIONING DOMAIN'S identifier of the resource and the ident= ifier used by >>> the service provider. Each resource MAY include a SINGLE non-empt= y >>> "externalId" value. The value of the "externalId" attribute is >>> always issued by the PROVISONING client and MUST NOT be specified b= y the >>> service provider. The service provider MUST always interpret the >>> externalId as scoped to the client's tenant. While the server >>> does not enforce uniqueness, it is assumed that the value's >>> uniqueness is controlled by the client setting the value. See >>> Section 9 for additional considerations regarding privacy. >>=20 >>=20 >> If any one has any objections or amendments, please let the group know by= the end of the week.=20 >>=20 >> I propose to post this change to the draft early next week. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail-1113C498-AE72-466A-ABC7-FDC43826B750 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Externalid is to allow a client to set= an id unique in its own domain. 

It may not b= e true that externalid is unique at the sp. If the sp forced uniqueness on t= his attribute it would cause bigger problems for many clients because they w= ould be unable or unwilling to change the value that they are placing in ext= ernalid.  which is already unique to them. 

A better approach is if the client can choose a naturally globally unique= value like a guid or find a second key to establish the sub-domain of users= where externalid is unique. Eg email.value ew "@example.com"

Phil

On Sep 10, 2015, at 14:51, Je= remy Palenchar <jeremy@palenchar.= net> wrote:

I am resuming work on my SCIM client and have a comment relevant to this= email. 

I thought it best to reply here instead of s= tarting a new thread. Please let me know if you would prefer I start a new t= hread.

I would very much like to suggest that the S= ervice enforce uniqueness on the [externalID] per client tenant.
<= br>
Here is the scenario:

I have a user i= n my client system that is provisioned into multiple SCIM Services. &nb= sp;I also set [externalID] =3D myLocalID for each User. I keep a mapping in m= y client of the user to his [id] in each Service. I keep the mapping so that= every time I want to do an update I do not need to search the Service by [e= xternalID] to get the Service [id] before PUTing the update using Service\Us= er\[id].

Everything works fine as long as the mappi= ng information remains intact in my system. I can ADD and PUT changes all I w= ant. My concern comes if the local mapping store is lost or corrupted.
=

In this case, I may try to ADD a resource when I should b= e doing an Update (Client doesn't know the user already exists). 
=

In my perfect world, the Service would enforce uniquenes= s on [externalID] and prevent me from creating a duplicate user in their Ser= vice. In this way I could fail gracefully and call back with an Update for t= he existing user instead of creating a duplicate.

<= br>
Thoughts?

-Jeremy



On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt <phil.hunt@oracle.com&= gt; wrote:
WG Members,

Morteza and I had a good tal= k on the phone on today=E2=80=99s informal WG call (we did not have quorum),= I think we may have a good proposal on externalId for your consideration. I= t does not address everyone=E2=80=99s needs but it addresses the concerns ab= out externalId within the scope of our charter which is provisioning.
Below is some modified text for the externalId attribute.
=

It keeps the definition the same, but makes clear w= ho gets to assign the value (besides an arbitrary SCIM client).
Please see the text below, the changes are in UPPERCASE.
<= div>
Proposed text for externalId:
exte= rnalId
 = ;     A String that is an identifier for the resource as defined b= y the PROVISIONING client.  The
      "externalId" may simplify= identification of the 
      resource between PROVISIONING client a= nd service provider by allowing 
      clientS to use a filter to lo= cate the resource with AN IDENTIFIER FROM THE PROVISIONING DOMAIN
      , o= bviating the need to store a local mapping between
      the PROVISIONING= DOMAIN'S identifier of the resource and the identifier used by
      the= service provider.  Each resource MAY include a SINGLE non-empty
<= div style=3D"margin:0px;font-size:11px;font-family:Menlo">    &nbs= p; "externalId" value.  The value of the "externalId" attribute is
    &n= bsp; always issued by the PROVISONING client and MUST NOT be specified by th= e
  &nb= sp;   service provider.  The service provider MUST always interpre= t the
 =     externalId as scoped to the client's tenant.  While the s= erver
 =     does not enforce uniqueness, it is assumed that the value's
   =   uniqueness is controlled by the client setting the value.  See<= /div>
   = ;   Section 9 for additional considerations regarding privacy.

If any one has any objections or a= mendments, please let the group know by the end of the week. 

I propose to post this change to the draft early next week.<= /div>

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


= --Apple-Mail-1113C498-AE72-466A-ABC7-FDC43826B750-- From nobody Fri Sep 25 16:36:01 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA01A9245; Fri, 25 Sep 2015 16:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bLW0C-d9qFo; Fri, 25 Sep 2015 16:35:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 017161A9239; Fri, 25 Sep 2015 16:35:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9ADDF18380A; Fri, 25 Sep 2015 16:34:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150925233454.9ADDF18380A@rfc-editor.org> Date: Fri, 25 Sep 2015 16:34:54 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, scim@ietf.org, rfc-editor@rfc-editor.org Subject: [scim] RFC 7642 on System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 23:36:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7642 Title: System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements Author: K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan Status: Informational Stream: IETF Date: September 2015 Mailbox: kepeng.lkp@alibaba-inc.com, phil.hunt@oracle.com, vumip1@gmail.com, tonynad@microsoft.com, zachary.zeltsan@gmail.com Pages: 19 Characters: 38759 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-scim-use-cases-08.txt URL: https://www.rfc-editor.org/info/rfc7642 DOI: http://dx.doi.org/10.17487/RFC7642 This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements. This document is a product of the System for Cross-domain Identity Management Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 25 16:36:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0041A92BA; Fri, 25 Sep 2015 16:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kwrQb8cc5tw; Fri, 25 Sep 2015 16:36:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BD6681A92E4; Fri, 25 Sep 2015 16:36:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 61D35187E46; Fri, 25 Sep 2015 16:35:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150925233506.61D35187E46@rfc-editor.org> Date: Fri, 25 Sep 2015 16:35:06 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, scim@ietf.org, rfc-editor@rfc-editor.org Subject: [scim] RFC 7643 on System for Cross-domain Identity Management: Core Schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 23:36:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7643 Title: System for Cross-domain Identity Management: Core Schema Author: P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Status: Standards Track Stream: IETF Date: September 2015 Mailbox: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com Pages: 104 Characters: 180665 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-scim-core-schema-22.txt URL: https://www.rfc-editor.org/info/rfc7643 DOI: http://dx.doi.org/10.17487/RFC7643 The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. This document is a product of the System for Cross-domain Identity Management Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 25 16:36:40 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A51A9248; Fri, 25 Sep 2015 16:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAiy60Z9kqm8; Fri, 25 Sep 2015 16:36:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 36D181A92F2; Fri, 25 Sep 2015 16:36:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9296618380A; Fri, 25 Sep 2015 16:35:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150925233523.9296618380A@rfc-editor.org> Date: Fri, 25 Sep 2015 16:35:23 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, scim@ietf.org, rfc-editor@rfc-editor.org Subject: [scim] RFC 7644 on System for Cross-domain Identity Management: Protocol X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 23:36:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7644 Title: System for Cross-domain Identity Management: Protocol Author: P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore Status: Standards Track Stream: IETF Date: September 2015 Mailbox: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, morteza.ansari@cisco.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com Pages: 89 Characters: 170460 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-scim-api-19.txt URL: https://www.rfc-editor.org/info/rfc7644 DOI: http://dx.doi.org/10.17487/RFC7644 The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. This document is a product of the System for Cross-domain Identity Management Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 25 19:00:44 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51C01ACE3C for ; Fri, 25 Sep 2015 19:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pdXHLJc5CfI for ; Fri, 25 Sep 2015 19:00:40 -0700 (PDT) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425AA1ACE37 for ; Fri, 25 Sep 2015 19:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1443232839; bh=4cT6cXh2pzaTBh7A0MUmaCQEBrcNkE/ZAWvtV5dzBT4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Pa5JjoALnYvTCVtjA/DQlhC2LeqzaaIyjQshUhQF5nxxtZYGxKqrHtJysAasReJ41FQC3mLI2pgdO8uJrhDTgVPKfNK8tFpk0Z5nSb6k7d3MpLG2SyWqP+AXJJJ22jRB8H5iZazCeZDF2+HKZHsPa/A6I9MetCHCqZAo9ooAR60HgSDSkFsqGP2o1BqC+XFMc4ewtq0FdnMRJAPnbYXnIjiPOGO7m7oVRep3vMKKgFlcsUYeTK/L6/gmymUodDNK0W92/sUOd7RnTRlEgATh89V7ItACd1qC/LcKJ09TmMc9fqSOXq0esCu2MNa65/HDdzkEa+lZgAzLNN1O9hgneg== Received: from [98.139.215.143] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2015 02:00:39 -0000 Received: from [98.139.215.228] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2015 02:00:39 -0000 Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 26 Sep 2015 02:00:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 136642.7726.bm@omp1068.mail.bf1.yahoo.com X-YMail-OSG: pLnwESwVM1mYVnqaRh22.ksuQSrVZzjM9sAT_LsQm_tt1s6VNGOpbM544IzXv9z BnAq6wmWUqenVzXT2aZpqxV1mKrZqLjxvzppPk0rSI5AaLp8w6W3sOsd4elKhghEjolbm_3UzMQU prNJJ1lDLvK4ZPHyvpwXUkMN7R1vrDKxFZlqFJF0WjgtoVkTy0qv9z2.5LqLPyYI.fA9fwqlusFi FmikxV6rFzIsW2eGNOtIlux0BWK5rHaLG73fKYhh5iDnqJwC_UAOjBRMOhUkuiOfhi4WYLRzsxDp jhslM_HHRBGISH4IYL0pE_UcP3Ak4_Z0Wr0khrS8vQgmRqVGEVA9D9M7bI5PTFcM7Stghr1vPmLn 9HvR9mcA.KRwSBhdgwwCBB9JDZEPpdYWAFZTSqRYAc4F3yfSVUM9aHg7xrk5YyVizkDQz5Gt_UHA 004hC8JwJpwPZqxh4R_5zOxl4v1xBHxzLuv8pX6pCKZd.UHEc4Zxxm5rQp6HFmGsNfOVA_rE9MCE i_pG34.TUtTrBBgDp_B002RGngrbrDUt_Us75rqLNJ.6zWdjBtQ-- Received: by 76.13.27.6; Sat, 26 Sep 2015 02:00:38 +0000 Date: Sat, 26 Sep 2015 02:00:38 +0000 (UTC) From: Bill Mills To: "rfc-editor@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Message-ID: <45108023.1177053.1443232838228.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150925233523.9296618380A@rfc-editor.org> References: <20150925233523.9296618380A@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1177052_1578969049.1443232838221" Archived-At: Cc: "drafts-update-ref@iana.org" , "scim@ietf.org" Subject: Re: [scim] RFC 7644 on System for Cross-domain Identity Management: Protocol X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 02:00:43 -0000 ------=_Part_1177052_1578969049.1443232838221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well done on all 3!=20 On Friday, September 25, 2015 4:40 PM, "rfc-editor@rfc-editor.org" wrote: =20 A new Request for Comments is now available in online RFC libraries. =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7644 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 System for Cross-dom= ain Identity Management:=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proto= col=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 P. Hunt, Ed., =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 K. Gr= izzle, M. Ansari, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E. Wa= hlstroem, C. Mortimore =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 Standards Track =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 IETF =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 September 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 phil.hunt@yahoo.com,=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kelly= .grizzle@sailpoint.com,=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 morte= za.ansari@cisco.com,=C2=A0=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 erik.= wahlstrom@nexusgroup.com,=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cmort= imore@salesforce.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 89 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 170460 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 None =C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-scim-api-19.tx= t =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc= -editor.org/info/rfc7644 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dx.doi.o= rg/10.17487/RFC7644 The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios.=C2=A0 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.=C2=A0 SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. This document is a product of the System for Cross-domain Identity Manageme= nt Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestion= s for improvements.=C2=A0 Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the= =20 standardization state and status of this protocol.=C2=A0 Distribution of th= is=20 memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see =C2=A0 https://www.ietf.org/mailman/listinfo/ietf-announce =C2=A0 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unles= s specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_Part_1177052_1578969049.1443232838221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well done on all 3!



On Friday, September 25, 2015 4:40 PM, "rfc-editor@rfc-editor.org" = <rfc-editor@rfc-editor.org> wrote:


A new Request for Comments is now available in on= line RFC libraries.

       
    &n= bsp;   RFC 7644

        Title:   =   System for Cross-domain Identity Management:
    &nbs= p;               Protocol
  &nb= sp;     Author:    P. Hunt, Ed.,
    &nbs= p;               K. Grizzle, M. Ansari,<= br>                    E.= Wahlstroem, C. Mortimore
        Status:  &nbs= p; Standards Track
        Stream:    IE= TF
        Date:      September 2015=
        Mailbox:    phil.hunt@yahoo.co= m,
                  &= nbsp; kelly.grizzle@sailpoint.com,
   =                 morte= za.ansari@cisco.com, 
           = ;         erik.wahlstrom@nexusgr= oup.com,
                &n= bsp;   cmortimore@salesforce.com
    &= nbsp;   Pages:      89
        C= haracters: 170460
        Updates/Obsoletes/SeeAlso:=   None

        I-D Tag:    draft= -ietf-scim-api-19.txt

        URL:    =     https://www.rfc-editor.org/info/rfc7644

    &= nbsp;   DOI:        http://dx.doi.org/10.17487/RFC7644
The System for Cross-domain Identity Management (SCIM) specification<= br>is an HTTP-based protocol that makes managing identities in
multi-dom= ain scenarios easier to support via a standardized service.
Examples inc= lude, but are not limited to, enterprise-to-cloud service
providers and = inter-cloud scenarios.  The specification suite seeks
to build upon= experience with existing schemas and deployments,
placing specific emph= asis on simplicity of development and
integration, while applying existi= ng authentication, authorization,
and privacy models.  SCIM's inten= t is to reduce the cost and
complexity of user management operations by = providing a common user
schema, an extension model, and a service protoc= ol defined by this
document.

This document is a product of the Sy= stem for Cross-domain Identity Management Working Group of the IETF.
This is now a Proposed Standard.

STANDARDS TRACK: This document spe= cifies an Internet Standards Track
protocol for the Internet community, = and requests discussion and suggestions
for improvements.  Please r= efer to the current edition of the Official
Internet Protocol Standards = (https:/= /www.rfc-editor.org/standards) for the
standardization state and st= atus of this protocol.  Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
= To subscribe or unsubscribe, see
  https://www.ietf.org/mail= man/listinfo/ietf-announce
  https://mailman.rfc-ed= itor.org/mailman/listinfo/rfc-dist

For searching the RFC series,= see https:= //www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.= org/rfc.html

Requests for special distribution should be address= ed to either the
author of the RFC in question, or to r= fc-editor@rfc-editor.org.  Unless
specifically noted otherwise = on the RFC itself, all RFCs are for
unlimited distribution.


T= he RFC Editor Team
Association Management Solutions, LLC


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


=
------=_Part_1177052_1578969049.1443232838221-- From nobody Mon Sep 28 11:58:14 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688571B2B9E for ; Mon, 28 Sep 2015 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oShD-RXB-qo for ; Mon, 28 Sep 2015 11:58:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFFD1B2B9D for ; Mon, 28 Sep 2015 11:58:10 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8SIw9BZ020350 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Sep 2015 18:58:10 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8SIw9Th018870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2015 18:58:09 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8SIw4TS028938 for ; Mon, 28 Sep 2015 18:58:09 GMT Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Sep 2015 11:58:04 -0700 From: Phil Hunt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 28 Sep 2015 11:58:03 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [scim] Discovery support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 18:58:12 -0000 It=E2=80=99s now Monday after completion of the SCIM RFCs and I have = already received a new enhancement request. BTW thanks to everyone in = the WG for all your efforts! The request is to define discovery for SCIM. For example using the = Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033). For example, a SCIM client may send the following query: GET https://www.example.com/.well-known/scim For which the server might respond with a URL to the appropriate SCIM = server and path to the server root (e.g. "profile.example.com/scim=E2=80=9D= ). In a more complex version with a webfinger (RFC7033) query: GET = https://www.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40exam= ple.com& rel=3Dscim-profile Which responds: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json { "subject" : "acct:bob@example.com", "links" : [ { "rel" : =E2=80=9Cscim-profile", "href" : "https://www.example.com/sciim/Users/bob-id" } ] } Overall, I see a few different use-cases: 1. A SCIM client simply wants to know where the SCIM Profile service is = for a specific domain (e.g. tenacy.example.com). 2. A SCIM client might be looking for a user=E2=80=99s profile service. = So it asks example.com where is phil.hunt@acme.com? This would be a = WebFinger style query based on the well-known endpoint. The same = WebFinger query could also return the OIDC endpoints as well as the SCIM = endpoints for the user. This may be useful for cases where service = providers have multiple tenancies and there is a need to have a generic, = tenancy neutral lookup service. 3. A SCIM client that has the service endpoint for a SaaS service (e.g. = CRM, HCM, Finance) may be looking for the provisioning endpoint and the = ResourceType and schemas relevant to the application. For example, a = client that wants to provision to a User to a Finance system, wants know = where the Finance app provisioning endpoint is. It could be an Finance = SCIM endpoint or it may a profile service endpoint. Questions: A. Are there members of the WG interested in this? B. =46rom a protocol standpoint, it should not matter whether a client = is talking to SCIM that is deployed in front of a business application = (like CRM, Finance), vs. SCIM as a general User profile service. = However, due to possible difference in the higher-level logic of the = client, would it be important to distinguish between say = =E2=80=9Cscim-provisioning=E2=80=9D and =E2=80=9Cscim-profile=E2=80=9D = as distinct types of services? If so, what do we think defines that = difference? Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com From nobody Mon Sep 28 12:37:08 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0241B2C16 for ; Mon, 28 Sep 2015 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKkrPu6XgAzj for ; Mon, 28 Sep 2015 12:37:05 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579641B2C15 for ; Mon, 28 Sep 2015 12:37:05 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so135817556obb.0 for ; Mon, 28 Sep 2015 12:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UtGYmtswTEkzKFOybhQJOR2VR9/6csYOhoTCyMofT7Q=; b=yyQ4H4HJ/qq428ROSWfxVLmRrt9Ls6UdJAxfHFGHaufoqTwFJtVK3yN+vwfqbGrShZ /SdG4qRiNbnuNaB8CrZA4BB/g86AJGco7thILVEG7dYkWqVLTpii4rnDsg4xyUD7dUid kklUzPENNg23QynpujybmFnbD/Ra4aKSNE8CF4q9x6JXapSKktLHcw9FB9NDDZHb7pF0 2NSearOcRXjHpS8FCeV5KUpfzhwIkurEvba0PSOXEPnLFYJHZRJ88kWwKK/08NbfkqSm AUaVpcC5bnRHAaxKD76WflNa5HGrZ9MHpU2dtgGW5NOEdFbuFwKhzIkQiELEL7/8QydX IrPA== MIME-Version: 1.0 X-Received: by 10.182.224.163 with SMTP id rd3mr11685007obc.61.1443469024759; Mon, 28 Sep 2015 12:37:04 -0700 (PDT) Received: by 10.202.174.21 with HTTP; Mon, 28 Sep 2015 12:37:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Sep 2015 12:37:04 -0700 Message-ID: From: Chuck Mortimore To: Phil Hunt Content-Type: multipart/alternative; boundary=089e013a211c7717240520d3d2ae Archived-At: Cc: SCIM WG Subject: Re: [scim] Discovery support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:37:07 -0000 --089e013a211c7717240520d3d2ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We're interested, in the service discovery aspect. Less so on the profile discovery / webfinger On Mon, Sep 28, 2015 at 11:58 AM, Phil Hunt wrote: > It=E2=80=99s now Monday after completion of the SCIM RFCs and I have alre= ady > received a new enhancement request. BTW thanks to everyone in the WG for > all your efforts! > > The request is to define discovery for SCIM. For example using the > Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033). > > For example, a SCIM client may send the following query: > > GET https://www.example.com/.well-known/scim > > For which the server might respond with a URL to the appropriate SCIM > server and path to the server root (e.g. "profile.example.com/scim=E2=80= =9D). > > In a more complex version with a webfinger (RFC7033) query: > > GET > https://www.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40exa= mple.com& > rel=3Dscim-profile > > Which responds: > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Content-Type: application/jrd+json > > { > "subject" : "acct:bob@example.com", > "links" : > [ > { > "rel" : =E2=80=9Cscim-profile", > "href" : "https://www.example.com/sciim/Users/bob-id" > } > ] > } > > > Overall, I see a few different use-cases: > > 1. A SCIM client simply wants to know where the SCIM Profile service is > for a specific domain (e.g. tenacy.example.com). > > 2. A SCIM client might be looking for a user=E2=80=99s profile service. = So it > asks example.com where is phil.hunt@acme.com? This would be a WebFinger > style query based on the well-known endpoint. The same WebFinger query > could also return the OIDC endpoints as well as the SCIM endpoints for th= e > user. This may be useful for cases where service providers have multiple > tenancies and there is a need to have a generic, tenancy neutral lookup > service. > > 3. A SCIM client that has the service endpoint for a SaaS service (e.g. > CRM, HCM, Finance) may be looking for the provisioning endpoint and the > ResourceType and schemas relevant to the application. For example, a > client that wants to provision to a User to a Finance system, wants know > where the Finance app provisioning endpoint is. It could be an Finance > SCIM endpoint or it may a profile service endpoint. > > Questions: > > A. Are there members of the WG interested in this? > > B. From a protocol standpoint, it should not matter whether a client is > talking to SCIM that is deployed in front of a business application (like > CRM, Finance), vs. SCIM as a general User profile service. However, due t= o > possible difference in the higher-level logic of the client, would it be > important to distinguish between say =E2=80=9Cscim-provisioning=E2=80=9D = and =E2=80=9Cscim-profile=E2=80=9D > as distinct types of services? If so, what do we think defines that > difference? > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --089e013a211c7717240520d3d2ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're interested, in the service discovery aspect. =C2= =A0 Less so on the profile discovery / webfinger =C2=A0=C2=A0

On Mon, Sep 28, 2015 at 1= 1:58 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
It=E2=80=99s now Monday after completion of the S= CIM RFCs and I have already received a new enhancement request.=C2=A0 BTW t= hanks to everyone in the WG for all your efforts!

The request is to define discovery for SCIM. For example using the Well-kno= wn mechanism (RFC5785) and potentially WebFinger (RFC7033).

For example, a SCIM client may send the following query:

GET=C2=A0 https://www.example.com/.well-known/scim

For which the server might respond with a URL to the appropriate SCIM serve= r and path to the server root (e.g. "profile.example.com/scim=E2=80=9D).

In a more complex version with a webfinger (RFC7033) query:

GET https://ww= w.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40example.com&= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rel=3Dscim-profile

Which responds:
=C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0Access-Control-Allow-Origin: *
=C2=A0 =C2=A0 =C2=A0Content-Type: application/jrd+json

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"subject" : "acct:bob@example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"links" :
=C2=A0 =C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : =E2=80=9Cscim-pr= ofile",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"href" : "https://www.example.com/sciim/Users/bob-id"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0}


Overall, I see a few different use-cases:

1.=C2=A0 A SCIM client simply wants to know where the SCIM Profile service = is for a specific domain (e.g. tenacy.example.com).

2.=C2=A0 A SCIM client might be looking for a user=E2=80=99s profile servic= e.=C2=A0 So it asks example.com where is phil.hunt@acme.com?=C2=A0 This would be a WebFinger style query based = on the well-known endpoint. The same WebFinger query could also return the = OIDC endpoints as well as the SCIM endpoints for the user.=C2=A0 This may b= e useful for cases where service providers have multiple tenancies and ther= e is a need to have a generic, tenancy neutral lookup service.

3.=C2=A0 A SCIM client that has the service endpoint for a SaaS service (e.= g. CRM, HCM, Finance) may be looking for the provisioning endpoint and the = ResourceType and schemas relevant to the application.=C2=A0 =C2=A0For examp= le, a client that wants to provision to a User to a Finance system, wants k= now where the Finance app provisioning endpoint is.=C2=A0 It could be an Fi= nance SCIM endpoint or it may a profile service endpoint.

Questions:

A. Are there members of the WG interested in this?

B. From a protocol standpoint, it should not matter whether a client is tal= king to SCIM that is deployed in front of a business application (like CRM,= Finance), vs. SCIM as a general User profile service. However, due to poss= ible difference in the higher-level logic of the client, would it be import= ant to distinguish between say =E2=80=9Cscim-provisioning=E2=80=9D and =E2= =80=9Cscim-profile=E2=80=9D as distinct types of services?=C2=A0 If so, wha= t do we think defines that difference?

Thanks,

Phil

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

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

--089e013a211c7717240520d3d2ae-- From nobody Mon Sep 28 13:44:37 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A71B32F9 for ; Mon, 28 Sep 2015 13:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7XoPGn_TkfV for ; Mon, 28 Sep 2015 13:44:33 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6CC1B2DA5 for ; Mon, 28 Sep 2015 13:44:33 -0700 (PDT) Received: by ioii196 with SMTP id i196so190021722ioi.3 for ; Mon, 28 Sep 2015 13:44:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Td//GtmiSiud/qYEIvZZNmAY4Dc7MhlJIYtvbPN7NZM=; b=W8uPTn/ZERHYfmlMcJVXUl7SvKzVX6+JyQy4ANTCIJlg4obrR/+eqs1TljGWGZirOs UcNMaw2LrfVg41VDdSrCwYqtlPSRZu5gDENBeZ7twZ32Nf/G0JZoRY5DWYngkgDRaxO7 n9oW28pe0mWfVtqFse/eqVrEot8Hd4o5ui2ZhgQBiaLd4pl4Qu5skH3TTrE6CXhFleI2 SfykEt3+GAgdxEgA+gv9tHy101X4J+Zi0YHjYdksmOwiiA2DqhiG6AkIoWenQAUxE0ic UCV74FvTdGDay20i+C4jLfT/O8rDXDzQq2fTbbP3SV5Ii31nSNTbJY3qCsCM13qRxP5T N09g== X-Gm-Message-State: ALoCoQmZHfkhgnpWL5szQlyGjFVzrhUil2MTe495HY4nFWARgfqRBfPthfGPDI6QlKpCA7UqEPjT MIME-Version: 1.0 X-Received: by 10.107.137.69 with SMTP id l66mr22122417iod.60.1443473073004; Mon, 28 Sep 2015 13:44:33 -0700 (PDT) Received: by 10.50.91.8 with HTTP; Mon, 28 Sep 2015 13:44:32 -0700 (PDT) In-Reply-To: <95F75355-03F8-4F47-811C-EC9E3FA233EB@oracle.com> References: <95F75355-03F8-4F47-811C-EC9E3FA233EB@oracle.com> Date: Mon, 28 Sep 2015 13:44:32 -0700 Message-ID: From: Jeremy Palenchar To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113ecb8ac2aa1a0520d4c3f3 Archived-At: Cc: SCIM WG Subject: Re: [scim] Proposed resolution for externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 20:44:36 -0000 --001a113ecb8ac2aa1a0520d4c3f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil, Missed your earlier reply. Thank you for your response. I am suggesting that the Service Provider should enforce externalID uniqueness per tenant / login-id. In preparing my response, I found the following text in section 6.2 of the current specification: o The externalId, defined by the client, is required to be unique ONLY within the resources associated with the associated Tenant. This is precisely, the functionality I am expecting. However, I cannot find anything in the protocol / schema section of the specification that would require this behavior on the part of a Server. For completeness and disambiguation of the spec I suggest we add something in the Protocol and / or Schema sections that would require a Server to enforce uniqueness of the External ID per Tenant. Thank you for your consideration, -jeremy On Thu, Sep 10, 2015 at 6:09 PM, Phil Hunt wrote: > Externalid is to allow a client to set an id unique in its own domain. > > It may not be true that externalid is unique at the sp. If the sp forced > uniqueness on this attribute it would cause bigger problems for many > clients because they would be unable or unwilling to change the value tha= t > they are placing in externalid. which is already unique to them. > > A better approach is if the client can choose a naturally globally unique > value like a guid or find a second key to establish the sub-domain of use= rs > where externalid is unique. Eg email.value ew "@example.com" > > Phil > > On Sep 10, 2015, at 14:51, Jeremy Palenchar wrote: > > I am resuming work on my SCIM client and have a comment relevant to this > email. > > I thought it best to reply here instead of starting a new thread. Please > let me know if you would prefer I start a new thread. > > I would very much like to suggest that the Service enforce uniqueness on > the [externalID] per client tenant. > > Here is the scenario: > > I have a user in my client system that is provisioned into multiple SCIM > Services. I also set [externalID] =3D myLocalID for each User. I keep a > mapping in my client of the user to his [id] in each Service. I keep the > mapping so that every time I want to do an update I do not need to search > the Service by [externalID] to get the Service [id] before PUTing the > update using Service\User\[id]. > > Everything works fine as long as the mapping information remains intact i= n > my system. I can ADD and PUT changes all I want. My concern comes if the > local mapping store is lost or corrupted. > > In this case, I may try to ADD a resource when I should be doing an Updat= e > (Client doesn't know the user already exists). > > In my perfect world, the Service would enforce uniqueness on [externalID] > and prevent me from creating a duplicate user in their Service. In this w= ay > I could fail gracefully and call back with an Update for the existing use= r > instead of creating a duplicate. > > > Thoughts? > > -Jeremy > > > > On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt wrote: > >> WG Members, >> >> Morteza and I had a good talk on the phone on today=E2=80=99s informal W= G call >> (we did not have quorum), I think we may have a good proposal on externa= lId >> for your consideration. It does not address everyone=E2=80=99s needs but= it >> addresses the concerns about externalId within the scope of our charter >> which is provisioning. >> >> Below is some modified text for the externalId attribute. >> >> It keeps the definition the same, but makes clear who gets to assign the >> value (besides an arbitrary SCIM client). >> >> Please see the text below, the changes are in UPPERCASE. >> >> Proposed text for externalId: >> >> externalId >> A String that is an identifier for the resource as defined by >> the PROVISIONING client. The >> "externalId" may simplify identification of the >> resource between PROVISIONING client and service provider by >> allowing >> clientS to use a filter to locate the resource with AN IDENTIFIER >> FROM THE PROVISIONING DOMAIN >> , obviating the need to store a local mapping between >> the PROVISIONING DOMAIN'S identifier of the resource and the >> identifier used by >> the service provider. Each resource MAY include a SINGLE non-empt= y >> "externalId" value. The value of the "externalId" attribute is >> always issued by the PROVISONING client and MUST NOT be specified >> by the >> service provider. The service provider MUST always interpret the >> externalId as scoped to the client's tenant. While the server >> does not enforce uniqueness, it is assumed that the value's >> uniqueness is controlled by the client setting the value. See >> Section 9 for additional considerations regarding privacy. >> >> >> If any one has any objections or amendments, please let the group know b= y >> the end of the week. >> >> I propose to post this change to the draft early next week. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > --001a113ecb8ac2aa1a0520d4c3f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil,

Missed your earlier reply. Thank = you for your response.

I am suggesting that the Se= rvice Provider should enforce externalID uniqueness per tenant / login-id.= =C2=A0

In preparing my response, I found the follo= wing text in section 6.2 of the current specification:

= 
 o  The externalId, defined by the client, is req=
uired to be unique
      ONLY within the resources associated with the associated Tenant.

This is precisely, the functionality I am expecting. =
However, I cannot find anything in the protocol / schema section of the spe=
cification that would require this behavior on the part of a Server.=


For comple=
teness and disambiguation of the spec I suggest we add something in the Pro=
tocol and / or Schema sections that would require a Server to enforce uniqu=
eness of the External ID per Tenant.

Thank you for your considerat=
ion,

-jeremy
On Thu, Sep 10, 2015 at 6:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Externalid is to allow a client to set an id uni= que in its own domain.=C2=A0

It may not be true th= at externalid is unique at the sp. If the sp forced uniqueness on this attr= ibute it would cause bigger problems for many clients because they would be= unable or unwilling to change the value that they are placing in externali= d. =C2=A0which is already unique to them.=C2=A0

A = better approach is if the client can choose a naturally globally unique val= ue like a guid or find a second key to establish the sub-domain of users wh= ere externalid is unique. Eg email.value ew "@example.com"

Phil

On Sep 10, 2015, at 14:51, Jeremy Palenchar <jeremy@palenchar.net> wrote:
I am resuming w= ork on my SCIM client and have a comment relevant to this email.=C2=A0
=
I thought it best to reply here instead of starting a new th= read. Please let me know if you would prefer I start a new thread.

I would very much like to suggest that the Service enforce= uniqueness on the [externalID] per client tenant.

Here is the scenario:

I have a user in my client = system that is provisioned into multiple SCIM Services.=C2=A0=C2=A0I also s= et [externalID] =3D myLocalID for each User. I keep a mapping in my client = of the user to his [id] in each Service. I keep the mapping so that every t= ime I want to do an update I do not need to search the Service by [external= ID] to get the Service [id] before PUTing the update using Service\User\[id= ].

Everything works fine as long as the mapping in= formation remains intact in my system. I can ADD and PUT changes all I want= . My concern comes if the local mapping store is lost or corrupted.

In this case, I may try to ADD a resource when I should b= e doing an Update (Client doesn't know the user already exists).=C2=A0<= /div>

In my perfect world, the Service would enforce uni= queness on [externalID] and prevent me from creating a duplicate user in th= eir Service. In this way I could fail gracefully and call back with an Upda= te for the existing user instead of creating a duplicate.


Thoughts?

-Jeremy



On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt <phil.hunt@= oracle.com> wrote:
WG Members,

Morteza an= d I had a good talk on the phone on today=E2=80=99s informal WG call (we di= d not have quorum), I think we may have a good proposal on externalId for y= our consideration. It does not address everyone=E2=80=99s needs but it addr= esses the concerns about externalId within the scope of our charter which i= s provisioning.

Below is some modified text for the exte= rnalId attribute.

It keeps the definition the= same, but makes clear who gets to assign the value (besides an arbitrary S= CIM client).

Please see the text below, the change= s are in UPPERCASE.

Proposed text for externalId:<= /div>
externalId
=C2=A0 =C2=A0 =C2=A0 A String that is an identif= ier for the resource as defined by the=C2=A0PROVISIONING client.=C2=A0 The<= /div>
=C2=A0 =C2= =A0 =C2=A0 "externalId" may simplify identification of the=C2=A0<= /div>
=C2=A0 =C2= =A0 =C2=A0 resource between PROVISIONING client and service provider by all= owing=C2=A0
=C2=A0 =C2=A0 =C2=A0 clientS to use a filter to locate the resource with A= N IDENTIFIER FROM THE PROVISIONING DOMAIN
=C2=A0 =C2=A0 =C2=A0 , obviating the need to= store a local mapping between
=C2=A0 =C2=A0 =C2=A0 the PROVISIONING DOMAIN'S iden= tifier of the resource and the identifier used by
=C2=A0 =C2=A0 =C2=A0 the service pro= vider.=C2=A0 Each resource MAY include a SINGLE non-empty
=C2=A0 =C2=A0 =C2=A0 "= ;externalId" value.=C2=A0 The value of the "externalId" attr= ibute is
= =C2=A0 =C2=A0 =C2=A0 always issued by the PROVISONING client and MUST NOT b= e specified by the
=C2=A0 =C2=A0 =C2=A0 service provider.=C2=A0 The service provider M= UST always interpret the
=C2=A0 =C2=A0 =C2=A0 externalId as scoped to the client's= tenant.=C2=A0 While the server
=C2=A0 =C2=A0 =C2=A0 does not enforce uniqueness, it i= s assumed that the value's
=C2=A0 =C2=A0 =C2=A0 uniqueness is controlled by the cl= ient setting the value.=C2=A0 See
=C2=A0 =C2=A0 =C2=A0 Section 9 for additional consid= erations regarding privacy.

If any one has any objections or amendments, please let the group know b= y the end of the week.=C2=A0

I propose to post thi= s change to the draft early next week.

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



--001a113ecb8ac2aa1a0520d4c3f3-- From nobody Tue Sep 29 11:10:40 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3C1ACF09 for ; Tue, 29 Sep 2015 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRg_4WLrUsNG for ; Tue, 29 Sep 2015 11:10:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0001ACF16 for ; Tue, 29 Sep 2015 11:10:36 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8TIAWT5021698 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Sep 2015 18:10:35 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8TIAW7j027616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 18:10:32 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8TIAVwE027799; Tue, 29 Sep 2015 18:10:32 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Sep 2015 11:10:31 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_38819D38-73EA-4F50-9721-7C6F4B104630" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: Date: Tue, 29 Sep 2015 11:10:27 -0700 Message-Id: <8EE2BEE7-8873-410B-8E17-FBA34C77A9FF@oracle.com> References: To: Chuck Mortimore X-Mailer: Apple Mail (2.2104) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: SCIM WG Subject: Re: [scim] Discovery support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 18:10:39 -0000 --Apple-Mail=_38819D38-73EA-4F50-9721-7C6F4B104630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chuck, Thanks. That too was my main objective. Is there anything else that should be returned other than the URL for = the SCIM server? E.g. do we want a JSON structure that might convey = multiple pieces of information? E.g. authentication requirements and = endpoints. I am leaning towards just returning a URL and keeping the response = simple since SCIM already has its own service specific discovery = endpoints (e.g. /ServiceProviderConfig). Phil @independentid www.independentid.com phil.hunt@oracle.com > On Sep 28, 2015, at 12:37 PM, Chuck Mortimore = wrote: >=20 > We're interested, in the service discovery aspect. Less so on the = profile discovery / webfinger =20 >=20 > On Mon, Sep 28, 2015 at 11:58 AM, Phil Hunt > wrote: > It=E2=80=99s now Monday after completion of the SCIM RFCs and I have = already received a new enhancement request. BTW thanks to everyone in = the WG for all your efforts! >=20 > The request is to define discovery for SCIM. For example using the = Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033). >=20 > For example, a SCIM client may send the following query: >=20 > GET https://www.example.com/.well-known/scim = >=20 > For which the server might respond with a URL to the appropriate SCIM = server and path to the server root (e.g. "profile.example.com/scim = =E2=80=9D). >=20 > In a more complex version with a webfinger (RFC7033) query: >=20 > GET = https://www.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40exam= ple.com& = > rel=3Dscim-profile >=20 > Which responds: > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Content-Type: application/jrd+json >=20 > { > "subject" : "acct:bob@example.com = ", > "links" : > [ > { > "rel" : =E2=80=9Cscim-profile", > "href" : "https://www.example.com/sciim/Users/bob-id = " > } > ] > } >=20 >=20 > Overall, I see a few different use-cases: >=20 > 1. A SCIM client simply wants to know where the SCIM Profile service = is for a specific domain (e.g. tenacy.example.com = ). >=20 > 2. A SCIM client might be looking for a user=E2=80=99s profile = service. So it asks example.com where is = phil.hunt@acme.com ? This would be a = WebFinger style query based on the well-known endpoint. The same = WebFinger query could also return the OIDC endpoints as well as the SCIM = endpoints for the user. This may be useful for cases where service = providers have multiple tenancies and there is a need to have a generic, = tenancy neutral lookup service. >=20 > 3. A SCIM client that has the service endpoint for a SaaS service = (e.g. CRM, HCM, Finance) may be looking for the provisioning endpoint = and the ResourceType and schemas relevant to the application. For = example, a client that wants to provision to a User to a Finance system, = wants know where the Finance app provisioning endpoint is. It could be = an Finance SCIM endpoint or it may a profile service endpoint. >=20 > Questions: >=20 > A. Are there members of the WG interested in this? >=20 > B. =46rom a protocol standpoint, it should not matter whether a client = is talking to SCIM that is deployed in front of a business application = (like CRM, Finance), vs. SCIM as a general User profile service. = However, due to possible difference in the higher-level logic of the = client, would it be important to distinguish between say = =E2=80=9Cscim-provisioning=E2=80=9D and =E2=80=9Cscim-profile=E2=80=9D = as distinct types of services? If so, what do we think defines that = difference? >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = >=20 --Apple-Mail=_38819D38-73EA-4F50-9721-7C6F4B104630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Chuck,

Thanks.  That too was my main objective.

Is there anything else = that should be returned other than the URL for the SCIM server? =  E.g. do we want a JSON structure that might convey multiple pieces = of information?  E.g. authentication requirements and = endpoints.

I = am leaning towards just returning a URL and keeping the response simple = since SCIM already has its own service specific discovery endpoints = (e.g. /ServiceProviderConfig).


On Sep 28, 2015, at 12:37 PM, Chuck Mortimore <charliemortimore@gmail.com> wrote:

We're interested, in the service discovery aspect.   = Less so on the profile discovery / webfinger   

On Mon, = Sep 28, 2015 at 11:58 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
It=E2=80=99s now = Monday after completion of the SCIM RFCs and I have already received a = new enhancement request.  BTW thanks to everyone in the WG for all = your efforts!

The request is to define discovery for SCIM. For example using the = Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033).

For example, a SCIM client may send the following query:

GET  https://www.example.com/.well-known/scim

For which the server might respond with a URL to the appropriate SCIM = server and path to the server root (e.g. "profile.example.com/scim=E2=80=9D).

In a more complex version with a webfinger (RFC7033) query:
=
GET https://www.example.com/.well-known/webfinger?resource=3Dacct%3= Abob%40example.com&
        rel=3Dscim-profile

Which responds:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : "acct:bob@example.com",
       "links" :
       [
         {
           "rel" : =E2=80=9Cscim-profile",            "href" : "https://www.example.com/sciim/Users/bob-id"
         }
       ]
     }


Overall, I see a few different use-cases:

1.  A SCIM client simply wants to know where the SCIM Profile = service is for a specific domain (e.g. tenacy.example.com).

2.  A SCIM client might be looking for a user=E2=80=99s profile = service.  So it asks example.com where is = phil.hunt@acme.com?  This would be a WebFinger style = query based on the well-known endpoint. The same WebFinger query could = also return the OIDC endpoints as well as the SCIM endpoints for the = user.  This may be useful for cases where service providers have = multiple tenancies and there is a need to have a generic, tenancy = neutral lookup service.

3.  A SCIM client that has the service endpoint for a SaaS service = (e.g. CRM, HCM, Finance) may be looking for the provisioning endpoint = and the ResourceType and schemas relevant to the application.  =  For example, a client that wants to provision to a User to a = Finance system, wants know where the Finance app provisioning endpoint = is.  It could be an Finance SCIM endpoint or it may a profile = service endpoint.

Questions:

A. Are there members of the WG interested in this?

B. =46rom a protocol standpoint, it should not matter whether a client = is talking to SCIM that is deployed in front of a business application = (like CRM, Finance), vs. SCIM as a general User profile service. = However, due to possible difference in the higher-level logic of the = client, would it be important to distinguish between say = =E2=80=9Cscim-provisioning=E2=80=9D and =E2=80=9Cscim-profile=E2=80=9D = as distinct types of services?  If so, what do we think defines = that difference?

Thanks,

Phil

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

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


= --Apple-Mail=_38819D38-73EA-4F50-9721-7C6F4B104630-- From nobody Tue Sep 29 12:29:29 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D581B4CAF for ; Tue, 29 Sep 2015 12:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6SudpFt9NxF for ; Tue, 29 Sep 2015 12:29:25 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC971B4B98 for ; Tue, 29 Sep 2015 12:29:25 -0700 (PDT) Received: by igbni9 with SMTP id ni9so14863240igb.0 for ; Tue, 29 Sep 2015 12:29:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eKbePpYpMMo66fdjV2WCrAr8QHLH6XrZYUESYDlAFP4=; b=jFVH9/gSetq4/W6eUU89EWXk8RDA7/8D8RKMfOIeCC14PkjR83amZhIe9kUbmFD8vV c/gxFl+kpUcEP1HHf05hRgyt4zARAF6W5fa0Tfn1HTQjcjeBN4tDoslRD84HXMhhg+XY pqUHq8axb92IleCdkvdyiccG/cC9G9OxEwPpnZsIQEfmW7I32qNmuzKKPs4w+gQzzhy+ PT2lqU9gr/e7xRdDQeNoBB4SxMcucXnsRvVogX8PWoyOOxF9zXu5hv+RP9bFEOjRaXEt Tmvi+Ej6jh4hZDfbyJyyeBPtxEwpVkNNxYldKSoeRMObje2EvJPwP3kwqBixA3B21GKo QC9Q== X-Gm-Message-State: ALoCoQmGv6dkF1D0PYjjGrjFzBuo1eUgDh1ECy4Zym7BVPsqjczk64jZzpEj+ulviiP4uS6z9Txl X-Received: by 10.50.78.231 with SMTP id e7mr540236igx.88.1443554964676; Tue, 29 Sep 2015 12:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.46.196 with HTTP; Tue, 29 Sep 2015 12:29:05 -0700 (PDT) In-Reply-To: <8EE2BEE7-8873-410B-8E17-FBA34C77A9FF@oracle.com> References: <8EE2BEE7-8873-410B-8E17-FBA34C77A9FF@oracle.com> From: Ian Glazer Date: Tue, 29 Sep 2015 15:29:05 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e013c649ee25a830520e7d4f9 Archived-At: Cc: SCIM WG , Chuck Mortimore Subject: Re: [scim] Discovery support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 19:29:28 -0000 --089e013c649ee25a830520e7d4f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like that approach Phil On Tue, Sep 29, 2015 at 2:10 PM, Phil Hunt wrote: > Chuck, > > Thanks. That too was my main objective. > > Is there anything else that should be returned other than the URL for the > SCIM server? E.g. do we want a JSON structure that might convey multiple > pieces of information? E.g. authentication requirements and endpoints. > > I am leaning towards just returning a URL and keeping the response simple > since SCIM already has its own service specific discovery endpoints (e.g. > /ServiceProviderConfig). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Sep 28, 2015, at 12:37 PM, Chuck Mortimore > wrote: > > We're interested, in the service discovery aspect. Less so on the > profile discovery / webfinger > > On Mon, Sep 28, 2015 at 11:58 AM, Phil Hunt wrote: > >> It=E2=80=99s now Monday after completion of the SCIM RFCs and I have alr= eady >> received a new enhancement request. BTW thanks to everyone in the WG fo= r >> all your efforts! >> >> The request is to define discovery for SCIM. For example using the >> Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033). >> >> For example, a SCIM client may send the following query: >> >> GET https://www.example.com/.well-known/scim >> >> For which the server might respond with a URL to the appropriate SCIM >> server and path to the server root (e.g. "profile.example.com/scim=E2=80= =9D). >> >> In a more complex version with a webfinger (RFC7033) query: >> >> GET >> https://www.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40ex= ample.com& >> rel=3Dscim-profile >> >> Which responds: >> HTTP/1.1 200 OK >> Access-Control-Allow-Origin: * >> Content-Type: application/jrd+json >> >> { >> "subject" : "acct:bob@example.com", >> "links" : >> [ >> { >> "rel" : =E2=80=9Cscim-profile", >> "href" : "https://www.example.com/sciim/Users/bob-id" >> } >> ] >> } >> >> >> Overall, I see a few different use-cases: >> >> 1. A SCIM client simply wants to know where the SCIM Profile service is >> for a specific domain (e.g. tenacy.example.com). >> >> 2. A SCIM client might be looking for a user=E2=80=99s profile service.= So it >> asks example.com where is phil.hunt@acme.com? This would be a WebFinger >> style query based on the well-known endpoint. The same WebFinger query >> could also return the OIDC endpoints as well as the SCIM endpoints for t= he >> user. This may be useful for cases where service providers have multipl= e >> tenancies and there is a need to have a generic, tenancy neutral lookup >> service. >> >> 3. A SCIM client that has the service endpoint for a SaaS service (e.g. >> CRM, HCM, Finance) may be looking for the provisioning endpoint and the >> ResourceType and schemas relevant to the application. For example, a >> client that wants to provision to a User to a Finance system, wants know >> where the Finance app provisioning endpoint is. It could be an Finance >> SCIM endpoint or it may a profile service endpoint. >> >> Questions: >> >> A. Are there members of the WG interested in this? >> >> B. From a protocol standpoint, it should not matter whether a client is >> talking to SCIM that is deployed in front of a business application (lik= e >> CRM, Finance), vs. SCIM as a general User profile service. However, due = to >> possible difference in the higher-level logic of the client, would it be >> important to distinguish between say =E2=80=9Cscim-provisioning=E2=80=9D= and =E2=80=9Cscim-profile=E2=80=9D >> as distinct types of services? If so, what do we think defines that >> difference? >> >> Thanks, >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.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 > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --089e013c649ee25a830520e7d4f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like that approach Phil
=
On Tue, Sep 29, 2015 at 2:10 PM, Phil Hunt <= span dir=3D"ltr"><phil.hunt@oracle.com> wrote:
Chuck,

Thanks.= =C2=A0 That too was my main objective.

Is there an= ything else that should be returned other than the URL for the SCIM server?= =C2=A0 E.g. do we want a JSON structure that might convey multiple pieces o= f information?=C2=A0 E.g. authentication requirements and endpoints.
<= div>
I am leaning towards just returning a URL and keeping th= e response simple since SCIM already has its own service specific discovery= endpoints (e.g. /ServiceProviderConfig).

=
Phil

@independentid
<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om

On Sep 28, 2015, at 12:37 PM, Chuck= Mortimore <charliemortimore@gmail.com> wrote:

We're interested, in the service discovery aspect. =C2=A0 Less so on = the profile discovery / webfinger =C2=A0=C2=A0

On Mon, Sep 28, 2015 at 11:58 AM, Phil H= unt <phil.hunt@oracle.com> wrote:
It=E2=80=99s now Monday after completion of the SCIM RFCs and I = have already received a new enhancement request.=C2=A0 BTW thanks to everyo= ne in the WG for all your efforts!

The request is to define discovery for SCIM. For example using the Well-kno= wn mechanism (RFC5785) and potentially WebFinger (RFC7033).

For example, a SCIM client may send the following query:

GET=C2=A0 https://www.example.com/.well-known/scim

For which the server might respond with a URL to the appropriate SCIM serve= r and path to the server root (e.g. "profile.example.com/scim=E2=80=9D).

In a more complex version with a webfinger (RFC7033) query:

GET https://ww= w.example.com/.well-known/webfinger?resource=3Dacct%3Abob%40example.com&= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rel=3Dscim-profile

Which responds:
=C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0Access-Control-Allow-Origin: *
=C2=A0 =C2=A0 =C2=A0Content-Type: application/jrd+json

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"subject" : "acct:bob@example.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"links" :
=C2=A0 =C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : =E2=80=9Cscim-pr= ofile",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"href" : "https://www.example.com/sciim/Users/bob-id"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0}


Overall, I see a few different use-cases:

1.=C2=A0 A SCIM client simply wants to know where the SCIM Profile service = is for a specific domain (e.g. tenacy.example.com).

2.=C2=A0 A SCIM client might be looking for a user=E2=80=99s profile servic= e.=C2=A0 So it asks example.com where is phil.hunt@acme.com?=C2=A0 This would be a WebFinger= style query based on the well-known endpoint. The same WebFinger query cou= ld also return the OIDC endpoints as well as the SCIM endpoints for the use= r.=C2=A0 This may be useful for cases where service providers have multiple= tenancies and there is a need to have a generic, tenancy neutral lookup se= rvice.

3.=C2=A0 A SCIM client that has the service endpoint for a SaaS service (e.= g. CRM, HCM, Finance) may be looking for the provisioning endpoint and the = ResourceType and schemas relevant to the application.=C2=A0 =C2=A0For examp= le, a client that wants to provision to a User to a Finance system, wants k= now where the Finance app provisioning endpoint is.=C2=A0 It could be an Fi= nance SCIM endpoint or it may a profile service endpoint.

Questions:

A. Are there members of the WG interested in this?

B. From a protocol standpoint, it should not matter whether a client is tal= king to SCIM that is deployed in front of a business application (like CRM,= Finance), vs. SCIM as a general User profile service. However, due to poss= ible difference in the higher-level logic of the client, would it be import= ant to distinguish between say =E2=80=9Cscim-provisioning=E2=80=9D and =E2= =80=9Cscim-profile=E2=80=9D as distinct types of services?=C2=A0 If so, wha= t do we think defines that difference?

Thanks,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.= 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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--089e013c649ee25a830520e7d4f9-- From nobody Tue Sep 29 13:42:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAF51B2A1F for ; Tue, 29 Sep 2015 13:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZMUNqNP16qn for ; Tue, 29 Sep 2015 13:42:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053351B2A1D for ; Tue, 29 Sep 2015 13:42:28 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8TKgSCE023846 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Sep 2015 20:42:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8TKgR4R028842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Sep 2015 20:42:27 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8TKgRP7008435 for ; Tue, 29 Sep 2015 20:42:27 GMT Received: from [25.91.75.250] (/72.143.232.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Sep 2015 13:42:27 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 29 Sep 2015 13:42:22 -0700 To: SCIM WG X-Mailer: iPhone Mail (12H321) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 20:42:30 -0000 Anyone interested in doing a call this Wednesday? Phil From nobody Tue Sep 29 13:44:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B191B2A42 for ; Tue, 29 Sep 2015 13:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVqqJ739mRMI for ; Tue, 29 Sep 2015 13:44:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720E41B2A3E for ; Tue, 29 Sep 2015 13:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cpgRnRVaCGt8JYb8GmnHB/7yPVNY3E7VJVUDREJjS4w=; b=KIusR0IV+Rr3dxl+Mb+1b9zSBd6uCTSmvpLJ9AYEsI9iHzmTMNicflS1n0G6pS00/QyIKOEo98hvJSs701Dc3ZC9H5RuwHBRRO2rb/Ybira9ZY3Pz/04GAg4Wtfd9rcWj+L7a1BQe2IVedqQQz56Ml1pRJIHL4pqPVe5Rl5kZy0= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (10.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 29 Sep 2015 20:43:56 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0280.017; Tue, 29 Sep 2015 20:43:55 +0000 From: Anthony Nadalin To: Phil Hunt , SCIM WG Thread-Topic: [scim] Call this week Thread-Index: AQHQ+vdixJB0n0Yg6UmGJi2Nw/8i855T+QhQ Date: Tue, 29 Sep 2015 20:43:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:3::49e] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:OJKvshuBhA3CNOYrc8UgEdmqx3FYEYgjEkKqecR48QU9AN5zl3OKmKCDIO7rjHtTg1mwj3X2NRz3pJ4vQJERnm9BBZWPMurcBh7EmPAmsbYW6WQKEPWsTdbkNc7iGuw55fSIBhx+Et8v40Tvet3jYQ==; 24:hP4QkZJsSylxSUYBA38Upindxhc4YZD86v2Y/7dcdfDyl0H67qgheyjN52pMXUjLNrWnbsP7TC/1sOqTcOdBvLdLnhI0GZVsnlP3aS4TK0o=; 20:bMvSVBoHtn182pAr0OvM9cGvdGmIKtrjfX3oO6iNq3ahlwzshp31CQhU9JhK5AsgWPqZM3cbn9eAe502Xpft8w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0714841678 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(46034005)(199003)(52254002)(17383004)(13464003)(16813002)(99286002)(5002640100001)(5005710100001)(105586002)(5001830100001)(106116001)(106356001)(5001860100001)(87936001)(10090500001)(81156007)(189998001)(12110500001)(122556002)(5001770100001)(74316001)(4001540100001)(8990500004)(10400500002)(97736004)(76576001)(10290500002)(101416001)(19580395003)(76176999)(102836002)(5003600100002)(15975445007)(77096005)(5004730100002)(5007970100001)(64706001)(68736005)(50986999)(46102003)(92566002)(86612001)(33656002)(2900100001)(62966003)(575784001)(86362001)(54356999)(107886002)(77156002)(2950100001)(40100003)(5001960100002)(5001920100001)(19580405001)(5008740100001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2015 20:43:55.6853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 20:44:02 -0000 Interested but how about a little more notice, next week ? or Thu/Fri this = week ? -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, September 29, 2015 1:42 PM To: SCIM WG Subject: [scim] Call this week Anyone interested in doing a call this Wednesday? Phil _______________________________________________ scim mailing list scim@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com%7= cf07fae2aa1974c9441f908d2c90e838f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd= ata=3DToqU1wJ5aIjmN1gmK78aD2i9Yu0BlR%2f8MRIozWRtTA8%3d From nobody Tue Sep 29 14:48:55 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B000A1B521F for ; Tue, 29 Sep 2015 14:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkozBeLRtVE8 for ; Tue, 29 Sep 2015 14:48:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBD71B5215 for ; Tue, 29 Sep 2015 14:48:53 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8TLmqa1013163 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Sep 2015 21:48:52 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8TLmpE8010032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 21:48:52 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8TLmp9L030973; Tue, 29 Sep 2015 21:48:51 GMT Received: from [25.91.75.250] (/72.143.232.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Sep 2015 14:48:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Tue, 29 Sep 2015 14:48:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anthony Nadalin X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: SCIM WG Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 21:48:54 -0000 It is the regular scheduled one. But I am open to any other time thurs or fr= iday.=20 Phil > On Sep 29, 2015, at 13:43, Anthony Nadalin wrote: >=20 > Interested but how about a little more notice, next week ? or Thu/Fri this= week ? >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Tuesday, September 29, 2015 1:42 PM > To: SCIM WG > Subject: [scim] Call this week >=20 > Anyone interested in doing a call this Wednesday? >=20 >=20 >=20 > Phil >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com%7= cf07fae2aa1974c9441f908d2c90e838f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda= ta=3DToqU1wJ5aIjmN1gmK78aD2i9Yu0BlR%2f8MRIozWRtTA8%3d >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 30 00:07:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558851A049A for ; Wed, 30 Sep 2015 00:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwkYvzCSsOGm for ; Wed, 30 Sep 2015 00:07:16 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE3C1A03B3 for ; Wed, 30 Sep 2015 00:07:16 -0700 (PDT) Received: from NG-EX02.ad.nexusgroup.com (10.75.28.43) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 30 Sep 2015 09:07:13 +0200 Received: from NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d]) by NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d%12]) with mapi id 15.00.0995.032; Wed, 30 Sep 2015 09:07:13 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= To: Phil Hunt Thread-Topic: [scim] Call this week Thread-Index: AQHQ+vdkCvbOvA+gO0CFcDSyYue+u55T16eAgAASHgCAAJwHAA== Date: Wed, 30 Sep 2015 07:07:12 +0000 Message-ID: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , SCIM WG Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 07:07:19 -0000 Thursday works for me, not Friday. / Erik > On 29 Sep 2015, at 23:48, Phil Hunt wrote: >=20 > It is the regular scheduled one. But I am open to any other time thurs or= friday.=20 >=20 > Phil >=20 >> On Sep 29, 2015, at 13:43, Anthony Nadalin wrote= : >>=20 >> Interested but how about a little more notice, next week ? or Thu/Fri th= is week ? >>=20 >> -----Original Message----- >> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Tuesday, September 29, 2015 1:42 PM >> To: SCIM WG >> Subject: [scim] Call this week >>=20 >> Anyone interested in doing a call this Wednesday? >>=20 >>=20 >>=20 >> Phil >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.co= m%7cf07fae2aa1974c9441f908d2c90e838f%7c72f988bf86f141af91ab2d7cd011db47%7c1= &sdata=3DToqU1wJ5aIjmN1gmK78aD2i9Yu0BlR%2f8MRIozWRtTA8%3d >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 30 09:14:52 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB23D1B5EDF for ; Wed, 30 Sep 2015 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtvWMmghaIL2 for ; Wed, 30 Sep 2015 09:14:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C741B5E7E for ; Wed, 30 Sep 2015 09:14:31 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8UGEUqw005148 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Sep 2015 16:14:31 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8UGEU1m025673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 16:14:30 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8UGEUGP031669; Wed, 30 Sep 2015 16:14:30 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Sep 2015 09:14:29 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> Date: Wed, 30 Sep 2015 09:14:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB05BF6-2B68-460A-8999-57402349F767@oracle.com> References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Anthony Nadalin , SCIM WG Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 16:14:50 -0000 Since 11am pacific was the usual time shall we plan for that? =20 I will email those who say they want to participate a conference number late= r today.=20 Erik if there is a better time let us know since so far you are the furthest= timezone away.=20 Phil > On Sep 30, 2015, at 00:07, Erik Wahlstr=C3=B6m neXus wrote: >=20 > Thursday works for me, not Friday. > / Erik >=20 >=20 >=20 >> On 29 Sep 2015, at 23:48, Phil Hunt wrote: >>=20 >> It is the regular scheduled one. But I am open to any other time thurs or= friday.=20 >>=20 >> Phil >>=20 >>> On Sep 29, 2015, at 13:43, Anthony Nadalin wrote= : >>>=20 >>> Interested but how about a little more notice, next week ? or Thu/Fri th= is week ? >>>=20 >>> -----Original Message----- >>> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >>> Sent: Tuesday, September 29, 2015 1:42 PM >>> To: SCIM WG >>> Subject: [scim] Call this week >>>=20 >>> Anyone interested in doing a call this Wednesday? >>>=20 >>>=20 >>>=20 >>> Phil >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com= %7cf07fae2aa1974c9441f908d2c90e838f%7c72f988bf86f141af91ab2d7cd011db47%7c1&s= data=3DToqU1wJ5aIjmN1gmK78aD2i9Yu0BlR%2f8MRIozWRtTA8%3d >>>=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 From nobody Wed Sep 30 11:59:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5251A890F for ; Wed, 30 Sep 2015 11:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT7BaZ7sx8a7 for ; Wed, 30 Sep 2015 11:58:59 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F24D1A890E for ; Wed, 30 Sep 2015 11:58:59 -0700 (PDT) Received: from NG-EX02.ad.nexusgroup.com (10.75.28.43) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 30 Sep 2015 20:58:56 +0200 Received: from NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d]) by NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d%12]) with mapi id 15.00.0995.032; Wed, 30 Sep 2015 20:58:56 +0200 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Phil Hunt Thread-Topic: [scim] Call this week Thread-Index: AQHQ+vdkCvbOvA+gO0CFcDSyYue+u55T16eAgAASHgCAAJwHAIAAmOcAgAAt9AA= Date: Wed, 30 Sep 2015 18:58:56 +0000 Message-ID: <29AEE58C-7C0C-4A5B-8F11-05819DDA3F3A@nexusgroup.com> References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> <1CB05BF6-2B68-460A-8999-57402349F767@oracle.com> In-Reply-To: <1CB05BF6-2B68-460A-8999-57402349F767@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: text/plain; charset="utf-8" Content-ID: <1EA26B655260814288E353ECCDB54173@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , SCIM WG Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 18:59:02 -0000 SGksDQpDdXJyZW50IHRpbWUgd29ya3MgZm9yIG1lLg0KLyBFcmlrDQoNCg0KPiBPbiAzMCBTZXAg MjAxNSwgYXQgMTg6MTQsIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+IHdyb3RlOg0K PiANCj4gU2luY2UgMTFhbSBwYWNpZmljIHdhcyB0aGUgdXN1YWwgdGltZSBzaGFsbCB3ZSBwbGFu IGZvciB0aGF0PyAgDQo+IA0KPiBJIHdpbGwgZW1haWwgdGhvc2Ugd2hvIHNheSB0aGV5IHdhbnQg dG8gcGFydGljaXBhdGUgYSBjb25mZXJlbmNlIG51bWJlciBsYXRlciB0b2RheS4gDQo+IA0KPiBF cmlrIGlmIHRoZXJlIGlzIGEgYmV0dGVyIHRpbWUgbGV0IHVzIGtub3cgc2luY2Ugc28gZmFyIHlv dSBhcmUgdGhlIGZ1cnRoZXN0IHRpbWV6b25lIGF3YXkuIA0KPiANCj4gUGhpbA0KPiANCj4+IE9u IFNlcCAzMCwgMjAxNSwgYXQgMDA6MDcsIEVyaWsgV2FobHN0csO2bSBuZVh1cyA8ZXJpay53YWhs c3Ryb21AbmV4dXNncm91cC5jb20+IHdyb3RlOg0KPj4gDQo+PiBUaHVyc2RheSB3b3JrcyBmb3Ig bWUsIG5vdCBGcmlkYXkuDQo+PiAvIEVyaWsNCj4+IA0KPj4gDQo+PiANCj4+PiBPbiAyOSBTZXAg MjAxNSwgYXQgMjM6NDgsIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+IHdyb3RlOg0K Pj4+IA0KPj4+IEl0IGlzIHRoZSByZWd1bGFyIHNjaGVkdWxlZCBvbmUuIEJ1dCBJIGFtIG9wZW4g dG8gYW55IG90aGVyIHRpbWUgdGh1cnMgb3IgZnJpZGF5LiANCj4+PiANCj4+PiBQaGlsDQo+Pj4g DQo+Pj4+IE9uIFNlcCAyOSwgMjAxNSwgYXQgMTM6NDMsIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5h ZEBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEludGVyZXN0ZWQgYnV0IGhvdyBh Ym91dCBhIGxpdHRsZSBtb3JlIG5vdGljZSwgbmV4dCB3ZWVrID8gb3IgVGh1L0ZyaSB0aGlzIHdl ZWsgPw0KPj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTog c2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVu dA0KPj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTUgMTo0MiBQTQ0KPj4+PiBU bzogU0NJTSBXRyA8c2NpbUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogW3NjaW1dIENhbGwgdGhp cyB3ZWVrDQo+Pj4+IA0KPj4+PiBBbnlvbmUgaW50ZXJlc3RlZCBpbiBkb2luZyBhIGNhbGwgdGhp cyBXZWRuZXNkYXk/DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFBoaWwNCj4+Pj4gDQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNj aW0gbWFpbGluZyBsaXN0DQo+Pj4+IHNjaW1AaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0 Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZzY2ltJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl NDBtaWNyb3NvZnQuY29tJTdjZjA3ZmFlMmFhMTk3NGM5NDQxZjkwOGQyYzkwZTgzOGYlN2M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9VG9xVTF3SjVhSWptTjFnbUs3 OGFEMmk5WXUwQmxSJTJmOE1SSW96V1J0VEE4JTNkDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzY2ltIG1haWxpbmcgbGlz dA0KPj4+PiBzY2ltQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2NpbQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gc2NpbSBtYWlsaW5nIGxpc3QNCj4+PiBzY2ltQGlldGYub3Jn DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzY2lt IG1haWxpbmcgbGlzdA0KPj4gc2NpbUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== From nobody Wed Sep 30 19:31:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3C1ACED5 for ; Wed, 30 Sep 2015 19:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVIecKrMJdM8 for ; Wed, 30 Sep 2015 19:31:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BD01ACDA5 for ; Wed, 30 Sep 2015 19:31:13 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Thu, 1 Oct 2015 02:31:09 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.16]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.16]) with mapi id 15.01.0280.017; Thu, 1 Oct 2015 02:31:09 +0000 From: Kelly Grizzle To: Ian Glazer , Phil Hunt Thread-Topic: [scim] Discovery support for SCIM Thread-Index: AQHQ+h+lT8JbNdrpyEulUhXjQhnZa55T0BlOgAAV3ICAAggBgA== Date: Thu, 1 Oct 2015 02:31:09 +0000 Message-ID: References: <8EE2BEE7-8873-410B-8E17-FBA34C77A9FF@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2B77915A00AC962B7792A7 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; x-originating-ip: [70.114.158.171] x-microsoft-exchange-diagnostics: 1; BN1PR04MB389; 5:T2cO56JK0yryCo6QfSQmPSbqREteuUhKiD+gZCx/KjULmmWSzfi8IWpE/xBofASCIJ/sK0PfoadOrKHD/1AmWQTLrqWVOjJgAkHV3eLbNy/lzIPCeHIG3whxeQS/f/kXLh5v1Sz8GFRM5gF385ZgQg==; 24:kOIaE1KVRUNG/Cot42OdPLlfskBgXvRudApYqGDPg0kTGgkyXTkOcaL/f/ASoZxQWuJArQTM+FvmAnPzcFgW7EiuIY8CTvl0+YthX75VA+0=; 20:d0uOJMfIW1dGl4T0eS9fcCMBi5q6kqxZsUzZesMckFXHxq9UTx9EnczjxHzK5/ExKUok2Br/39OVAyE9g/tcGA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB389; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0716E70AB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(54164003)(164054003)(189002)(377454003)(24454002)(199003)(15395725005)(99286002)(50986999)(40100003)(101416001)(76176999)(105586002)(5002640100001)(86362001)(54356999)(106116001)(15975445007)(5001960100002)(5007970100001)(5008740100001)(10400500002)(74316001)(5004730100002)(11100500001)(106356001)(189998001)(5003600100002)(68736005)(5001770100001)(5001830100001)(19580405001)(46102003)(16601075003)(87936001)(64706001)(122556002)(81156007)(4001540100001)(5001860100001)(16236675004)(66066001)(76576001)(19625215002)(19609705001)(33656002)(93886004)(92566002)(2950100001)(62966003)(19617315012)(77156002)(102836002)(2900100001)(19300405004)(97736004)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR04MB392BC5B246BF082E0E3DCA9E24C0BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2015 02:31:09.5201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 Archived-At: Cc: SCIM WG , Chuck Mortimore Subject: Re: [scim] Discovery support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 02:31:16 -0000 --_000_BN1PR04MB392BC5B246BF082E0E3DCA9E24C0BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuICBKdXN0IHRoZSBiYXNlIFVSTCBzaG91bGQgYmUgZ29vZC4gIFRoZW4gdGhlIC9TZXJ2aWNl UHJvdmlkZXJDb25maWdzLCAvUmVzb3VyY2VUeXBlcywgYW5kIC9TY2hlbWFzIGNhbiBiZSB1c2Vk IGJhc2VkIG9uIHRoZSBTQ0lNIHNwZWMuDQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gR2xhemVyDQpTZW50OiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMjksIDIwMTUgMjoyOSBQTQ0KVG86IFBoaWwgSHVudA0KQ2M6IFNDSU0gV0c7IENodWNr IE1vcnRpbW9yZQ0KU3ViamVjdDogUmU6IFtzY2ltXSBEaXNjb3Zlcnkgc3VwcG9ydCBmb3IgU0NJ TQ0KDQpJIGxpa2UgdGhhdCBhcHByb2FjaCBQaGlsDQoNCk9uIFR1ZSwgU2VwIDI5LCAyMDE1IGF0 IDI6MTAgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQpDaHVjaywNCg0KVGhhbmtzLiAgVGhhdCB0b28gd2FzIG15 IG1haW4gb2JqZWN0aXZlLg0KDQpJcyB0aGVyZSBhbnl0aGluZyBlbHNlIHRoYXQgc2hvdWxkIGJl IHJldHVybmVkIG90aGVyIHRoYW4gdGhlIFVSTCBmb3IgdGhlIFNDSU0gc2VydmVyPyAgRS5nLiBk byB3ZSB3YW50IGEgSlNPTiBzdHJ1Y3R1cmUgdGhhdCBtaWdodCBjb252ZXkgbXVsdGlwbGUgcGll Y2VzIG9mIGluZm9ybWF0aW9uPyAgRS5nLiBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMgYW5k IGVuZHBvaW50cy4NCg0KSSBhbSBsZWFuaW5nIHRvd2FyZHMganVzdCByZXR1cm5pbmcgYSBVUkwg YW5kIGtlZXBpbmcgdGhlIHJlc3BvbnNlIHNpbXBsZSBzaW5jZSBTQ0lNIGFscmVhZHkgaGFzIGl0 cyBvd24gc2VydmljZSBzcGVjaWZpYyBkaXNjb3ZlcnkgZW5kcG9pbnRzIChlLmcuIC9TZXJ2aWNl UHJvdmlkZXJDb25maWcpLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRl bnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gU2VwIDI4LCAyMDE1LCBhdCAx MjozNyBQTSwgQ2h1Y2sgTW9ydGltb3JlIDxjaGFybGllbW9ydGltb3JlQGdtYWlsLmNvbTxtYWls dG86Y2hhcmxpZW1vcnRpbW9yZUBnbWFpbC5jb20+PiB3cm90ZToNCg0KV2UncmUgaW50ZXJlc3Rl ZCwgaW4gdGhlIHNlcnZpY2UgZGlzY292ZXJ5IGFzcGVjdC4gICBMZXNzIHNvIG9uIHRoZSBwcm9m aWxlIGRpc2NvdmVyeSAvIHdlYmZpbmdlcg0KDQpPbiBNb24sIFNlcCAyOCwgMjAxNSBhdCAxMTo1 OCBBTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+PiB3cm90ZToNCkl04oCZcyBub3cgTW9uZGF5IGFmdGVyIGNvbXBsZXRpb24gb2Yg dGhlIFNDSU0gUkZDcyBhbmQgSSBoYXZlIGFscmVhZHkgcmVjZWl2ZWQgYSBuZXcgZW5oYW5jZW1l bnQgcmVxdWVzdC4gIEJUVyB0aGFua3MgdG8gZXZlcnlvbmUgaW4gdGhlIFdHIGZvciBhbGwgeW91 ciBlZmZvcnRzIQ0KDQpUaGUgcmVxdWVzdCBpcyB0byBkZWZpbmUgZGlzY292ZXJ5IGZvciBTQ0lN LiBGb3IgZXhhbXBsZSB1c2luZyB0aGUgV2VsbC1rbm93biBtZWNoYW5pc20gKFJGQzU3ODUpIGFu ZCBwb3RlbnRpYWxseSBXZWJGaW5nZXIgKFJGQzcwMzMpLg0KDQpGb3IgZXhhbXBsZSwgYSBTQ0lN IGNsaWVudCBtYXkgc2VuZCB0aGUgZm9sbG93aW5nIHF1ZXJ5Og0KDQpHRVQgIGh0dHBzOi8vd3d3 LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL3NjaW0NCg0KRm9yIHdoaWNoIHRoZSBzZXJ2ZXIgbWln aHQgcmVzcG9uZCB3aXRoIGEgVVJMIHRvIHRoZSBhcHByb3ByaWF0ZSBTQ0lNIHNlcnZlciBhbmQg cGF0aCB0byB0aGUgc2VydmVyIHJvb3QgKGUuZy4gInByb2ZpbGUuZXhhbXBsZS5jb20vc2NpbTxo dHRwOi8vcHJvZmlsZS5leGFtcGxlLmNvbS9zY2ltPuKAnSkuDQoNCkluIGEgbW9yZSBjb21wbGV4 IHZlcnNpb24gd2l0aCBhIHdlYmZpbmdlciAoUkZDNzAzMykgcXVlcnk6DQoNCkdFVCBodHRwczov L3d3dy5leGFtcGxlLmNvbS8ud2VsbC1rbm93bi93ZWJmaW5nZXI/cmVzb3VyY2U9YWNjdCUzQWJv YiU0MGV4YW1wbGUuY29tJg0KICAgICAgICByZWw9c2NpbS1wcm9maWxlDQoNCldoaWNoIHJlc3Bv bmRzOg0KICAgICBIVFRQLzEuMSAyMDAgT0sNCiAgICAgQWNjZXNzLUNvbnRyb2wtQWxsb3ctT3Jp Z2luOiAqDQogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanJkK2pzb24NCg0KICAgICB7 DQogICAgICAgInN1YmplY3QiIDogImFjY3Q6Ym9iQGV4YW1wbGUuY29tPG1haWx0bzphY2N0JTNB Ym9iQGV4YW1wbGUuY29tPiIsDQogICAgICAgImxpbmtzIiA6DQogICAgICAgWw0KICAgICAgICAg ew0KICAgICAgICAgICAicmVsIiA6IOKAnHNjaW0tcHJvZmlsZSIsDQogICAgICAgICAgICJocmVm IiA6ICJodHRwczovL3d3dy5leGFtcGxlLmNvbS9zY2lpbS9Vc2Vycy9ib2ItaWQiDQogICAgICAg ICB9DQogICAgICAgXQ0KICAgICB9DQoNCg0KT3ZlcmFsbCwgSSBzZWUgYSBmZXcgZGlmZmVyZW50 IHVzZS1jYXNlczoNCg0KMS4gIEEgU0NJTSBjbGllbnQgc2ltcGx5IHdhbnRzIHRvIGtub3cgd2hl cmUgdGhlIFNDSU0gUHJvZmlsZSBzZXJ2aWNlIGlzIGZvciBhIHNwZWNpZmljIGRvbWFpbiAoZS5n LiB0ZW5hY3kuZXhhbXBsZS5jb208aHR0cDovL3RlbmFjeS5leGFtcGxlLmNvbS8+KS4NCg0KMi4g IEEgU0NJTSBjbGllbnQgbWlnaHQgYmUgbG9va2luZyBmb3IgYSB1c2Vy4oCZcyBwcm9maWxlIHNl cnZpY2UuICBTbyBpdCBhc2tzIGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+IHdoZXJl IGlzIHBoaWwuaHVudEBhY21lLmNvbTxtYWlsdG86cGhpbC5odW50QGFjbWUuY29tPj8gIFRoaXMg d291bGQgYmUgYSBXZWJGaW5nZXIgc3R5bGUgcXVlcnkgYmFzZWQgb24gdGhlIHdlbGwta25vd24g ZW5kcG9pbnQuIFRoZSBzYW1lIFdlYkZpbmdlciBxdWVyeSBjb3VsZCBhbHNvIHJldHVybiB0aGUg T0lEQyBlbmRwb2ludHMgYXMgd2VsbCBhcyB0aGUgU0NJTSBlbmRwb2ludHMgZm9yIHRoZSB1c2Vy LiAgVGhpcyBtYXkgYmUgdXNlZnVsIGZvciBjYXNlcyB3aGVyZSBzZXJ2aWNlIHByb3ZpZGVycyBo YXZlIG11bHRpcGxlIHRlbmFuY2llcyBhbmQgdGhlcmUgaXMgYSBuZWVkIHRvIGhhdmUgYSBnZW5l cmljLCB0ZW5hbmN5IG5ldXRyYWwgbG9va3VwIHNlcnZpY2UuDQoNCjMuICBBIFNDSU0gY2xpZW50 IHRoYXQgaGFzIHRoZSBzZXJ2aWNlIGVuZHBvaW50IGZvciBhIFNhYVMgc2VydmljZSAoZS5nLiBD Uk0sIEhDTSwgRmluYW5jZSkgbWF5IGJlIGxvb2tpbmcgZm9yIHRoZSBwcm92aXNpb25pbmcgZW5k cG9pbnQgYW5kIHRoZSBSZXNvdXJjZVR5cGUgYW5kIHNjaGVtYXMgcmVsZXZhbnQgdG8gdGhlIGFw cGxpY2F0aW9uLiAgIEZvciBleGFtcGxlLCBhIGNsaWVudCB0aGF0IHdhbnRzIHRvIHByb3Zpc2lv biB0byBhIFVzZXIgdG8gYSBGaW5hbmNlIHN5c3RlbSwgd2FudHMga25vdyB3aGVyZSB0aGUgRmlu YW5jZSBhcHAgcHJvdmlzaW9uaW5nIGVuZHBvaW50IGlzLiAgSXQgY291bGQgYmUgYW4gRmluYW5j ZSBTQ0lNIGVuZHBvaW50IG9yIGl0IG1heSBhIHByb2ZpbGUgc2VydmljZSBlbmRwb2ludC4NCg0K UXVlc3Rpb25zOg0KDQpBLiBBcmUgdGhlcmUgbWVtYmVycyBvZiB0aGUgV0cgaW50ZXJlc3RlZCBp biB0aGlzPw0KDQpCLiBGcm9tIGEgcHJvdG9jb2wgc3RhbmRwb2ludCwgaXQgc2hvdWxkIG5vdCBt YXR0ZXIgd2hldGhlciBhIGNsaWVudCBpcyB0YWxraW5nIHRvIFNDSU0gdGhhdCBpcyBkZXBsb3ll ZCBpbiBmcm9udCBvZiBhIGJ1c2luZXNzIGFwcGxpY2F0aW9uIChsaWtlIENSTSwgRmluYW5jZSks IHZzLiBTQ0lNIGFzIGEgZ2VuZXJhbCBVc2VyIHByb2ZpbGUgc2VydmljZS4gSG93ZXZlciwgZHVl IHRvIHBvc3NpYmxlIGRpZmZlcmVuY2UgaW4gdGhlIGhpZ2hlci1sZXZlbCBsb2dpYyBvZiB0aGUg Y2xpZW50LCB3b3VsZCBpdCBiZSBpbXBvcnRhbnQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBzYXkg 4oCcc2NpbS1wcm92aXNpb25pbmfigJ0gYW5kIOKAnHNjaW0tcHJvZmlsZeKAnSBhcyBkaXN0aW5j dCB0eXBlcyBvZiBzZXJ2aWNlcz8gIElmIHNvLCB3aGF0IGRvIHdlIHRoaW5rIGRlZmluZXMgdGhh dCBkaWZmZXJlbmNlPw0KDQpUaGFua3MsDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5p bmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpz Y2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFp bHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NjaW0NCg0KDQoNCi0tDQpJYW4gR2xhemVyDQpTZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5DQor MSAyMDIgMjU1IDMxNjYNCkBpZ2xhemVyPGh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplcj4NCg== --_000_BN1PR04MB392BC5B246BF082E0E3DCA9E24C0BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MS4mbmJzcDsgSnVzdCB0aGUgYmFzZSBVUkwgc2hvdWxk IGJlIGdvb2QuJm5ic3A7IFRoZW4gdGhlIC9TZXJ2aWNlUHJvdmlkZXJDb25maWdzLCAvUmVzb3Vy Y2VUeXBlcywgYW5kIC9TY2hlbWFzIGNhbiBiZSB1c2VkIGJhc2VkIG9uIHRoZSBTQ0lNIHNwZWMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzY2ltIFttYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5JYW4gR2xhemVyPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAxNSAyOjI5IFBNPGJyPg0K PGI+VG86PC9iPiBQaGlsIEh1bnQ8YnI+DQo8Yj5DYzo8L2I+IFNDSU0gV0c7IENodWNrIE1vcnRp bW9yZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIERpc2NvdmVyeSBzdXBwb3J0IGZv ciBTQ0lNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBsaWtlIHRoYXQg YXBwcm9hY2ggUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBTZXAgMjksIDIwMTUgYXQgMjoxMCBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNodWNrLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLiZuYnNwOyBUaGF0IHRvbyB3YXMgbXkgbWFpbiBvYmplY3RpdmUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRo ZXJlIGFueXRoaW5nIGVsc2UgdGhhdCBzaG91bGQgYmUgcmV0dXJuZWQgb3RoZXIgdGhhbiB0aGUg VVJMIGZvciB0aGUgU0NJTSBzZXJ2ZXI/Jm5ic3A7IEUuZy4gZG8gd2Ugd2FudCBhIEpTT04gc3Ry dWN0dXJlIHRoYXQgbWlnaHQgY29udmV5IG11bHRpcGxlIHBpZWNlcyBvZiBpbmZvcm1hdGlvbj8m bmJzcDsgRS5nLiBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMgYW5kIGVuZHBvaW50cy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBs ZWFuaW5nIHRvd2FyZHMganVzdCByZXR1cm5pbmcgYSBVUkwgYW5kIGtlZXBpbmcgdGhlIHJlc3Bv bnNlIHNpbXBsZSBzaW5jZSBTQ0lNIGFscmVhZHkgaGFzIGl0cyBvd24gc2VydmljZSBzcGVjaWZp YyBkaXNjb3ZlcnkgZW5kcG9pbnRzIChlLmcuIC9TZXJ2aWNlUHJvdmlkZXJDb25maWcpLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBTZXAgMjgsIDIwMTUsIGF0IDEyOjM3IFBNLCBDaHVjayBNb3J0aW1vcmUgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaGFybGllbW9ydGltb3JlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmNoYXJsaWVtb3J0aW1vcmVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSdyZSBpbnRlcmVzdGVkLCBpbiB0 aGUgc2VydmljZSBkaXNjb3ZlcnkgYXNwZWN0LiAmbmJzcDsgTGVzcyBzbyBvbiB0aGUgcHJvZmls ZSBkaXNjb3ZlcnkgLyB3ZWJmaW5nZXIgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIFNlcCAyOCwgMjAxNSBhdCAxMTo1OCBB TSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIG5vdyBNb25kYXkgYWZ0ZXIgY29t cGxldGlvbiBvZiB0aGUgU0NJTSBSRkNzIGFuZCBJIGhhdmUgYWxyZWFkeSByZWNlaXZlZCBhIG5l dyBlbmhhbmNlbWVudCByZXF1ZXN0LiZuYnNwOyBCVFcgdGhhbmtzIHRvIGV2ZXJ5b25lIGluIHRo ZSBXRyBmb3IgYWxsIHlvdXIgZWZmb3J0cyE8YnI+DQo8YnI+DQpUaGUgcmVxdWVzdCBpcyB0byBk ZWZpbmUgZGlzY292ZXJ5IGZvciBTQ0lNLiBGb3IgZXhhbXBsZSB1c2luZyB0aGUgV2VsbC1rbm93 biBtZWNoYW5pc20gKFJGQzU3ODUpIGFuZCBwb3RlbnRpYWxseSBXZWJGaW5nZXIgKFJGQzcwMzMp Ljxicj4NCjxicj4NCkZvciBleGFtcGxlLCBhIFNDSU0gY2xpZW50IG1heSBzZW5kIHRoZSBmb2xs b3dpbmcgcXVlcnk6PGJyPg0KPGJyPg0KR0VUJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmV4 YW1wbGUuY29tLy53ZWxsLWtub3duL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5l eGFtcGxlLmNvbS8ud2VsbC1rbm93bi9zY2ltPC9hPjxicj4NCjxicj4NCkZvciB3aGljaCB0aGUg c2VydmVyIG1pZ2h0IHJlc3BvbmQgd2l0aCBhIFVSTCB0byB0aGUgYXBwcm9wcmlhdGUgU0NJTSBz ZXJ2ZXIgYW5kIHBhdGggdG8gdGhlIHNlcnZlciByb290IChlLmcuICZxdW90OzxhIGhyZWY9Imh0 dHA6Ly9wcm9maWxlLmV4YW1wbGUuY29tL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5wcm9maWxlLmV4 YW1wbGUuY29tL3NjaW08L2E+4oCdKS48YnI+DQo8YnI+DQpJbiBhIG1vcmUgY29tcGxleCB2ZXJz aW9uIHdpdGggYSB3ZWJmaW5nZXIgKFJGQzcwMzMpIHF1ZXJ5Ojxicj4NCjxicj4NCkdFVCA8YSBo cmVmPSJodHRwczovL3d3dy5leGFtcGxlLmNvbS8ud2VsbC1rbm93bi93ZWJmaW5nZXI/cmVzb3Vy Y2U9YWNjdCUzQWJvYiU0MGV4YW1wbGUuY29tJmFtcDsiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL3dlYmZpbmdlcj9yZXNvdXJjZT1hY2N0JTNB Ym9iJTQwZXhhbXBsZS5jb20mYW1wOzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgcmVsPXNjaW0tcHJvZmlsZTxicj4NCjxicj4NCldoaWNoIHJlc3BvbmRzOjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7SFRUUC8xLjEgMjAwIE9LPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtB Y2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0Nv bnRlbnQtVHlwZTogYXBwbGljYXRpb24vanJkJiM0Mztqc29uPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDt7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7c3ViamVj dCZxdW90OyA6ICZxdW90OzxhIGhyZWY9Im1haWx0bzphY2N0JTNBYm9iQGV4YW1wbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YWNjdDpib2JAZXhhbXBsZS5jb208L2E+JnF1b3Q7LDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2xpbmtzJnF1b3Q7IDo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3s8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3Jl bCZxdW90OyA6IOKAnHNjaW0tcHJvZmlsZSZxdW90Oyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2hyZWYmcXVvdDsgOiAmcXVvdDs8YSBocmVmPSJo dHRwczovL3d3dy5leGFtcGxlLmNvbS9zY2lpbS9Vc2Vycy9ib2ItaWQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5leGFtcGxlLmNvbS9zY2lpbS9Vc2Vycy9ib2ItaWQ8L2E+JnF1b3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtdPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KPGJyPg0KPGJy Pg0KT3ZlcmFsbCwgSSBzZWUgYSBmZXcgZGlmZmVyZW50IHVzZS1jYXNlczo8YnI+DQo8YnI+DQox LiZuYnNwOyBBIFNDSU0gY2xpZW50IHNpbXBseSB3YW50cyB0byBrbm93IHdoZXJlIHRoZSBTQ0lN IFByb2ZpbGUgc2VydmljZSBpcyBmb3IgYSBzcGVjaWZpYyBkb21haW4gKGUuZy4NCjxhIGhyZWY9 Imh0dHA6Ly90ZW5hY3kuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+dGVuYWN5LmV4YW1w bGUuY29tPC9hPikuPGJyPg0KPGJyPg0KMi4mbmJzcDsgQSBTQ0lNIGNsaWVudCBtaWdodCBiZSBs b29raW5nIGZvciBhIHVzZXLigJlzIHByb2ZpbGUgc2VydmljZS4mbmJzcDsgU28gaXQgYXNrcyA8 YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+DQpleGFtcGxlLmNv bTwvYT4gd2hlcmUgaXMgPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBhY21lLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBhY21lLmNvbTwvYT4/Jm5ic3A7IFRoaXMgd291bGQgYmUgYSBX ZWJGaW5nZXIgc3R5bGUgcXVlcnkgYmFzZWQgb24gdGhlIHdlbGwta25vd24gZW5kcG9pbnQuIFRo ZSBzYW1lIFdlYkZpbmdlciBxdWVyeSBjb3VsZCBhbHNvIHJldHVybiB0aGUgT0lEQyBlbmRwb2lu dHMgYXMgd2VsbCBhcyB0aGUgU0NJTSBlbmRwb2ludHMNCiBmb3IgdGhlIHVzZXIuJm5ic3A7IFRo aXMgbWF5IGJlIHVzZWZ1bCBmb3IgY2FzZXMgd2hlcmUgc2VydmljZSBwcm92aWRlcnMgaGF2ZSBt dWx0aXBsZSB0ZW5hbmNpZXMgYW5kIHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIGEgZ2VuZXJpYywg dGVuYW5jeSBuZXV0cmFsIGxvb2t1cCBzZXJ2aWNlLjxicj4NCjxicj4NCjMuJm5ic3A7IEEgU0NJ TSBjbGllbnQgdGhhdCBoYXMgdGhlIHNlcnZpY2UgZW5kcG9pbnQgZm9yIGEgU2FhUyBzZXJ2aWNl IChlLmcuIENSTSwgSENNLCBGaW5hbmNlKSBtYXkgYmUgbG9va2luZyBmb3IgdGhlIHByb3Zpc2lv bmluZyBlbmRwb2ludCBhbmQgdGhlIFJlc291cmNlVHlwZSBhbmQgc2NoZW1hcyByZWxldmFudCB0 byB0aGUgYXBwbGljYXRpb24uJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlLCBhIGNsaWVudCB0aGF0 IHdhbnRzIHRvIHByb3Zpc2lvbiB0byBhIFVzZXINCiB0byBhIEZpbmFuY2Ugc3lzdGVtLCB3YW50 cyBrbm93IHdoZXJlIHRoZSBGaW5hbmNlIGFwcCBwcm92aXNpb25pbmcgZW5kcG9pbnQgaXMuJm5i c3A7IEl0IGNvdWxkIGJlIGFuIEZpbmFuY2UgU0NJTSBlbmRwb2ludCBvciBpdCBtYXkgYSBwcm9m aWxlIHNlcnZpY2UgZW5kcG9pbnQuPGJyPg0KPGJyPg0KUXVlc3Rpb25zOjxicj4NCjxicj4NCkEu IEFyZSB0aGVyZSBtZW1iZXJzIG9mIHRoZSBXRyBpbnRlcmVzdGVkIGluIHRoaXM/PGJyPg0KPGJy Pg0KQi4gRnJvbSBhIHByb3RvY29sIHN0YW5kcG9pbnQsIGl0IHNob3VsZCBub3QgbWF0dGVyIHdo ZXRoZXIgYSBjbGllbnQgaXMgdGFsa2luZyB0byBTQ0lNIHRoYXQgaXMgZGVwbG95ZWQgaW4gZnJv bnQgb2YgYSBidXNpbmVzcyBhcHBsaWNhdGlvbiAobGlrZSBDUk0sIEZpbmFuY2UpLCB2cy4gU0NJ TSBhcyBhIGdlbmVyYWwgVXNlciBwcm9maWxlIHNlcnZpY2UuIEhvd2V2ZXIsIGR1ZSB0byBwb3Nz aWJsZSBkaWZmZXJlbmNlIGluIHRoZSBoaWdoZXItbGV2ZWwNCiBsb2dpYyBvZiB0aGUgY2xpZW50 LCB3b3VsZCBpdCBiZSBpbXBvcnRhbnQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBzYXkg4oCcc2Np bS1wcm92aXNpb25pbmfigJ0gYW5kIOKAnHNjaW0tcHJvZmlsZeKAnSBhcyBkaXN0aW5jdCB0eXBl cyBvZiBzZXJ2aWNlcz8mbmJzcDsgSWYgc28sIHdoYXQgZG8gd2UgdGhpbmsgZGVmaW5lcyB0aGF0 IGRpZmZlcmVuY2U/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NClBoaWw8YnI+DQo8YnI+ DQpAaW5kZXBlbmRlbnRpZDxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j b20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxicj4NCjxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklhbiBHbGF6ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmlvciBEaXJlY3Rvciwg SWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiYjNDM7MSAyMDIgMjU1IDMxNjY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplciIg dGFyZ2V0PSJfYmxhbmsiPkBpZ2xhemVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN1PR04MB392BC5B246BF082E0E3DCA9E24C0BN1PR04MB392namprd_--