From kelly.grizzle@sailpoint.com Tue May 1 06:22:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F121E8085 for ; Tue, 1 May 2012 06:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.768 X-Spam-Level: X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CohtuhPN3A9M for ; Tue, 1 May 2012 06:22:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4772F21E8053 for ; Tue, 1 May 2012 06:22:29 -0700 (PDT) Received: from mail211-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 May 2012 13:22:21 +0000 Received: from mail211-ch1 (localhost [127.0.0.1]) by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id 3D0313E06EB; Tue, 1 May 2012 13:22:21 +0000 (UTC) X-SpamScore: -27 X-BigFish: PS-27(zz9371I936eKc85fh1458Kzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail211-ch1: domain of sailpoint.com designates 157.56.240.85 as permitted sender) client-ip=157.56.240.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 133587854034151_27044; Tue, 1 May 2012 13:22:20 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail211-ch1.bigfish.com (Postfix) with ESMTP id EEB263C0280; Tue, 1 May 2012 13:22:19 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 1 May 2012 13:22:18 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.50]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0143.004; Tue, 1 May 2012 13:22:21 +0000 From: Kelly Grizzle To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: Draft charter - v9 Thread-Index: Ac0nZmZncbCZUJEjS0OzHhA3kcqBygANwSgA Date: Tue, 1 May 2012 13:22:20 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437220C8CC3@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437220C8CC3BL2PRD0410MB351_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:22:31 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437220C8CC3BL2PRD0410MB351_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These seem reasonable to me. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mor= teza Ansari (moransar) Sent: Tuesday, May 01, 2012 1:58 AM To: scim@ietf.org Subject: [scim] Draft charter - v9 Hi folks, Thanks to Barry's help this version now has milestone dates. I think these = dates are pretty reasonable and achievable. The only change between this v= ersion and version 8.1 Barry sent on Friday is the milestone dates includin= g addition of a new document in the milestone for targeting per Phil's requ= est. Please review and send your feedback. I think we are almost done with the c= harter. Cheers, Morteza *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 *************** *** 79,91 **** Milestones ! mm/yyyy Initial adoption of SCIM use cases, as a living document ! mm/yyyy Initial adoption of SCIM core schema ! mm/yyyy Initial adoption of SCIM restful interface draft ! mm/yyyy WGLC SCIM core schema ! mm/yyyy WGLC SCIM restful interface ! mm/yyyy Initial adoption of SCIM SAML bindings draft ! mm/yyyy Initial adoption of SCIM LDAP mapping draft ! mm/yyyy WGLC SCIM SAML bindings ! mm/yyyy WGLC SCIM LDAP mapping ! mm/yyyy Re-charter discussion --- 79,95 ---- Milestones ! 06/2012 Initial adoption of SCIM use cases, as a living document ! 06/2012 Initial adoption of SCIM core schema ! 08/2012 Initial adoption of SCIM restful interface draft ! 12/2012 WGLC initial version of SCIM use cases ! 12/2012 Proposal for client targeting of SCIM endpoints ! 02/2013 WGLC SCIM core schema ! 05/2013 WGLC SCIM restful interface ! 07/2013 Initial adoption of SCIM SAML bindings draft ! 07/2013 Initial adoption of SCIM LDAP mapping draft ! 08/2013 WGLC on client targeting of SCIM endpoints ! 09/2013 Possible update of SCIM use cases ! 11/2013 WGLC SCIM SAML bindings ! 12/2013 WGLC SCIM LDAP mapping ! 01/2014 Re-charter discussion --_000_56C3C758F9D6534CA3778EAA1E0C3437220C8CC3BL2PRD0410MB351_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These seem reasonable = to me.

 

--Kelly

 

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Tuesday, May 01, 2012 1:58 AM
To: scim@ietf.org
Subject: [scim] Draft charter - v9

 

Hi folks,

 

Thanks to Barry’s help this version now has mi= lestone dates. I think these dates are pretty reasonable and achievable.&nb= sp; The only change between this version and version 8.1 Barry sent on Frid= ay is the milestone dates including addition of a new document in the milestone for targeting per Phil’s request.=

 

Please review and send your feedback. I think we are= almost done with the charter.

 

 

Cheers,

Morteza

 

*** charter8-2.txt     &nbs= p;     2012-04-27 11:32:29.000000000 -0700

--- charter9.txt  2012-04-30 06:56:43.000000000= -0700

***************

*** 79,91 ****

 

  Milestones

 

! mm/yyyy    Initial adoption of SCIM= use cases, as a living document

! mm/yyyy    Initial adoption of SCIM= core schema

! mm/yyyy    Initial adoption of SCIM= restful interface draft

! mm/yyyy    WGLC SCIM core schema

! mm/yyyy    WGLC SCIM restful interf= ace

! mm/yyyy    Initial adoption of SCIM= SAML bindings draft

! mm/yyyy    Initial adoption of SCIM= LDAP mapping draft

! mm/yyyy    WGLC SCIM SAML bindings<= o:p>

! mm/yyyy    WGLC SCIM LDAP mapping

! mm/yyyy    Re-charter discussion

--- 79,95 ----

 

  Milestones

 

! 06/2012    Initial adoption of SCIM= use cases, as a living document

! 06/2012    Initial adoption of SCIM= core schema

! 08/2012    Initial adoption of SCIM= restful interface draft

! 12/2012    WGLC initial version of = SCIM use cases

! 12/2012    Proposal for client targ= eting of SCIM endpoints

! 02/2013    WGLC SCIM core schema

! 05/2013    WGLC SCIM restful interf= ace

! 07/2013    Initial adoption of SCIM= SAML bindings draft

! 07/2013    Initial adoption of SCIM= LDAP mapping draft

! 08/2013    WGLC on client targeting= of SCIM endpoints

! 09/2013    Possible update of SCIM = use cases

! 11/2013    WGLC SCIM SAML bindings<= o:p>

! 12/2013    WGLC SCIM LDAP mapping

! 01/2014    Re-charter discussion

--_000_56C3C758F9D6534CA3778EAA1E0C3437220C8CC3BL2PRD0410MB351_-- From phil.hunt@oracle.com Tue May 1 10:52:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8D21E83E6 for ; Tue, 1 May 2012 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuKdTazlYtBU for ; Tue, 1 May 2012 10:52:04 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 021A121E8034 for ; Tue, 1 May 2012 10:52:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41Hq1T8028584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 17:52:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q41Hq0qW008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 17:52:00 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41Hpxoj030529; Tue, 1 May 2012 12:51:59 -0500 Received: from [10.2.4.191] (/64.9.249.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 10:51:59 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB76D93B-2370-4CB9-8D67-C854FEA03DF8" From: Phil Hunt In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Date: Tue, 1 May 2012 10:51:59 -0700 Message-Id: References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> To: "Morteza Ansari (moransar)" X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:52:05 -0000 --Apple-Mail=_EB76D93B-2370-4CB9-8D67-C854FEA03DF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-30, at 11:58 PM, Morteza Ansari (moransar) wrote: > Hi folks, > =20 > Thanks to Barry=92s help this version now has milestone dates. I think = these dates are pretty reasonable and achievable. The only change = between this version and version 8.1 Barry sent on Friday is the = milestone dates including addition of a new document in the milestone = for targeting per Phil=92s request. > =20 > Please review and send your feedback. I think we are almost done with = the charter. > =20 > =20 > Cheers, > Morteza > =20 > *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 > --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 > *************** > *** 79,91 **** > =20 > Milestones > =20 > ! mm/yyyy Initial adoption of SCIM use cases, as a living document > ! mm/yyyy Initial adoption of SCIM core schema > ! mm/yyyy Initial adoption of SCIM restful interface draft > ! mm/yyyy WGLC SCIM core schema > ! mm/yyyy WGLC SCIM restful interface > ! mm/yyyy Initial adoption of SCIM SAML bindings draft > ! mm/yyyy Initial adoption of SCIM LDAP mapping draft > ! mm/yyyy WGLC SCIM SAML bindings > ! mm/yyyy WGLC SCIM LDAP mapping > ! mm/yyyy Re-charter discussion > --- 79,95 ---- > =20 > Milestones > =20 > ! 06/2012 Initial adoption of SCIM use cases, as a living document > ! 06/2012 Initial adoption of SCIM core schema > ! 08/2012 Initial adoption of SCIM restful interface draft > ! 12/2012 WGLC initial version of SCIM use cases > ! 12/2012 Proposal for client targeting of SCIM endpoints > ! 02/2013 WGLC SCIM core schema > ! 05/2013 WGLC SCIM restful interface > ! 07/2013 Initial adoption of SCIM SAML bindings draft > ! 07/2013 Initial adoption of SCIM LDAP mapping draft > ! 08/2013 WGLC on client targeting of SCIM endpoints > ! 09/2013 Possible update of SCIM use cases > ! 11/2013 WGLC SCIM SAML bindings > ! 12/2013 WGLC SCIM LDAP mapping > ! 01/2014 Re-charter discussion > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_EB76D93B-2370-4CB9-8D67-C854FEA03DF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

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





On 2012-04-30, at 11:58 PM, Morteza Ansari (moransar) = wrote:

Hi folks,
 
Thanks to Barry=92s help this = version now has milestone dates. I think these dates are pretty = reasonable and achievable.  The only change between this version = and version 8.1 Barry sent on Friday is the milestone dates including = addition of a new document in the milestone for targeting per Phil=92s = request.
 
Please review and send your feedback. I think we are = almost done with the charter.
 
Cheers,
Morteza
*** = charter8-2.txt          = 2012-04-27 11:32:29.000000000 -0700
--- charter9.txt  2012-04-30 06:56:43.000000000 = -0700
***************
*** 79,91 ****
 
! mm/yyyy    Initial adoption of SCIM use = cases, as a living document
! = mm/yyyy    Initial adoption of SCIM core = schema
! mm/yyyy    Initial adoption of = SCIM restful interface draft
! = mm/yyyy    WGLC SCIM core schema
! mm/yyyy    WGLC SCIM restful = interface
! mm/yyyy    Initial = adoption of SCIM SAML bindings draft
! mm/yyyy    Initial adoption of SCIM LDAP = mapping draft
! mm/yyyy    = WGLC SCIM SAML bindings
! mm/yyyy    = WGLC SCIM LDAP mapping
! mm/yyyy    = Re-charter discussion
--- 79,95 = ----
 
 
! 06/2012    Initial adoption of SCIM use = cases, as a living document
! = 06/2012    Initial adoption of SCIM core = schema
! 08/2012    Initial adoption of = SCIM restful interface draft
! = 12/2012    WGLC initial version of SCIM use = cases
! 12/2012    Proposal for client = targeting of SCIM endpoints
! = 02/2013    WGLC SCIM core schema
! 05/2013    WGLC SCIM restful = interface
! 07/2013    Initial = adoption of SCIM SAML bindings draft
! 07/2013    Initial adoption of SCIM LDAP = mapping draft
! 08/2013    = WGLC on client targeting of SCIM endpoints
! 09/2013    Possible update of SCIM use = cases
! 11/2013    WGLC SCIM SAML = bindings
! 12/2013    WGLC = SCIM LDAP mapping
! 01/2014    = Re-charter = discussion
<charter9.txt>________= _______________________________________
scim mailing list
scim@ietf.org
X-Gm-Message-State: ALoCoQkVM3C9/EAfUOxV6UTOHabWRWLJOEeP1/kOqQvv5Sf6E1y7YQESAyMdGwYUgzEVUnNIiXup Cc: "" Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:55:58 -0000 --Apple-Mail-6AC276E3-5669-4982-9BEE-5D346311B729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sounds like a plan +1 On Apr 30, 2012, at 11:58 PM, "Morteza Ansari (moransar)" wrote: > Hi folks, > =20 > Thanks to Barry=E2=80=99s help this version now has milestone dates. I thi= nk these dates are pretty reasonable and achievable. The only change betwee= n this version and version 8.1 Barry sent on Friday is the milestone dates i= ncluding addition of a new document in the milestone for targeting per Phil=E2= =80=99s request. > =20 > Please review and send your feedback. I think we are almost done with the c= harter. > =20 > =20 > Cheers, > Morteza > =20 > *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 > --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 > *************** > *** 79,91 **** > =20 > Milestones > =20 > ! mm/yyyy Initial adoption of SCIM use cases, as a living document > ! mm/yyyy Initial adoption of SCIM core schema > ! mm/yyyy Initial adoption of SCIM restful interface draft > ! mm/yyyy WGLC SCIM core schema > ! mm/yyyy WGLC SCIM restful interface > ! mm/yyyy Initial adoption of SCIM SAML bindings draft > ! mm/yyyy Initial adoption of SCIM LDAP mapping draft > ! mm/yyyy WGLC SCIM SAML bindings > ! mm/yyyy WGLC SCIM LDAP mapping > ! mm/yyyy Re-charter discussion > --- 79,95 ---- > =20 > Milestones > =20 > ! 06/2012 Initial adoption of SCIM use cases, as a living document > ! 06/2012 Initial adoption of SCIM core schema > ! 08/2012 Initial adoption of SCIM restful interface draft > ! 12/2012 WGLC initial version of SCIM use cases > ! 12/2012 Proposal for client targeting of SCIM endpoints > ! 02/2013 WGLC SCIM core schema > ! 05/2013 WGLC SCIM restful interface > ! 07/2013 Initial adoption of SCIM SAML bindings draft > ! 07/2013 Initial adoption of SCIM LDAP mapping draft > ! 08/2013 WGLC on client targeting of SCIM endpoints > ! 09/2013 Possible update of SCIM use cases > ! 11/2013 WGLC SCIM SAML bindings > ! 12/2013 WGLC SCIM LDAP mapping > ! 01/2014 Re-charter discussion > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-6AC276E3-5669-4982-9BEE-5D346311B729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Sounds like a plan +1
<= br>


Hi folks,

 

Thanks to Barry=E2=80=99s help this version now has m= ilestone dates. I think these dates are pretty reasonable and achievable.&nb= sp; The only change between this version and version 8.1 Barry sent on Frida= y is the milestone dates including addition of a new document in the milesto= ne for targeting per Phil=E2=80=99s request.

 

Please review and send you= r feedback. I think we are almost done with the charter.

 

 

Cheers,

M= orteza

 

*** charter8-2.txt =           2012-04-27 11:32:29.0= 00000000 -0700

--- charter9.txt  2= 012-04-30 06:56:43.000000000 -0700

****= ***********

*** 79,91 ****

 

 =  Milestones

 

=

! mm/yyyy    Initial adoption of SCIM u= se cases, as a living document

! mm/yyy= y    Initial adoption of SCIM core schema

! mm/yyyy    Initial adoption of SCIM restf= ul interface draft

! mm/yyyy  = ;  WGLC SCIM core schema

! mm/yyyy=     WGLC SCIM restful interface

! mm/yyyy    Initial adoption of SCIM SAML bindings d= raft

! mm/yyyy    Initia= l adoption of SCIM LDAP mapping draft

!= mm/yyyy    WGLC SCIM SAML bindings

! mm/yyyy    WGLC SCIM LDAP mapping

! mm/yyyy    Re-charter discussion

--- 79,95 ----

 

  Mileston= es

 

! 06/2012    Initial adoption of SCIM use cases, as a= living document

! 06/2012  &= nbsp; Initial adoption of SCIM core schema

! 08/2012    Initial adoption of SCIM restful interface d= raft

! 12/2012    WGLC i= nitial version of SCIM use cases

! 12/2= 012    Proposal for client targeting of SCIM endpoints

! 02/2013    WGLC SCIM core sc= hema

! 05/2013    WGLC S= CIM restful interface

! 07/2013 &n= bsp;  Initial adoption of SCIM SAML bindings draft

! 07/2013    Initial adoption of SCIM LDAP m= apping draft

! 08/2013   = ; WGLC on client targeting of SCIM endpoints

! 09/2013    Possible update of SCIM use cases

! 11/2013    WGLC SCIM SAML bind= ings

! 12/2013    WGLC S= CIM LDAP mapping

! 01/2014  &= nbsp; Re-charter discussion

<charter9.txt>
_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
= --Apple-Mail-6AC276E3-5669-4982-9BEE-5D346311B729-- From igor.faynberg@alcatel-lucent.com Tue May 1 10:58:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595C321E83FC for ; Tue, 1 May 2012 10:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.349 X-Spam-Level: X-Spam-Status: No, score=-7.349 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+cYVImQFe0V for ; Tue, 1 May 2012 10:58:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2A921E8409 for ; Tue, 1 May 2012 10:58:40 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q41HwbPk011140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 May 2012 12:58:37 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q41Hwbre022837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 May 2012 12:58:37 -0500 Received: from [135.244.24.130] (faynberg.lra.lucent.com [135.244.24.130]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q41Hwa2W015423; Tue, 1 May 2012 12:58:36 -0500 (CDT) Message-ID: <4FA0244C.2060504@alcatel-lucent.com> Date: Tue, 01 May 2012 13:58:36 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Content-Type: multipart/alternative; boundary="------------050503020501050602070101" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:58:42 -0000 This is a multi-part message in MIME format. --------------050503020501050602070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Igor On 5/1/2012 2:58 AM, Morteza Ansari (moransar) wrote: > > Hi folks, > > Thanks to Barry's help this version now has milestone dates. I think > these dates are pretty reasonable and achievable. The only change > between this version and version 8.1 Barry sent on Friday is the > milestone dates including addition of a new document in the milestone > for targeting per Phil's request. > > Please review and send your feedback. I think we are almost done with > the charter. > > Cheers, > > Morteza > > *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 > > --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 > > *************** > > *** 79,91 **** > > Milestones > > ! mm/yyyy Initial adoption of SCIM use cases, as a living document > > ! mm/yyyy Initial adoption of SCIM core schema > > ! mm/yyyy Initial adoption of SCIM restful interface draft > > ! mm/yyyy WGLC SCIM core schema > > ! mm/yyyy WGLC SCIM restful interface > > ! mm/yyyy Initial adoption of SCIM SAML bindings draft > > ! mm/yyyy Initial adoption of SCIM LDAP mapping draft > > ! mm/yyyy WGLC SCIM SAML bindings > > ! mm/yyyy WGLC SCIM LDAP mapping > > ! mm/yyyy Re-charter discussion > > --- 79,95 ---- > > Milestones > > ! 06/2012 Initial adoption of SCIM use cases, as a living document > > ! 06/2012 Initial adoption of SCIM core schema > > ! 08/2012 Initial adoption of SCIM restful interface draft > > ! 12/2012 WGLC initial version of SCIM use cases > > ! 12/2012 Proposal for client targeting of SCIM endpoints > > ! 02/2013 WGLC SCIM core schema > > ! 05/2013 WGLC SCIM restful interface > > ! 07/2013 Initial adoption of SCIM SAML bindings draft > > ! 07/2013 Initial adoption of SCIM LDAP mapping draft > > ! 08/2013 WGLC on client targeting of SCIM endpoints > > ! 09/2013 Possible update of SCIM use cases > > ! 11/2013 WGLC SCIM SAML bindings > > ! 12/2013 WGLC SCIM LDAP mapping > > ! 01/2014 Re-charter discussion > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------050503020501050602070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Igor

On 5/1/2012 2:58 AM, Morteza Ansari (moransar) wrote:

Hi folks,

 

Thanks to Barry’s help this version now has milestone dates. I think these dates are pretty reasonable and achievable.  The only change between this version and version 8.1 Barry sent on Friday is the milestone dates including addition of a new document in the milestone for targeting per Phil’s request.

 

Please review and send your feedback. I think we are almost done with the charter.

 

 

Cheers,

Morteza

 

*** charter8-2.txt           2012-04-27 11:32:29.000000000 -0700

--- charter9.txt  2012-04-30 06:56:43.000000000 -0700

***************

*** 79,91 ****

 

  Milestones

 

! mm/yyyy    Initial adoption of SCIM use cases, as a living document

! mm/yyyy    Initial adoption of SCIM core schema

! mm/yyyy    Initial adoption of SCIM restful interface draft

! mm/yyyy    WGLC SCIM core schema

! mm/yyyy    WGLC SCIM restful interface

! mm/yyyy    Initial adoption of SCIM SAML bindings draft

! mm/yyyy    Initial adoption of SCIM LDAP mapping draft

! mm/yyyy    WGLC SCIM SAML bindings

! mm/yyyy    WGLC SCIM LDAP mapping

! mm/yyyy    Re-charter discussion

--- 79,95 ----

 

  Milestones

 

! 06/2012    Initial adoption of SCIM use cases, as a living document

! 06/2012    Initial adoption of SCIM core schema

! 08/2012    Initial adoption of SCIM restful interface draft

! 12/2012    WGLC initial version of SCIM use cases

! 12/2012    Proposal for client targeting of SCIM endpoints

! 02/2013    WGLC SCIM core schema

! 05/2013    WGLC SCIM restful interface

! 07/2013    Initial adoption of SCIM SAML bindings draft

! 07/2013    Initial adoption of SCIM LDAP mapping draft

! 08/2013    WGLC on client targeting of SCIM endpoints

! 09/2013    Possible update of SCIM use cases

! 11/2013    WGLC SCIM SAML bindings

! 12/2013    WGLC SCIM LDAP mapping

! 01/2014    Re-charter discussion


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------050503020501050602070101-- From melinda.shore@gmail.com Tue May 1 11:02:51 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D75821E840E for ; Tue, 1 May 2012 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyHJJF6-JwW for ; Tue, 1 May 2012 11:02:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8198621E83FC for ; Tue, 1 May 2012 11:02:50 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2435721ghb.31 for ; Tue, 01 May 2012 11:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=boTNs+kIUFB4M4ei9T3FfdykT8FtwoB8q/5VMoeHUBg=; b=nybu8uk3lXiCQg0Wp+OqI7rRPoanERTTen3pkfM+g9AmcHSZpTY6eTbCfDbgE00OT7 H9RP7bHD7gjoYo/w7ExLWnrH/8SxLErFM5M66nSYW/JIWqEoqf+mxLtZWrY8vslJzZg4 qTF3mwvWa7x/HKpEn7fJM/qxSZYXQEHQf0aXhGvR5tiuK1M8Tk7V4BjnJ68WxrI7wpZQ NDJIvaem+yxLAST3uFSvJBnadgYkC6WrYUPARCluFN3gLXYcy5GBn977dv0GC69DKVlZ O7yziot7kQI1y7KN/MhgDEzR8Ye/7P3RZHiOO+LedNdIBLoQPyHhFzMIHQYfwEexlbwy lX+Q== Received: by 10.68.238.201 with SMTP id vm9mr7326142pbc.155.1335895369780; Tue, 01 May 2012 11:02:49 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id ib1sm5182099pbc.13.2012.05.01.11.02.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 11:02:49 -0700 (PDT) Message-ID: <4FA02547.5050502@gmail.com> Date: Tue, 01 May 2012 10:02:47 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> <4FA0244C.2060504@alcatel-lucent.com> In-Reply-To: <4FA0244C.2060504@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:02:51 -0000 This schedule looks doable. Melinda From Chris.Phillips@canarie.ca Tue May 1 11:26:41 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75E121E83E6 for ; Tue, 1 May 2012 11:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e4KK2WkgSbW for ; Tue, 1 May 2012 11:26:41 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00B21E8034 for ; Tue, 1 May 2012 11:26:40 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Tue, 1 May 2012 14:26:40 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Tue, 1 May 2012 14:26:37 -0400 Thread-Topic: [scim] Draft charter - v9 Thread-Index: Ac0nx/MtRTTHKXNyRZKssF9ew+z1Uw== Message-ID: In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBC5A2C19B018chrisphillipscanarieca_" MIME-Version: 1.0 Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:26:42 -0000 --_000_CBC5A2C19B018chrisphillipscanarieca_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 from here, looks reasonable. Chris. From: "Morteza Ansari (moransar)" > Date: Tue, 1 May 2012 02:58:02 -0400 To: "scim@ietf.org" > Subject: [scim] Draft charter - v9 Hi folks, Thanks to Barry=92s help this version now has milestone dates. I think thes= e dates are pretty reasonable and achievable. The only change between this= version and version 8.1 Barry sent on Friday is the milestone dates includ= ing addition of a new document in the milestone for targeting per Phil=92s = request. Please review and send your feedback. I think we are almost done with the c= harter. Cheers, Morteza *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 *************** *** 79,91 **** Milestones ! mm/yyyy Initial adoption of SCIM use cases, as a living document ! mm/yyyy Initial adoption of SCIM core schema ! mm/yyyy Initial adoption of SCIM restful interface draft ! mm/yyyy WGLC SCIM core schema ! mm/yyyy WGLC SCIM restful interface ! mm/yyyy Initial adoption of SCIM SAML bindings draft ! mm/yyyy Initial adoption of SCIM LDAP mapping draft ! mm/yyyy WGLC SCIM SAML bindings ! mm/yyyy WGLC SCIM LDAP mapping ! mm/yyyy Re-charter discussion --- 79,95 ---- Milestones ! 06/2012 Initial adoption of SCIM use cases, as a living document ! 06/2012 Initial adoption of SCIM core schema ! 08/2012 Initial adoption of SCIM restful interface draft ! 12/2012 WGLC initial version of SCIM use cases ! 12/2012 Proposal for client targeting of SCIM endpoints ! 02/2013 WGLC SCIM core schema ! 05/2013 WGLC SCIM restful interface ! 07/2013 Initial adoption of SCIM SAML bindings draft ! 07/2013 Initial adoption of SCIM LDAP mapping draft ! 08/2013 WGLC on client targeting of SCIM endpoints ! 09/2013 Possible update of SCIM use cases ! 11/2013 WGLC SCIM SAML bindings ! 12/2013 WGLC SCIM LDAP mapping ! 01/2014 Re-charter discussion --_000_CBC5A2C19B018chrisphillipscanarieca_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1 from here, looks reasona= ble.

Chris.

From: "Morteza Ansari (moransar)" &= lt;moransar@cisco.com>
Date: Tue, 1 May 2012 02:58:02 -0400To: "scim@ietf.org" <sci= m@ietf.org>
Subject: [sc= im] Draft charter - v9

<= meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">

Hi folks,

 

Thanks to Barry=92s help this version now has milestone dates. I think = these dates are pretty reasonable and achievable.  The only change bet= ween this version and version 8.1 Barry sent on Friday is the milestone dat= es including addition of a new document in the milestone for targeting per = Phil=92s request.

 

Please review and send your feedback. I think we ar= e almost done with the charter.

&= nbsp;

 

Cheers,

Morteza

 =

*** charter8-2.txt    =        2012-04-27 11:32:29.000000000 -0700

--- charter9.txt  2012-04-30 06:56:= 43.000000000 -0700

***************

*** 79,91 ****

 

  Milesto= nes

 

! mm/yyyy    Initial adoption of SCIM use cases, = as a living document

! mm/yyyy &n= bsp;  Initial adoption of SCIM core schema

! mm/yyyy    Initial adoption of SCIM restful inte= rface draft

! mm/yyyy   = ; WGLC SCIM core schema

! mm/yyyy = ;   WGLC SCIM restful interface

! mm/yyyy    Initial adoption of SCIM SAML bindings draf= t

! mm/yyyy    Initial = adoption of SCIM LDAP mapping draft

! = mm/yyyy    WGLC SCIM SAML bindings

! mm/yyyy    WGLC SCIM LDAP mapping

! mm/yyyy    Re-charter discussion<= o:p>

--- 79,95 ----

 

  Mil= estones

 

! 06/2012    Initial adoption of SCIM use cas= es, as a living document

! 06/2012&nbs= p;   Initial adoption of SCIM core schema

! 08/2012    Initial adoption of SCIM restful= interface draft

! 12/2012  =   WGLC initial version of SCIM use cases

! 12/2012    Proposal for client targeting of SCIM e= ndpoints

! 02/2013    W= GLC SCIM core schema

! 05/2013 &n= bsp;  WGLC SCIM restful interface

! 07/2013    Initial adoption of SCIM SAML bindings draft

! 07/2013    Initial ado= ption of SCIM LDAP mapping draft

! 08/= 2013    WGLC on client targeting of SCIM endpoints

! 09/2013    Possible update of = SCIM use cases

! 11/2013  &n= bsp; WGLC SCIM SAML bindings

! 12/2013=     WGLC SCIM LDAP mapping

! 01/2014    Re-charter discussion

<= /div>
--_000_CBC5A2C19B018chrisphillipscanarieca_-- From samuel@erdtman.se Tue May 1 11:32:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD23921F8881 for ; Tue, 1 May 2012 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa7aZqEJbHPx for ; Tue, 1 May 2012 11:32:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF6021F887E for ; Tue, 1 May 2012 11:32:52 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so311906lbb.31 for ; Tue, 01 May 2012 11:32:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=w77HRjIT8TCibVaVjakk+d6slQhwd22D/AJU740n6VA=; b=lYLZbipPB/lKJ8bCjZwSN2NZIcz4mCccLRfCX8Uk55SKb995bBPeO20LHeCx4yh6pS X/dkdTLoYyM8yTWOm8ktulFHypJA3HF/ojycQeLhQsVJS/o0m8k9UpOOE1F9IMW9j9+m s8s8CjvV2msYMXg9dM1T8tpfxkqHAsboE35AnhCFO40Lo2J4ccLE0cprh3XW/w19Jg5W lR5qwOSqDGrFQYNUtNQF0TLkX8bwb3RRZpj7T8cNPkvOYhk285BMnfO5behK0oG5D5eI 3nvxwqBLI/HSyw2fn/SvV1AmgW5clDqUgXUqnMGLObCLNlT1JIWVuPh/SH9T8pxOCKFN uhEg== MIME-Version: 1.0 Received: by 10.112.28.131 with SMTP id b3mr6888084lbh.63.1335897171868; Tue, 01 May 2012 11:32:51 -0700 (PDT) Received: by 10.112.115.166 with HTTP; Tue, 1 May 2012 11:32:51 -0700 (PDT) In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Date: Tue, 1 May 2012 20:32:51 +0200 Message-ID: From: Samuel Erdtman To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnGFiSufoa2uHwpHbBoSNRZs1fU6WeRnEy8C8dhQ7pjrIBQ3TM4iT6R8cqoILgBmVFr7KwD Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:32:54 -0000 +1 On Tue, May 1, 2012 at 8:58 AM, Morteza Ansari (moransar) wrote: > Hi folks, > > > > Thanks to Barry=92s help this version now has milestone dates. I think th= ese > dates are pretty reasonable and achievable.=A0 The only change between th= is > version and version 8.1 Barry sent on Friday is the milestone dates > including addition of a new document in the milestone for targeting per > Phil=92s request. > > > > Please review and send your feedback. I think we are almost done with the > charter. > > > > > > Cheers, > > Morteza > > > > *** charter8-2.txt=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2012-04-27 11:32:29.0000= 00000 -0700 > > --- charter9.txt=A0 2012-04-30 06:56:43.000000000 -0700 > > *************** > > *** 79,91 **** > > > > =A0=A0Milestones > > > > ! mm/yyyy=A0=A0=A0 Initial adoption of SCIM use cases, as a living docume= nt > > ! mm/yyyy=A0=A0=A0 Initial adoption of SCIM core schema > > ! mm/yyyy=A0=A0=A0 Initial adoption of SCIM restful interface draft > > ! mm/yyyy=A0=A0=A0 WGLC SCIM core schema > > ! mm/yyyy=A0=A0=A0 WGLC SCIM restful interface > > ! mm/yyyy=A0=A0=A0 Initial adoption of SCIM SAML bindings draft > > ! mm/yyyy=A0=A0=A0 Initial adoption of SCIM LDAP mapping draft > > ! mm/yyyy=A0=A0=A0 WGLC SCIM SAML bindings > > ! mm/yyyy=A0=A0=A0 WGLC SCIM LDAP mapping > > ! mm/yyyy=A0=A0=A0 Re-charter discussion > > --- 79,95 ---- > > > > =A0=A0Milestones > > > > ! 06/2012=A0=A0=A0 Initial adoption of SCIM use cases, as a living docume= nt > > ! 06/2012=A0=A0=A0 Initial adoption of SCIM core schema > > ! 08/2012=A0=A0=A0 Initial adoption of SCIM restful interface draft > > ! 12/2012=A0=A0=A0 WGLC initial version of SCIM use cases > > ! 12/2012=A0=A0=A0 Proposal for client targeting of SCIM endpoints > > ! 02/2013=A0=A0=A0 WGLC SCIM core schema > > ! 05/2013=A0=A0=A0 WGLC SCIM restful interface > > ! 07/2013=A0=A0=A0 Initial adoption of SCIM SAML bindings draft > > ! 07/2013=A0=A0=A0 Initial adoption of SCIM LDAP mapping draft > > ! 08/2013=A0=A0=A0 WGLC on client targeting of SCIM endpoints > > ! 09/2013=A0=A0=A0 Possible update of SCIM use cases > > ! 11/2013=A0=A0=A0 WGLC SCIM SAML bindings > > ! 12/2013=A0=A0=A0 WGLC SCIM LDAP mapping > > ! 01/2014=A0=A0=A0 Re-charter discussion > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From prvs=4468019529=erik.wahlstrom@nexussafe.com Tue May 1 11:48:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73821E822A for ; Tue, 1 May 2012 11:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s55PkSgBUfa6 for ; Tue, 1 May 2012 11:48:43 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C621E8088 for ; Tue, 1 May 2012 11:48:42 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 1 May 2012 20:20:44 +0200 Received: from MARVMAILDB.technxs.com ([fe80::93a:970c:f043:1455]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 1 May 2012 20:20:45 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: "Morteza Ansari (moransar)" Thread-Topic: [scim] Draft charter - v9 Thread-Index: Ac0nZmZncbCZUJEjS0OzHhA3kcqBygAT96oA Date: Tue, 1 May 2012 18:20:45 +0000 Message-ID: <3ACDF880-9595-4F3E-9E00-4D4737C18745@nexussafe.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: multipart/alternative; boundary="_000_3ACDF88095954F3E9E004D4737C18745nexussafecom_" MIME-Version: 1.0 Cc: "" Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:48:44 -0000 --_000_3ACDF88095954F3E9E004D4737C18745nexussafecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 On Apr 30, 2012, at 11:58 PM, Morteza Ansari (moransar) wrote: Hi folks, Thanks to Barry=92s help this version now has milestone dates. I think thes= e dates are pretty reasonable and achievable. The only change between this= version and version 8.1 Barry sent on Friday is the milestone dates includ= ing addition of a new document in the milestone for targeting per Phil=92s = request. Please review and send your feedback. I think we are almost done with the c= harter. Cheers, Morteza *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 *************** *** 79,91 **** Milestones ! mm/yyyy Initial adoption of SCIM use cases, as a living document ! mm/yyyy Initial adoption of SCIM core schema ! mm/yyyy Initial adoption of SCIM restful interface draft ! mm/yyyy WGLC SCIM core schema ! mm/yyyy WGLC SCIM restful interface ! mm/yyyy Initial adoption of SCIM SAML bindings draft ! mm/yyyy Initial adoption of SCIM LDAP mapping draft ! mm/yyyy WGLC SCIM SAML bindings ! mm/yyyy WGLC SCIM LDAP mapping ! mm/yyyy Re-charter discussion --- 79,95 ---- Milestones ! 06/2012 Initial adoption of SCIM use cases, as a living document ! 06/2012 Initial adoption of SCIM core schema ! 08/2012 Initial adoption of SCIM restful interface draft ! 12/2012 WGLC initial version of SCIM use cases ! 12/2012 Proposal for client targeting of SCIM endpoints ! 02/2013 WGLC SCIM core schema ! 05/2013 WGLC SCIM restful interface ! 07/2013 Initial adoption of SCIM SAML bindings draft ! 07/2013 Initial adoption of SCIM LDAP mapping draft ! 08/2013 WGLC on client targeting of SCIM endpoints ! 09/2013 Possible update of SCIM use cases ! 11/2013 WGLC SCIM SAML bindings ! 12/2013 WGLC SCIM LDAP mapping ! 01/2014 Re-charter discussion _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_3ACDF88095954F3E9E004D4737C18745nexussafecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <72AF919D8D321C4EBB1BFC9EC955E62A@nexussafe.com> Content-Transfer-Encoding: quoted-printable +1

On Apr 30, 2012, at 11:58 PM, Morteza Ansari (moransar) wrote:

Hi folks,
 
Thanks to Barry=92s help this version now has milestone dates. I think thes= e dates are pretty reasonable and achievable.  The only change between= this version and version 8.1 Barry sent on Friday is the milestone dates i= ncluding addition of a new document in the milestone for targeting per Phil=92s request.
 
Please review and send your feedback. I think we are almost done with the c= harter.
 
 
Cheers,
Morteza
 
*** charter8-2.txt         &nb= sp; 2012-04-27 11:32:29.000000000 -0700
--- charter9.txt  2012-04-30 06:56:43.000000000 -0700
***************
*** 79,91 ****
 
  Milestones
 
! mm/yyyy    Initial adoption of SCIM use cases, as a living= document
! mm/yyyy    Initial adoption of SCIM core schema=
! mm/yyyy    Initial adoption of SCIM restful interface draf= t
! mm/yyyy    WGLC SCIM core schema
! mm/yyyy    WGLC SCIM restful interface
! mm/yyyy    Initial adoption of SCIM SAML bindings draft
! mm/yyyy    Initial adoption of SCIM LDAP mapping draft
! mm/yyyy    WGLC SCIM SAML bindings
! mm/yyyy    WGLC SCIM LDAP mapping
! mm/yyyy    Re-charter discussion
--- 79,95 ----
 
  Milestones
 
! 06/2012    Initial adoption of SCIM use cases, as a living= document
! 06/2012    Initial adoption of SCIM core schema=
! 08/2012    Initial adoption of SCIM restful interface draf= t
! 12/2012    WGLC initial version of SCIM use cases
! 12/2012    Proposal for client targeting of SCIM endpoints=
! 02/2013    WGLC SCIM core schema
! 05/2013    WGLC SCIM restful interface
! 07/2013    Initial adoption of SCIM SAML bindings draft
! 07/2013    Initial adoption of SCIM LDAP mapping draft
! 08/2013    WGLC on client targeting of SCIM endpoints=
! 09/2013    Possible update of SCIM use cases
! 11/2013    WGLC SCIM SAML bindings
! 12/2013    WGLC SCIM LDAP mapping
! 01/2014    Re-charter discussion
<charter9.txt>__________________________________________= _____
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= /a>

--_000_3ACDF88095954F3E9E004D4737C18745nexussafecom_-- From mmorrow@cisco.com Tue May 1 13:35:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC811E8076 for ; Tue, 1 May 2012 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.726 X-Spam-Level: X-Spam-Status: No, score=-9.726 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7+qFC0qdyMU for ; Tue, 1 May 2012 13:35:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F063E11E8074 for ; Tue, 1 May 2012 13:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmorrow@cisco.com; l=6186; q=dns/txt; s=iport; t=1335904513; x=1337114113; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=qET3lm2VRKbr3XrGxrE3oyIdXD3eBTTlAh+S4SdpzGk=; b=bf0J/a8+cEokFOryY1gXKvdw+fWgdU5RkEVmgcwWKO8i+EVtnVn+2+SD 4gRBNSXssin0wlAbZi25zrUmTK2SQFFLsZ/w+vaQjwpqQEz/8ui1nloIW pCqfr5nHuyDYBY8bFRCCTFX622mbJvjWYN6zlCN4nrmtBVKYNByHrz4Fi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAF1IoE+Q/khN/2dsb2JhbABEgkatM4F7gQaBB4IJAQEBAwEBAQEPASoxEA0BCG0wAQEEARIih2YFC5ofnzgEkQkEiDA0jRqOWYFpgwg X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208,217";a="136737420" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 May 2012 20:35:11 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q41KZBK6028481 for ; Tue, 1 May 2012 20:35:11 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 22:35:11 +0200 Received: from 10.155.56.70 ([10.155.56.70]) by XMB-AMS-110.cisco.com ([144.254.74.85]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 May 2012 20:35:11 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 01 May 2012 12:26:47 -0700 From: Monique Morrow To: "Morteza Ansari (moransar)" , Message-ID: Thread-Topic: [scim] Draft charter - v9 Thread-Index: Ac0nZmZncbCZUJEjS0OzHhA3kcqBygAafL94 In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3418724110_1198295" X-OriginalArrivalTime: 01 May 2012 20:35:11.0667 (UTC) FILETIME=[E7F63030:01CD27D9] Subject: Re: [scim] Draft charter - v9 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 20:35:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3418724110_1198295 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 from this end ! Monique On 4/30/12 11:58 PM, "Morteza Ansari (moransar)" wrote= : > Hi folks, > =20 > Thanks to Barry=B9s help this version now has milestone dates. I think thes= e > dates are pretty reasonable and achievable. The only change between this > version and version 8.1 Barry sent on Friday is the milestone dates inclu= ding > addition of a new document in the milestone for targeting per Phil=B9s requ= est. > =20 > Please review and send your feedback. I think we are almost done with the > charter. > =20 > =20 > Cheers, >=20 > Morteza > =20 > *** charter8-2.txt 2012-04-27 11:32:29.000000000 -0700 > --- charter9.txt 2012-04-30 06:56:43.000000000 -0700 > *************** > *** 79,91 **** > =20 > Milestones > =20 > ! mm/yyyy Initial adoption of SCIM use cases, as a living document > ! mm/yyyy Initial adoption of SCIM core schema > ! mm/yyyy Initial adoption of SCIM restful interface draft > ! mm/yyyy WGLC SCIM core schema > ! mm/yyyy WGLC SCIM restful interface > ! mm/yyyy Initial adoption of SCIM SAML bindings draft > ! mm/yyyy Initial adoption of SCIM LDAP mapping draft > ! mm/yyyy WGLC SCIM SAML bindings > ! mm/yyyy WGLC SCIM LDAP mapping > ! mm/yyyy Re-charter discussion > --- 79,95 ---- > =20 > Milestones > =20 > ! 06/2012 Initial adoption of SCIM use cases, as a living document > ! 06/2012 Initial adoption of SCIM core schema > ! 08/2012 Initial adoption of SCIM restful interface draft > ! 12/2012 WGLC initial version of SCIM use cases > ! 12/2012 Proposal for client targeting of SCIM endpoints > ! 02/2013 WGLC SCIM core schema > ! 05/2013 WGLC SCIM restful interface > ! 07/2013 Initial adoption of SCIM SAML bindings draft > ! 07/2013 Initial adoption of SCIM LDAP mapping draft > ! 08/2013 WGLC on client targeting of SCIM endpoints > ! 09/2013 Possible update of SCIM use cases > ! 11/2013 WGLC SCIM SAML bindings > ! 12/2013 WGLC SCIM LDAP mapping > ! 01/2014 Re-charter discussion >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --B_3418724110_1198295 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [scim] Draft charter - v9 +1 from this end !

Monique


On 4/30/12 11:58 PM, "Morteza Ansari (moransar)" <moransar@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi folks,
 
Thanks to Barry’s help this version now has milestone dates. I think = these dates are pretty reasonable and achievable.  The only change betw= een this version and version 8.1 Barry sent on Friday is the milestone dates= including addition of a new document in the milestone for targeting per Phi= l’s request.
 
Please review and send your feedback. I think we are almost done with the c= harter.
 
 
Cheers,

Morteza
 
*** charter8-2.txt          &n= bsp;2012-04-27 11:32:29.000000000 -0700
--- charter9.txt  2012-04-30 06:56:43.000000000 -0700
***************
*** 79,91 ****
  
  Milestones
  
! mm/yyyy    Initial adoption of SCIM use cases, as a living= document
! mm/yyyy    Initial adoption of SCIM core schema
! mm/yyyy    Initial adoption of SCIM restful interface draf= t
! mm/yyyy    WGLC SCIM core schema
! mm/yyyy    WGLC SCIM restful interface
! mm/yyyy    Initial adoption of SCIM SAML bindings draft ! mm/yyyy    Initial adoption of SCIM LDAP mapping draft
! mm/yyyy    WGLC SCIM SAML bindings
! mm/yyyy    WGLC SCIM LDAP mapping
! mm/yyyy    Re-charter discussion
--- 79,95 ----
  
  Milestones
  
! 06/2012    Initial adoption of SCIM use cases, as a living= document
! 06/2012    Initial adoption of SCIM core schema
! 08/2012    Initial adoption of SCIM restful interface draf= t
! 12/2012    WGLC initial version of SCIM use cases
! 12/2012    Proposal for client targeting of SCIM endpoints=
! 02/2013    WGLC SCIM core schema
! 05/2013    WGLC SCIM restful interface
! 07/2013    Initial adoption of SCIM SAML bindings draft ! 07/2013    Initial adoption of SCIM LDAP mapping draft
! 08/2013    WGLC on client targeting of SCIM endpoints
! 09/2013    Possible update of SCIM use cases
! 11/2013    WGLC SCIM SAML bindings
! 12/2013    WGLC SCIM LDAP mapping
! 01/2014    Re-charter discussion

___________= ____________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim
--B_3418724110_1198295-- From phil.hunt@oracle.com Wed May 9 08:42:24 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E8921F8542 for ; Wed, 9 May 2012 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhcYU9MQQHvN for ; Wed, 9 May 2012 08:42:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6A221F853E for ; Wed, 9 May 2012 08:42:23 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q49FgL36016064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 15:42:22 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q49FgKYv023011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 15:42:21 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q49FgKlO001755; Wed, 9 May 2012 10:42:20 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 May 2012 08:42:20 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437220DF3EE@BL2PRD0410MB351.namprd04.prod.outlook.com> Date: Wed, 9 May 2012 08:42:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11589C20-80DC-402F-B015-EC9074F4D195@oracle.com> References: <83877F5A-5F08-44E8-8DC1-C1C9E815023F@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437220DF281@BL2PRD0410MB351.namprd04.prod.outlook.com> <05033FB0-315A-488B-9DB2-94535D852B00@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437220DF3EE@BL2PRD0410MB351.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim@ietf.org, Trey Drake , "Morteza Ansari \(moransar\)" Subject: [scim] Use of attributes parameter X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:42:25 -0000 Note: copying the mailing list as this is interesting (I originally = thought it was a simple editorial item). Somehow I missed that modify operations could return the entire resource = (and hence the attributes parameter has an effect). That seems noisy. Is = this to avoid clients doing read-after-write? =46rom an access control perspective, this seems more complex (e.g. than = say LDAP). What happens with data the client didn't provide? Does the = server withhold "proprietary data" or data contributed by other = entities? Most access control systems set rules attributes that may be = returned as part of a query only. This would mean significant = enhancements to most data store technologies unless the intent is that = the operation acts as a modify (PUT/POST/PATCH) followed by a READ. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-09, at 6:34 AM, Kelly Grizzle wrote: > I think that it can be used on a PUT/POST/PATCH to constrain what gets = sent back as the 200 response body. >=20 > Consumers MAY request a partial Resource representation on *any* > operation that returns a Resource within the response by specifying > the URL query parameter 'attributes'. >=20 >=20 > Here is some text from the section 3.3.2 describing the use with = PATCH: >=20 > The server MUST return either a 200 OK > response code and the entire Resource (subject to the "attributes" > query parameter - see Additional Retrieval Query Parameters > (Section 3.7)) within the response body, or a 204 No Content = response > code and the appropriate response headers for a successful PATCH > request. >=20 > --Kelly >=20 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, May 08, 2012 5:56 PM > To: Kelly Grizzle > Cc: Trey Drake; Morteza Ansari (moransar) > Subject: Re: attributes parameter=20 >=20 > Ok. Missed that. Wonder if it should be listed on the read operations = since it doesn't apply to modify, etc. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-05-08, at 1:11 PM, Kelly Grizzle wrote: >=20 >> The attributes query parameter is defined in section 3.7 - = http://tools.ietf.org/html/draft-scim-api-00#section-3.7. =20 >>=20 >> Interesting point about making some attributes be explicitly = requested. This might make sense for some of the potentially larger = attributes (extensions like x509 cert that have binary encoded data). >>=20 >> Issue 44 (http://code.google.com/p/scim/issues/detail?id=3D44) = discusses an "excludedAttributes" query parameter, which may be easier = to use than the "attributes" parameter if most attributes are desired. = This still won't auto-suppress certain attributes, but may be good = enough. >>=20 >> --Kelly >>=20 >>=20 >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Thursday, May 03, 2012 11:53 AM >> To: Trey Drake; Morteza Ansari (moransar); Kelly Grizzle >> Subject: attributes parameter=20 >>=20 >> Just looking through draft 00 of the api, I notice the attributes = parameter is not documented though an example is given on page 9. I was = wondering if like directories, SCIM defines optionality and operational = style of attributes. E.g. I was thinking about yesterdays tenandid use = case. Should tenantId be an attribute but likely it would be the kind of = thing that should only be returned if requested. >>=20 >> Does SCIM reporting functions follow the LDAP model on this in terms = of defining attributes that are always returned vs attributes that must = be explicitly requested? >>=20 >> Happy to report on the mailing list later. Just thought I'd get your = thought in case this is covered somewhere else in the document. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 From barryleiba.mailing.lists@gmail.com Fri May 11 06:55:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1F021F8665 for ; Fri, 11 May 2012 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.968 X-Spam-Level: X-Spam-Status: No, score=-102.968 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR7dlqWVeUux for ; Fri, 11 May 2012 06:55:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F621F8638 for ; Fri, 11 May 2012 06:55:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2186232lbb.31 for ; Fri, 11 May 2012 06:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=g0HVBLc2TUIZDA0TwjO/B7pgEX5r4YCYmwHJOSnu0mA=; b=fjYDi01cW/1l6rAY66NFWUuDpYWlwCr8ugAURSuwJvgYMWOCShJnPGGjKDxo5Ih9jt eLiqy91e6h+qdQ7SnBAnOK/8kLbLvG6xYacPy+k7baCq1uSFeC2OJodNdw9/MLiTt7KA zjAVcKpStPAp0Br26iyX6AmoAP/KXBXHYZiYY+LCMc/iSafXCY2Q3gyG104aNouefe8h 8oEPV1OmCrU/Ar8E/QKkmZTDzja9VU+CWR+9989837LQLWoy633bz7alLTrYhcZS6qVO s29J05vCzCkKdjQWTKPStbZBLSwo9XLBSiw+2wwFghagOvUBebQvb1uRSTUKUm7ppH9p HqfQ== MIME-Version: 1.0 Received: by 10.152.105.19 with SMTP id gi19mr8546985lab.11.1336744541697; Fri, 11 May 2012 06:55:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Fri, 11 May 2012 06:55:41 -0700 (PDT) Date: Fri, 11 May 2012 09:55:41 -0400 X-Google-Sender-Auth: LABOMzY3xiCzeBYlIMcjfgG2MY0 Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: multipart/mixed; boundary=f46d040716e190384904bfc31754 Subject: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 13:55:44 -0000 --f46d040716e190384904bfc31754 Content-Type: text/plain; charset=ISO-8859-1 The first step in chartering is to get feedback from the IESG and IAB, and I have the first few comments. For the record, the attached charter text is what's being commented on. 1. We should include intended document status in the milestones. To that end, I suggest this: 06/2012 Initial adoption of SCIM use cases, as a living document 06/2012 Initial adoption of SCIM core schema 08/2012 Initial adoption of SCIM restful interface draft | 12/2012 Snapshot version of SCIM use cases to IESG as Informational (possibly) 12/2012 Proposal for client targeting of SCIM endpoints | 02/2013 SCIM core schema to IESG as Proposed Standard | 05/2013 SCIM restful interface to IESG as Proposed Standard 07/2013 Initial adoption of SCIM SAML bindings draft 07/2013 Initial adoption of SCIM LDAP mapping draft | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard | 09/2013 Snapshot update of SCIM use cases as Informational (possibly) | 11/2013 SCIM SAML bindings to IESG as Proposed Standard | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter Are those correct? That is, everything is meant to be Proposed Standard except for the use cases document (which might or might not get published)? 2. There's concern about the "gaps" text in this part: > In addition, the working group will ensure that the SCIM protocol > embodies good security practices, and will document gaps in its > capabilities and propose a path forward for addressing those gaps. What's that really meant to be saying? That is, why shouldn't the sentence simply end after "good security practices"? We certainly can't produce documents that *don't* use good security practices, so if the rest of the sentence is important we have to separate it and make it clear what we're getting at. 3. There's concern by more than one AD that doing the schema definition without having the LDAP mapping there with it will result in problems, and will end up with a new schema that ultimately has as many problems as the existing one(s). The best suggestion to deal with that is to move the order around, do the LDAP mapping along with the schema, and send both documents to the IESG together. 4. The name did come up (I told you...). It's not getting in the way, at least not yet, but folks are balking at both the "simple" and the "cloud" parts. They wonder if there isn't a way to keep "scim", but to make up something new that it can stand for. Keep in mind that this is a minor point, though -- the other three above need to be fixed. Feedback to the feedback? Barry --f46d040716e190384904bfc31754 Content-Type: text/plain; charset=US-ASCII; name="charter-ietf-scim-00-00.txt" Content-Disposition: attachment; filename="charter-ietf-scim-00-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h23atqrq1 U2ltcGxlIENsb3VkIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pCgpDaGFpcihzKTogVEJEIAoK QXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3Iocyk6CiAgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0Bx dWFsY29tbS5jb20+IAogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gCgpN YWlsaW5nIExpc3RzOgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogc2NpbUBpZXRmLm9yZwogIFRvIFN1 YnNjcmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt CiAgQXJjaGl2ZTogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvc2NpbS8KIApEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOgoKVGhlIFNpbXBsZSBDbG91 ZCBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSB3b3JraW5nIGdyb3VwIHdpbGwKc3RhbmRhcmRp emUgbWV0aG9kcyBmb3IgY3JlYXRpbmcsIHJlYWRpbmcsIHNlYXJjaGluZywgbW9kaWZ5aW5nLCBh bmQKZGVsZXRpbmcgdXNlciBpZGVudGl0aWVzIGFuZCBpZGVudGl0eS1yZWxhdGVkIG9iamVjdHMg YWNyb3NzCmFkbWluaXN0cmF0aXZlIGRvbWFpbnMsIHdpdGggdGhlIGdvYWwgb2Ygc2ltcGxpZnlp bmcgY29tbW9uIHRhc2tzCnJlbGF0ZWQgdG8gdXNlciBpZGVudGl0eSBtYW5hZ2VtZW50IGluIHNl cnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMuCgoiU3RhbmRhcmRpemUiIGRvZXMgbm90IG5lY2Vzc2Fy aWx5IG1lYW4gdGhhdCB0aGUgd29ya2luZyBncm91cCB3aWxsCmRldmVsb3AgbmV3IHRlY2hub2xv Z2llcy4gIEZvciBleGFtcGxlLCB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMKZm9yICJTQ0lN IDEuMCIgcHJvdmlkZSBSRVNUZnVsIGludGVyZmFjZXMgb24gdG9wIG9mIEhUVFAgcmF0aGVyIHRo YW4KZGVmaW5pbmcgYSBuZXcgYXBwbGljYXRpb24gcHJvdG9jb2wuCgpUb2RheSwgZGlzdHJpYnV0 ZWQgaWRlbnRpdHkgbWFuYWdlbWVudCBhY3Jvc3MgYWRtaW5pc3RyYXRpdmUgZG9tYWlucwppcyBj b21wbGljYXRlZCBieSBhIGxhY2sgb2YgcHJvdG9jb2wgYW5kIHNjaGVtYSBzdGFuZGFyZGl6YXRp b24KYmV0d2VlbiBjb25zdW1lcnMgYW5kIHByb2R1Y2VycyBvZiBpZGVudGl0aWVzLiAgVGhpcyBo YXMgbGVkIHRvIGEKbnVtYmVyIG9mIGFwcHJvYWNoZXMsIGluY2x1ZGluZyBlcnJvci1wcm9uZSBt YW51YWwgYWRtaW5pc3RyYXRpb24gYW5kCmJ1bGsgZmlsZSB1cGxvYWRzLCBhcyB3ZWxsIGFzIHBy b3ByaWV0YXJ5IHByb3RvY29scyBhbmQgbWVkaWF0aW9uCmRldmljZXMgdGhhdCBtdXN0IGJlIGFk YXB0ZWQgdG8gZWFjaCBzZXJ2aWNlIGZvciBlYWNoIG9yZ2FuaXphdGlvbi4gCldoaWxlIHRoZXJl IGlzIGV4aXN0aW5nIHdvcmsgaW4gdGhlIGZpZWxkLCBpdCBoYXMgbm90IGJlZW4gd2lkZWx5CmFk b3B0ZWQgZm9yIGEgdmFyaWV0eSBvZiByZWFzb25zLCBpbmNsdWRpbmcgYSBsYWNrIG9mIGNvbW1v biBhcnRpZmFjdHMKc3VjaCBhcyBzY2hlbWEsIHRvb2xzZXRzLCBhbmQgbGlicmFyaWVzLgoKVGhl IFNDSU0gd29ya2luZyBncm91cCB3aWxsIGRldmVsb3AgdGhlIGNvcmUgc2NoZW1hIGFuZCBSRVNU ZnVsCmludGVyZmFjZXMgdG8gYWRkcmVzcyB0aGVzZSBwcm9ibGVtcy4gIEluaXRpYWxseSwgdGhl IGdyb3VwIHdpbGwgZm9jdXMKb24KLSBhIHNjaGVtYSBkZWZpbml0aW9uCi0gYSBzZXQgb2Ygb3Bl cmF0aW9ucyBmb3IgY3JlYXRpb24sIG1vZGlmaWNhdGlvbiwgYW5kIGRlbGV0aW9uIG9mIHVzZXJz Ci0gc2NoZW1hIGRpc2NvdmVyeQotIHJlYWQgYW5kIHNlYXJjaAotIGJ1bGsgb3BlcmF0aW9ucwpJ dCB3aWxsIGZvbGxvdyB0aGF0IGJ5IGNvbnNpZGVyaW5nIGV4dGVuc2lvbnMgZm9yIGNsaWVudCB0 YXJnZXRpbmcgb2YKc3BlY2lmaWMgU0NJTSBlbmRwb2ludHMsIFNBTUwgYmluZGluZywgYW5kIExE QVAgbWFwcGluZy4gIFRoZQphcHByb2FjaCB3aWxsIGJlIGV4dGVuc2libGUuCgpUaGUgZ3JvdXAg d2lsbCB1c2UsIGFzIHN0YXJ0aW5nIHBvaW50cywgdGhlIGZvbGxvd2luZyBkcmFmdHMgaW4gdGhl CmZvbGxvd2luZyB3YXlzOgogICAgIGRyYWZ0LXNjaW0tdXNlLWNhc2VzLTAwIGFzIHRoZSBpbml0 aWFsIHVzZSBjYXNlcyBmb3IgU0NJTQogICAgIGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDAgYXMg dGhlIHNjaGVtYSBzcGVjaWZpY2F0aW9uCiAgICAgZHJhZnQtc2NpbS1hcGktMDAgYXMgdGhlIHBy b3RvY29sIHNwZWNpZmljYXRpb24KClRoZXNlIGRyYWZ0cyBhcmUgYmFzZWQgb24gZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbnMsIHdoaWNoIHRvZ2V0aGVyIGFyZQpjb21tb25seSBrbm93biBhcyBTQ0lN IDEuMC4gIEJlY2F1c2UgdGhlcmUgaXMgZXhpc3Rpbmcgd29yayB3aXRoCmV4aXN0aW5nIGltcGxl bWVudGF0aW9ucywgc29tZSBjb25zaWRlcmF0aW9uIHNob3VsZCBiZSBnaXZlbiB0bwpiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5LCB0aG91Z2ggZ2V0dGluZyBpdCByaWdodCB0YWtlcyBwcmlvcml0eS4g IFRoaXMKZ3JvdXAgd2lsbCBjb25zaWRlciB0aGUgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBnYXRo ZXJlZCBmcm9tIHRoZQpleGlzdGluZyB3b3JrLCBhcyB3ZWxsIGFzIGV4cGVyaWVuY2VzIHdpdGgg d29yayBkb25lIGJ5IG90aGVyIGJvZGllcywKaW5jbHVkaW5nIHRoZSBPQVNJUyBQcm92aXNpb25p bmcgVEMuCgpUaGUgdXNlIGNhc2VzIGRvY3VtZW50IHdpbGwgYmUgYSAibGl2aW5nIGRvY3VtZW50 IiwgZ3VpZGluZyB0aGUKd29ya2luZyBncm91cCBkdXJpbmcgaXRzIGRldmVsb3BtZW50IG9mIHRo ZSBzdGFuZGFyZHMuICBUaGUgZ3JvdXAgbWF5CnRha2Ugc25hcHNob3RzIG9mIHRoYXQgZG9jdW1l bnQgZm9yIEluZm9ybWF0aW9uYWwgcHVibGljYXRpb24sIHRvCnNlcnZlIGFzIGRvY3VtZW50YXRp b24gb2YgdGhlIG1vdGl2YXRpb24gZm9yIHRoZSB3b3JrIGluIHByb2dyZXNzCmFuZCB0byBzaW1p bGFybHkgZ3VpZGUgcGxhbm5pbmcgYW5kIGltcGxlbWVudGF0aW9uLgoKVGhlIGdyb3VwIHdpbGwg cHJvZHVjZSBQcm9wb3NlZCBTdGFuZGFyZHMgZm9yIGEgc2NoZW1hLCBhIFJFU1QtYmFzZWQKcHJv dG9jb2wsIGEgU0FNTCBiaW5kaW5nLCBhbmQgYW4gTERBUCBtYXBwaW5nLiAgSW4gZG9pbmcgc28s IHRoZSBncm91cAp3aWxsIG1ha2UgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnQsIGlkZW50aWZ5 IGFueSBmdW5jdGlvbmFsIGdhcHMKdGhhdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGZ1dHVyZSB3b3Jr LCBhZGRyZXNzIGludGVybmF0aW9uYWxpemF0aW9uLAphbmQgcHJvdmlkZSBndWlkZWxpbmVzIGFu ZCBtZWNoYW5pc21zIGZvciBleHRlbnNpYmlsaXR5LgoKSW4gYWRkaXRpb24sIHRoZSB3b3JraW5n IGdyb3VwIHdpbGwgZW5zdXJlIHRoYXQgdGhlIFNDSU0gcHJvdG9jb2wKZW1ib2RpZXMgZ29vZCBz ZWN1cml0eSBwcmFjdGljZXMsIGFuZCB3aWxsIGRvY3VtZW50IGdhcHMgaW4gaXRzCmNhcGFiaWxp dGllcyBhbmQgcHJvcG9zZSBhIHBhdGggZm9yd2FyZCBmb3IgYWRkcmVzc2luZyB0aG9zZSBnYXBz LiAKR2l2ZW4gYm90aCB0aGUgc2Vuc2l0aXZpdHkgb2YgdGhlIGluZm9ybWF0aW9uIGJlaW5nIGNv bnZleWVkIGluIFNDSU0KbWVzc2FnZXMgYW5kIHRoZSByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyBy ZWdhcmRpbmcgdGhlIHByaXZhY3kgb2YKcGVyc29uYWxseSBpZGVudGlmaWFibGUgaW5mb3JtYXRp b24sIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcGF5CnBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIGlz c3VlcyBhcm91bmQgYXV0aGVudGljaXR5IGFuZCBwcml2YWN5LgoKVGhlIGdyb3VwIGNvbnNpZGVy cyB0aGUgZm9sbG93aW5nIG91dCBvZiBzY29wZSBmb3IgdGhpcyBncm91cDoKICAgICBEZWZpbmlu ZyBuZXcgYXV0aGVudGljYXRpb24gc2NoZW1lcwogICAgIERlZmluaW5nIG5ldyBwb2xpY3kvYXV0 aG9yaXphdGlvbiBzY2hlbWVzCgpNaWxlc3RvbmVzCgowNi8yMDEyICAgIEluaXRpYWwgYWRvcHRp b24gb2YgU0NJTSB1c2UgY2FzZXMsIGFzIGEgbGl2aW5nIGRvY3VtZW50CjA2LzIwMTIgICAgSW5p dGlhbCBhZG9wdGlvbiBvZiBTQ0lNIGNvcmUgc2NoZW1hCjA4LzIwMTIgICAgSW5pdGlhbCBhZG9w dGlvbiBvZiBTQ0lNIHJlc3RmdWwgaW50ZXJmYWNlIGRyYWZ0CjEyLzIwMTIgICAgU25hcHNob3Qg dmVyc2lvbiBvZiBTQ0lNIHVzZSBjYXNlcyB0byBJRVNHIChwb3NzaWJseSkKMTIvMjAxMiAgICBQ cm9wb3NhbCBmb3IgY2xpZW50IHRhcmdldGluZyBvZiBTQ0lNIGVuZHBvaW50cwowMi8yMDEzICAg IFNDSU0gY29yZSBzY2hlbWEgdG8gSUVTRwowNS8yMDEzICAgIFNDSU0gcmVzdGZ1bCBpbnRlcmZh Y2UgdG8gSUVTRwowNy8yMDEzICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSBTQU1MIGJpbmRp bmdzIGRyYWZ0CjA3LzIwMTMgICAgSW5pdGlhbCBhZG9wdGlvbiBvZiBTQ0lNIExEQVAgbWFwcGlu ZyBkcmFmdAowOC8yMDEzICAgIENsaWVudCB0YXJnZXRpbmcgb2YgU0NJTSBlbmRwb2ludHMgdG8g SUVTRwowOS8yMDEzICAgIFNuYXBzaG90IHVwZGF0ZSBvZiBTQ0lNIHVzZSBjYXNlcyAocG9zc2li bHkpCjExLzIwMTMgICAgU0NJTSBTQU1MIGJpbmRpbmdzIHRvIElFU0cKMTIvMjAxMyAgICBTQ0lN IExEQVAgbWFwcGluZyB0byBJRVNHCjAxLzIwMTQgICAgV29yayBjb21wbGV0ZWQ7IGRpc2N1c3Mg cmUtY2hhcnRlcgo= --f46d040716e190384904bfc31754-- From presnick@qualcomm.com Fri May 11 10:00:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A121F859E for ; Fri, 11 May 2012 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tlzvD4iIcMF for ; Fri, 11 May 2012 10:00:38 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8878821F8582 for ; Fri, 11 May 2012 10:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1336755638; x=1368291638; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=cXdCgI25cvuYwGAKC7F2vQqMwwGCyadJwtGq7mJ47Zs=; b=qUnFA1Gz59dUgzLDTxqQgtV3MtE4ck6k/kXBqBElSQtqvgVvzgIoDQPD Hr6gxA8fEzermE8+HDzBbzCX93kWTrptsEgU1OM7wLiC6TM3oVV7TIbW/ 55yuX4fgctgSH2pGdKA7k3TaLc6poUteh/UmX3VJfocQv76fKmg9NAbEO Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6708"; a="187785822" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 11 May 2012 10:00:38 -0700 X-IronPort-AV: E=Sophos;i="4.75,571,1330934400"; d="scan'208";a="249618115" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 May 2012 10:00:38 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 11 May 2012 10:00:37 -0700 Message-ID: <4FAD45B3.8020202@qualcomm.com> Date: Fri, 11 May 2012 12:00:35 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:00:39 -0000 On 5/11/12 8:55 AM, Barry Leiba wrote: > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. > "Yet" has arrived. It is getting in the way. Here's more or less what I said to the IESG: Having the word "simple" is just nonsense and I think it should go, but that's not my big concern. Having the word "cloud" is flypaper for the loons to come out of the woodwork and disrupt this WG. There will obviously be engineering loons who will come to work on this thing simply because it is about "clouds" and try to get their cloud nonsense into the work. But there also will be press loons, and there will be otherwise normal people who end up pandering to the press loons. I think this will really do damage to the productivity of the WG. (Others in the IESG are equally concerned about "Identity Management", in that we have lots of work on what people refer to as "Identity Management", but it normally involves protocols used to log in and log out, which is not what this is doing.) The "name recognition" argument does nothing for me. Jabber survived just fine after it got called XMPP in the IETF. You can continue to call your management scheme "SCIM" in your own circles, but in the IETF it should have a name that doesn't carry baggage. I am truly opposed to the current name. Come up with a new name. Please. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From melinda.shore@gmail.com Fri May 11 10:18:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5421F8647 for ; Fri, 11 May 2012 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7xSpWeKTGhR for ; Fri, 11 May 2012 10:18:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6026121F85FC for ; Fri, 11 May 2012 10:18:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3713217pbc.31 for ; Fri, 11 May 2012 10:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L42V72YgecxVqSb/cWMZIZfr1hCytnVHDZOOWmNtLBA=; b=XYp7gfLWl/YjnnX5Iff24WCu6AplEjCv2RvVvZqgEorrEh0C4dg4om85l3OWWCmiOR /T3S+nQPiD4gLb7BJeGzK2iOMEEMQtarcQ1hFXKIMTbElYDz3CD7SWmfCe6CuBzl4QVa IxQa0qngeXE5HR9bzd9fV7F3mvRsHy5aXHXnyFaU23LAnwlxLFl+1J4ixpEKgaML8zES E8f0LyyOjRS8Q3KmYX+pc8QdqCvxm6Gx8z8149geNpClgslDrRId7yz1Bj07nkP+gaGa 9RlBNdHMrJuGDW7811n48Gur6VWPp1UdIrZXpPWSwGWXWwG4sN7qF0Gr2NeLsI278FAn Mp3g== Received: by 10.68.232.129 with SMTP id to1mr15308451pbc.121.1336756706184; Fri, 11 May 2012 10:18:26 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id va3sm9039034pbc.9.2012.05.11.10.18.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 10:18:25 -0700 (PDT) Message-ID: <4FAD49DF.6090600@gmail.com> Date: Fri, 11 May 2012 09:18:23 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:18:27 -0000 On 5/11/12 5:55 AM, Barry Leiba wrote: > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > > What's that really meant to be saying? That is, why shouldn't the > sentence simply end after "good security practices"? We certainly > can't produce documents that *don't* use good security practices, so > if the rest of the sentence is important we have to separate it and > make it clear what we're getting at. While we're kvetching about language I'm not a huge fan of the phrase "gap analysis" but it's my understanding that that's what's being talked about here. That said, I'm still not sure whether it's going to take the form of a few paragraphs in the security considerations section of document saying "we don't do and we need to address that" or something more rigorous. A gap analysis usually starts with a requirements document and there isn't one here, but it may be worth taking a look at the current document set, putting together a threat analysis, which I think is not a huge job for scim, and using that as a starting point. I'd be happy to take that on. > 3. There's concern by more than one AD that doing the schema > definition without having the LDAP mapping there with it will result > in problems, and will end up with a new schema that ultimately has as > many problems as the existing one(s). The best suggestion to deal > with that is to move the order around, do the LDAP mapping along with > the schema, and send both documents to the IESG together. I'm coming at this from the IETF side and haven't had any involvement with scim prior to it being brought to the IETF, but there seems to be more concern with SAML, which would face a similar problem. I've started working on an implementation and it very quickly became clear that this is almost certainly the most likely source of incompatibilities/non-interoperability between implementations, and I'd be good with seeing both the SAML and LDAP mappings being folded into the schema document as appendices. > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. It seems to me that including "provisioning" (or something similar) in the protocol's name has the twin virtues of being accurate and helping to distinguish from authentication/authorization protocols. And yeah, definitely - "cloud" has got to go. "Simple" would seem to depend on what folks decide to do about element mappings (nyuk, nyuk, nyuk). Melinda From michael.hammer@yaanatech.com Fri May 11 10:39:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7621F86D3 for ; Fri, 11 May 2012 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzCnb-3UTjtH for ; Fri, 11 May 2012 10:39:56 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3521F86D1 for ; Fri, 11 May 2012 10:39:56 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 11 May 2012 10:39:56 -0700 From: Michael Hammer To: "presnick@qualcomm.com" , "barryleiba@computer.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33EsPIWbTdIu0WuwXeZ20hv+JbFRYeA//+NLaA= Date: Fri, 11 May 2012 17:39:54 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38AA5FF@EX2K10MB1.corp.yaanatech.com> References: <4FAD45B3.8020202@qualcomm.com> In-Reply-To: <4FAD45B3.8020202@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0058_01CD2F7B.8B82A410" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:39:57 -0000 ------=_NextPart_000_0058_01CD2F7B.8B82A410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pete, So, to summarize: Simple is out Cloud is out Identity Management is out. What was left? :) Do you have a proposal? Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Pete Resnick Sent: Friday, May 11, 2012 1:01 PM To: Barry Leiba Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 8:55 AM, Barry Leiba wrote: > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. > "Yet" has arrived. It is getting in the way. Here's more or less what I said to the IESG: Having the word "simple" is just nonsense and I think it should go, but that's not my big concern. Having the word "cloud" is flypaper for the loons to come out of the woodwork and disrupt this WG. There will obviously be engineering loons who will come to work on this thing simply because it is about "clouds" and try to get their cloud nonsense into the work. But there also will be press loons, and there will be otherwise normal people who end up pandering to the press loons. I think this will really do damage to the productivity of the WG. (Others in the IESG are equally concerned about "Identity Management", in that we have lots of work on what people refer to as "Identity Management", but it normally involves protocols used to log in and log out, which is not what this is doing.) The "name recognition" argument does nothing for me. Jabber survived just fine after it got called XMPP in the IETF. You can continue to call your management scheme "SCIM" in your own circles, but in the IETF it should have a name that doesn't carry baggage. I am truly opposed to the current name. Come up with a new name. Please. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0058_01CD2F7B.8B82A410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx MTE3Mzk1M1owIwYJKoZIhvcNAQkEMRYEFCyvLDn2YMB+8pHj86INDuoJXvCTMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAYu/+f2tkmuePuepSbEJUggrgTmtGuvNd7aEzruNwccn1 O65/jDI8HaU827aiPLgqroj2cRI1bkzV+WUJcE1p+OccSheZG37u5DMqeIzTyAu8OKeBLBTdbGO7 dX30nIkkXUvKjuNNLstlOQoerrnZ+z2zbTDhEElnavSpco3rGiIAAAAAAAA= ------=_NextPart_000_0058_01CD2F7B.8B82A410-- From michael.hammer@yaanatech.com Fri May 11 10:50:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C221F86E2 for ; Fri, 11 May 2012 10:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXxCT+GbqmLp for ; Fri, 11 May 2012 10:50:36 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0421F857A for ; Fri, 11 May 2012 10:50:36 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 11 May 2012 10:50:36 -0700 From: Michael Hammer To: "melinda.shore@gmail.com" , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33EsPIWbTdIu0WuwXeZ20hv+JbFSoCA//+TcKA= Date: Fri, 11 May 2012 17:50:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> References: <4FAD49DF.6090600@gmail.com> In-Reply-To: <4FAD49DF.6090600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C1_01CD2F7D.0967D6B0" MIME-Version: 1.0 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:50:36 -0000 ------=_NextPart_000_00C1_01CD2F7D.0967D6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would avoid the word simple too. IETF has a SIMPLE WG already. :) Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Friday, May 11, 2012 1:18 PM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 5:55 AM, Barry Leiba wrote: > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > > What's that really meant to be saying? That is, why shouldn't the > sentence simply end after "good security practices"? We certainly > can't produce documents that *don't* use good security practices, so > if the rest of the sentence is important we have to separate it and > make it clear what we're getting at. While we're kvetching about language I'm not a huge fan of the phrase "gap analysis" but it's my understanding that that's what's being talked about here. That said, I'm still not sure whether it's going to take the form of a few paragraphs in the security considerations section of document saying "we don't do and we need to address that" or something more rigorous. A gap analysis usually starts with a requirements document and there isn't one here, but it may be worth taking a look at the current document set, putting together a threat analysis, which I think is not a huge job for scim, and using that as a starting point. I'd be happy to take that on. > 3. There's concern by more than one AD that doing the schema > definition without having the LDAP mapping there with it will result > in problems, and will end up with a new schema that ultimately has as > many problems as the existing one(s). The best suggestion to deal > with that is to move the order around, do the LDAP mapping along with > the schema, and send both documents to the IESG together. I'm coming at this from the IETF side and haven't had any involvement with scim prior to it being brought to the IETF, but there seems to be more concern with SAML, which would face a similar problem. I've started working on an implementation and it very quickly became clear that this is almost certainly the most likely source of incompatibilities/non-interoperability between implementations, and I'd be good with seeing both the SAML and LDAP mappings being folded into the schema document as appendices. > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. It seems to me that including "provisioning" (or something similar) in the protocol's name has the twin virtues of being accurate and helping to distinguish from authentication/authorization protocols. And yeah, definitely - "cloud" has got to go. "Simple" would seem to depend on what folks decide to do about element mappings (nyuk, nyuk, nyuk). Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_00C1_01CD2F7D.0967D6B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx MTE3NTAzM1owIwYJKoZIhvcNAQkEMRYEFLoyRCZjZdomOmKagfqY9LljbsNaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAemF3aeSIwTUtPLmS41KiDJlD7Wdt0zBY0yqqR6bM1sX1 kzn12G4i6aHBvHucum2K3T0SR47psaEHCkXisykIZMzpv67m0hzmyEzRv1+s62NhJtfDkdGfxpcn YJtENoeA9teTUI1gXM77rg3M8LD0Mf9FIlqgADAKcqOHwz/4588AAAAAAAA= ------=_NextPart_000_00C1_01CD2F7D.0967D6B0-- From michael.brenner@alcatel-lucent.com Fri May 11 11:00:23 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F821F86F6 for ; Fri, 11 May 2012 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.524 X-Spam-Level: X-Spam-Status: No, score=-9.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Yla86LlYHX for ; Fri, 11 May 2012 11:00:22 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5442721F86F0 for ; Fri, 11 May 2012 11:00:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4BI0HAg027399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 13:00:17 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BI0HfV017534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 May 2012 13:00:17 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 11 May 2012 13:00:17 -0500 From: "Brenner, Michael Ralf (Michael)" To: Michael Hammer , "melinda.shore@gmail.com" , "scim@ietf.org" Date: Fri, 11 May 2012 13:00:15 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33EsPIWbTdIu0WuwXeZ20hv+JbFSoCA//+TcKCAAALB8A== Message-ID: <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:00:23 -0000 IAPI: Identity Attributes Provisioning Interface -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Friday, May 11, 2012 1:51 PM To: melinda.shore@gmail.com; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB I would avoid the word simple too. IETF has a SIMPLE WG already. :) Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mel= inda Shore Sent: Friday, May 11, 2012 1:18 PM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 5:55 AM, Barry Leiba wrote: > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > > What's that really meant to be saying? That is, why shouldn't the=20 > sentence simply end after "good security practices"? We certainly=20 > can't produce documents that *don't* use good security practices, so=20 > if the rest of the sentence is important we have to separate it and=20 > make it clear what we're getting at. While we're kvetching about language I'm not a huge fan of the phrase "gap = analysis" but it's my understanding that that's what's being talked about h= ere. That said, I'm still not sure whether it's going to take the form of = a few paragraphs in the security considerations section of docum= ent saying "we don't do and we need to address that" or something mor= e rigorous. A gap analysis usually starts with a requirements document and= there isn't one here, but it may be worth taking a look at the current doc= ument set, putting together a threat analysis, which I think is not a huge = job for scim, and using that as a starting point. I'd be happy to take tha= t on. > 3. There's concern by more than one AD that doing the schema=20 > definition without having the LDAP mapping there with it will result=20 > in problems, and will end up with a new schema that ultimately has as=20 > many problems as the existing one(s). The best suggestion to deal=20 > with that is to move the order around, do the LDAP mapping along with=20 > the schema, and send both documents to the IESG together. I'm coming at this from the IETF side and haven't had any involvement with = scim prior to it being brought to the IETF, but there seems to be more conc= ern with SAML, which would face a similar problem. I've started working on an implementation and it very quickly became clear = that this is almost certainly the most likely source of incompatibilities/n= on-interoperability between implementations, and I'd be good with seeing bo= th the SAML and LDAP mappings being folded into the schema document as appe= ndices. > 4. The name did come up (I told you...). It's not getting in the way,=20 > at least not yet, but folks are balking at both the "simple" and the=20 > "cloud" parts. They wonder if there isn't a way to keep "scim", but=20 > to make up something new that it can stand for. Keep in mind that=20 > this is a minor point, though -- the other three above need to be=20 > fixed. It seems to me that including "provisioning" (or something similar) in the = protocol's name has the twin virtues of being accurate and helping to disti= nguish from authentication/authorization protocols. And yeah, definitely - "cloud" has got to go. "Simple" would seem to depen= d on what folks decide to do about element mappings (nyuk, nyuk, nyuk). Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From michael.brenner@alcatel-lucent.com Fri May 11 11:01:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69ED21F86F9 for ; Fri, 11 May 2012 11:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0vtcqzuQVOO for ; Fri, 11 May 2012 11:01:32 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DDA8921F86F0 for ; Fri, 11 May 2012 11:01:31 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4BI1TMU027783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 13:01:30 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BI1T3n027562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 May 2012 13:01:29 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 11 May 2012 13:01:16 -0500 From: "Brenner, Michael Ralf (Michael)" To: "Brenner, Michael Ralf (Michael)" , Michael Hammer , "melinda.shore@gmail.com" , "scim@ietf.org" Date: Fri, 11 May 2012 13:01:14 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33EsPIWbTdIu0WuwXeZ20hv+JbFSoCA//+TcKCAAALB8IAAAFZA Message-ID: <219947F0B2242843A0A1E62FDB510DC02511917D1E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:01:32 -0000 I did not realize ... but at the same time it could stand for Identity API:= -) -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bre= nner, Michael Ralf (Michael) Sent: Friday, May 11, 2012 2:00 PM To: Michael Hammer; melinda.shore@gmail.com; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB IAPI: Identity Attributes Provisioning Interface -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Friday, May 11, 2012 1:51 PM To: melinda.shore@gmail.com; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB I would avoid the word simple too. IETF has a SIMPLE WG already. :) Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mel= inda Shore Sent: Friday, May 11, 2012 1:18 PM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 5:55 AM, Barry Leiba wrote: > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > > What's that really meant to be saying? That is, why shouldn't the=20 > sentence simply end after "good security practices"? We certainly=20 > can't produce documents that *don't* use good security practices, so=20 > if the rest of the sentence is important we have to separate it and=20 > make it clear what we're getting at. While we're kvetching about language I'm not a huge fan of the phrase "gap = analysis" but it's my understanding that that's what's being talked about h= ere. That said, I'm still not sure whether it's going to take the form of = a few paragraphs in the security considerations section of docum= ent saying "we don't do and we need to address that" or something mor= e rigorous. A gap analysis usually starts with a requirements document and= there isn't one here, but it may be worth taking a look at the current doc= ument set, putting together a threat analysis, which I think is not a huge = job for scim, and using that as a starting point. I'd be happy to take tha= t on. > 3. There's concern by more than one AD that doing the schema=20 > definition without having the LDAP mapping there with it will result=20 > in problems, and will end up with a new schema that ultimately has as=20 > many problems as the existing one(s). The best suggestion to deal=20 > with that is to move the order around, do the LDAP mapping along with=20 > the schema, and send both documents to the IESG together. I'm coming at this from the IETF side and haven't had any involvement with = scim prior to it being brought to the IETF, but there seems to be more conc= ern with SAML, which would face a similar problem. I've started working on an implementation and it very quickly became clear = that this is almost certainly the most likely source of incompatibilities/n= on-interoperability between implementations, and I'd be good with seeing bo= th the SAML and LDAP mappings being folded into the schema document as appe= ndices. > 4. The name did come up (I told you...). It's not getting in the way,=20 > at least not yet, but folks are balking at both the "simple" and the=20 > "cloud" parts. They wonder if there isn't a way to keep "scim", but=20 > to make up something new that it can stand for. Keep in mind that=20 > this is a minor point, though -- the other three above need to be=20 > fixed. It seems to me that including "provisioning" (or something similar) in the = protocol's name has the twin virtues of being accurate and helping to disti= nguish from authentication/authorization protocols. And yeah, definitely - "cloud" has got to go. "Simple" would seem to depen= d on what folks decide to do about element mappings (nyuk, nyuk, nyuk). Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Fri May 11 11:03:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8221F84A5 for ; Fri, 11 May 2012 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rewYwsy8sf9 for ; Fri, 11 May 2012 11:03:39 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id E416921F8427 for ; Fri, 11 May 2012 11:03:39 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 11 May 2012 11:03:39 -0700 From: Michael Hammer To: "michael.brenner@alcatel-lucent.com" , "melinda.shore@gmail.com" , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33EsPIWbTdIu0WuwXeZ20hv+JbFSoCA//+TcKCAAALB8IAAAFZAgAAAvnA= Date: Fri, 11 May 2012 18:03:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38AA730@EX2K10MB1.corp.yaanatech.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC02511917D1E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC02511917D1E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DE_01CD2F7E.DD15F180" MIME-Version: 1.0 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:03:40 -0000 ------=_NextPart_000_00DE_01CD2F7E.DD15F180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cool -----Original Message----- From: Brenner, Michael Ralf (Michael) [mailto:michael.brenner@alcatel-lucent.com] Sent: Friday, May 11, 2012 2:01 PM To: Brenner, Michael Ralf (Michael); Michael Hammer; melinda.shore@gmail.com; scim@ietf.org Subject: RE: [scim] Feedback on the charter from IESG and IAB I did not realize ... but at the same time it could stand for Identity API:-) -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Brenner, Michael Ralf (Michael) Sent: Friday, May 11, 2012 2:00 PM To: Michael Hammer; melinda.shore@gmail.com; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB IAPI: Identity Attributes Provisioning Interface -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Friday, May 11, 2012 1:51 PM To: melinda.shore@gmail.com; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB I would avoid the word simple too. IETF has a SIMPLE WG already. :) Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Friday, May 11, 2012 1:18 PM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 5:55 AM, Barry Leiba wrote: > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > > What's that really meant to be saying? That is, why shouldn't the > sentence simply end after "good security practices"? We certainly > can't produce documents that *don't* use good security practices, so > if the rest of the sentence is important we have to separate it and > make it clear what we're getting at. While we're kvetching about language I'm not a huge fan of the phrase "gap analysis" but it's my understanding that that's what's being talked about here. That said, I'm still not sure whether it's going to take the form of a few paragraphs in the security considerations section of document saying "we don't do and we need to address that" or something more rigorous. A gap analysis usually starts with a requirements document and there isn't one here, but it may be worth taking a look at the current document set, putting together a threat analysis, which I think is not a huge job for scim, and using that as a starting point. I'd be happy to take that on. > 3. There's concern by more than one AD that doing the schema > definition without having the LDAP mapping there with it will result > in problems, and will end up with a new schema that ultimately has as > many problems as the existing one(s). The best suggestion to deal > with that is to move the order around, do the LDAP mapping along with > the schema, and send both documents to the IESG together. I'm coming at this from the IETF side and haven't had any involvement with scim prior to it being brought to the IETF, but there seems to be more concern with SAML, which would face a similar problem. I've started working on an implementation and it very quickly became clear that this is almost certainly the most likely source of incompatibilities/non-interoperability between implementations, and I'd be good with seeing both the SAML and LDAP mappings being folded into the schema document as appendices. > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. It seems to me that including "provisioning" (or something similar) in the protocol's name has the twin virtues of being accurate and helping to distinguish from authentication/authorization protocols. And yeah, definitely - "cloud" has got to go. "Simple" would seem to depend on what folks decide to do about element mappings (nyuk, nyuk, nyuk). Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_00DE_01CD2F7E.DD15F180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx MTE4MDMzOFowIwYJKoZIhvcNAQkEMRYEFJvP7imeUU0vee6iDEmiWSBvvwUaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAv9/GRpwSKkJfdkbQI8FFl8yd1hF/ifAtka0I0XxVwZwJ Us8CtlupOqbUUBDLLAZKc9cohRpH4xmXsCzHdoFVJUc5XRiZrLr6EKudQQoNOYjzgLhBbJ5HCCZ3 8g/g1l3K1ZNVjNJR6yKjdghP5FFikSeKKZep+ctTiuzP5qr5tYwAAAAAAAA= ------=_NextPart_000_00DE_01CD2F7E.DD15F180-- From tony@yaanatech.com Fri May 11 14:09:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815A21F8718 for ; Fri, 11 May 2012 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plw8z2e+DNiY for ; Fri, 11 May 2012 14:09:31 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4917821F8713 for ; Fri, 11 May 2012 14:09:31 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id C048158076; Fri, 11 May 2012 21:09:26 +0000 (UTC) Message-ID: <4FAD8005.4070706@yaanatech.com> Date: Fri, 11 May 2012 17:09:25 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: "Brenner, Michael Ralf (Michael)" References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , "melinda.shore@gmail.com" , Michael Hammer Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:09:32 -0000 This has now become generic enough that CybOX could be used at the interface. It's just been added to MAEC. If you're not familiar with CybOX, check out cybox.mitre.org Identity attributes are ultimately nothing more than observables. --tony On 5/11/2012 2:00 PM, Brenner, Michael Ralf (Michael) wrote: > IAPI: Identity Attributes Provisioning Interface From igor.faynberg@alcatel-lucent.com Fri May 11 14:41:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DD29E800B for ; Fri, 11 May 2012 14:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.561 X-Spam-Level: X-Spam-Status: No, score=-7.561 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi79nBIv7C5K for ; Fri, 11 May 2012 14:41:28 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9A9E800A for ; Fri, 11 May 2012 14:41:28 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4BLfP4i023800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 May 2012 16:41:26 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BLfPbm021540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 May 2012 16:41:25 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4BLfPqg016208; Fri, 11 May 2012 16:41:25 -0500 (CDT) Message-ID: <4FAD8785.8000704@alcatel-lucent.com> Date: Fri, 11 May 2012 17:41:25 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <4FAD45B3.8020202@qualcomm.com> In-Reply-To: <4FAD45B3.8020202@qualcomm.com> Content-Type: multipart/alternative; boundary="------------050401010408040405040509" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:41:29 -0000 This is a multi-part message in MIME format. --------------050401010408040405040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The loon has arrived to ask a (simple) question: What does "S" stand for in SNMP,? (For the record, this very loon had always been on a megalomaniac side, as when insisting, successfully, that a WG designing a /simple/ media gateway protocol be called MEGACO. But simple is simple is simple.) Igor the Loon On 5/11/2012 1:00 PM, Pete Resnick wrote: > On 5/11/12 8:55 AM, Barry Leiba wrote: >> 4. The name did come up (I told you...). It's not getting in the way, >> at least not yet, but folks are balking at both the "simple" and the >> "cloud" parts. They wonder if there isn't a way to keep "scim", but >> to make up something new that it can stand for. Keep in mind that >> this is a minor point, though -- the other three above need to be >> fixed. > > "Yet" has arrived. It is getting in the way. Here's more or less what > I said to the IESG: > > Having the word "simple" is just nonsense and I think it should go, > but that's not my big concern. > > Having the word "cloud" is flypaper for the loons to come out of the > woodwork and disrupt this WG. There will obviously be engineering > loons who will come to work on this thing simply because it is about > "clouds" and try to get their cloud nonsense into the work. But there > also will be press loons, and there will be otherwise normal people > who end up pandering to the press loons. I think this will really do > damage to the productivity of the WG. > > (Others in the IESG are equally concerned about "Identity Management", > in that we have lots of work on what people refer to as "Identity > Management", but it normally involves protocols used to log in and log > out, which is not what this is doing.) > > The "name recognition" argument does nothing for me. Jabber survived > just fine after it got called XMPP in the IETF. You can continue to > call your management scheme "SCIM" in your own circles, but in the > IETF it should have a name that doesn't carry baggage. > > I am truly opposed to the current name. Come up with a new name. Please. > > pr > --------------050401010408040405040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The loon has arrived to ask a (simple) question: What does "S" stand for in SNMP,? 

(For the record, this very loon had always been on a megalomaniac side,  as when insisting, successfully, that a WG designing a simple media gateway protocol be called MEGACO. But simple is simple is simple.)

Igor the Loon



On 5/11/2012 1:00 PM, Pete Resnick wrote:
On 5/11/12 8:55 AM, Barry Leiba wrote:
4. The name did come up (I told you...).  It's not getting in the way,
at least not yet, but folks are balking at both the "simple" and the
"cloud" parts.  They wonder if there isn't a way to keep "scim", but
to make up something new that it can stand for.  Keep in mind that
this is a minor point, though -- the other three above need to be
fixed.
  

"Yet" has arrived. It is getting in the way. Here's more or less what I said to the IESG:

Having the word "simple" is just nonsense and I think it should go, but that's not my big concern.

Having the word "cloud" is flypaper for the loons to come out of the woodwork and disrupt this WG. There will obviously be engineering loons who will come to work on this thing simply because it is about "clouds" and try to get their cloud nonsense into the work. But there also will be press loons, and there will be otherwise normal people who end up pandering to the press loons. I think this will really do damage to the productivity of the WG.

(Others in the IESG are equally concerned about "Identity Management", in that we have lots of work on what people refer to as "Identity Management", but it normally involves protocols used to log in and log out, which is not what this is doing.)

The "name recognition" argument does nothing for me. Jabber survived just fine after it got called XMPP in the IETF. You can continue to call your management scheme "SCIM" in your own circles, but in the IETF it should have a name that doesn't carry baggage.

I am truly opposed to the current name. Come up with a new name. Please.

pr

--------------050401010408040405040509-- From phil.hunt@oracle.com Fri May 11 14:43:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743E721F8525 for ; Fri, 11 May 2012 14:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jog2EKE5Ugx3 for ; Fri, 11 May 2012 14:43:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id A579821F84BF for ; Fri, 11 May 2012 14:43:14 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BLhAMW005492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 21:43:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BLhACC013625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 21:43:10 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BLh9HT028515; Fri, 11 May 2012 16:43:09 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 14:43:09 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4FAD8005.4070706@yaanatech.com> Date: Fri, 11 May 2012 14:43:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> To: tony@yaanatech.com X-Mailer: Apple Mail (2.1257) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , "melinda.shore@gmail.com" , Michael Hammer Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:43:15 -0000 I think we're talking about just renaming the project rather then = starting all over. I think RESTful and cross-domain are important aspects worth = highlighting in the name. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-11, at 2:09 PM, Tony Rutkowski wrote: > This has now become generic enough that CybOX could > be used at the interface. It's just been added to > MAEC. >=20 > If you're not familiar with CybOX, check out > cybox.mitre.org > Identity attributes are ultimately nothing > more than observables. >=20 > --tony >=20 > On 5/11/2012 2:00 PM, Brenner, Michael Ralf (Michael) wrote: >> IAPI: Identity Attributes Provisioning Interface >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stephen.farrell@cs.tcd.ie Fri May 11 16:03:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9811E8097 for ; Fri, 11 May 2012 16:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQQl-ns6pbht for ; Fri, 11 May 2012 16:03:26 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA19E800A for ; Fri, 11 May 2012 16:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 559C915356F; Sat, 12 May 2012 00:03:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1336777403; bh=ASySD x+McMzVS776bFv1GRCPQFbO/TDSL0H1uOLOMVM=; b=7JaSc7PJCMaJtWHZLd6Y5 AMvFz2jP2kWyfp4us9VeMCjjGOI8+QrND5198ZuoynLQCzjxt1tKnjhbcgLgzc2j QauNAxNIYV3i4SCF9hmZVHA7aLkn0Q8bC03jEMsN8VeMwcBgFk7c8fskG8bA4hmI lOqb7ui9eW+HKrmk3bzoSVeooJnSDKtR6iRWYRY9+uQeaoaOZ3ZnS30GNkqEJ9Lm mvscmoG/lHQK9Inhjf+CApHyWxkyoxp/Z/8N+NCB83pXGL9KKMOp7GZDCoUP7Y1F NiW9viS/JNZGCxcNOoNCRC6uB2ZXkaw4MwllPFvFtvjs2+1N4I7cczWnCF5VGZHJ Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id sOOrmAKhWqRo; Sat, 12 May 2012 00:03:23 +0100 (IST) Received: from [10.87.48.6] (unknown [86.45.59.27]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 28B901714F0; Sat, 12 May 2012 00:03:20 +0100 (IST) References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> In-Reply-To: <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> X-Mailer: iPhone Mail (9B176) From: Stephen Farrell Date: Sat, 12 May 2012 00:03:12 +0100 To: Phil Hunt Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , "melinda.shore@gmail.com" , Michael Hammer , "tony@yaanatech.com" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:03:36 -0000 Scalable Cross-domain Identity Migration? On 11 May 2012, at 22:43, Phil Hunt wrote: > I think we're talking about just renaming the project rather then starting= all over. >=20 > I think RESTful and cross-domain are important aspects worth highlighting i= n the name. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-05-11, at 2:09 PM, Tony Rutkowski wrote: >=20 >> This has now become generic enough that CybOX could >> be used at the interface. It's just been added to >> MAEC. >>=20 >> If you're not familiar with CybOX, check out >> cybox.mitre.org >> Identity attributes are ultimately nothing >> more than observables. >>=20 >> --tony >>=20 >> On 5/11/2012 2:00 PM, Brenner, Michael Ralf (Michael) wrote: >>> IAPI: Identity Attributes Provisioning Interface >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri May 11 16:05:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6373511E808A for ; Fri, 11 May 2012 16:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SoAdyHOPT0z for ; Fri, 11 May 2012 16:05:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E605411E8088 for ; Fri, 11 May 2012 16:05:08 -0700 (PDT) Received: by dacx6 with SMTP id x6so3821415dac.31 for ; Fri, 11 May 2012 16:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SM4OiSD9ZSbBYCc1qipY3BJ5Il94uv0oeGyLYi127Ic=; b=sUTO6P1092sv7wwR0UjaveKwSZij7j5VewWcS9/tVgEM/B8Gld7vKnvIuNdaq/5nTS XQm+gFtxQDk+GDNbdfkJlig3oyfDQD1lgy1rc+nfhBy0wE6SDTx6DqIv9VfJVZdl8Dmr xSS32vaeRunlEI4bY24wu+2PaqsHRe9sC3zLULLFH9+3FM42rNHoOFWtc85fdR1rewlh BIkx6sEaOaLg8KK+XF4N2szjz6cPGTxgfuyPkxlEeMCh0lRLlvIUxsUaF+B7F3/Vdi0v /xxgD1DShzrxionhp/XFbXeuVzPz46qGmPFio6LWyI32qsi9LYiOGwPjghptuNDJsg2V a0lg== Received: by 10.68.134.232 with SMTP id pn8mr35475448pbb.106.1336777508419; Fri, 11 May 2012 16:05:08 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id qm3sm14087952pbc.12.2012.05.11.16.05.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 16:05:07 -0700 (PDT) Message-ID: <4FAD9B21.6070603@gmail.com> Date: Fri, 11 May 2012 15:05:05 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> In-Reply-To: <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , "tony@yaanatech.com" , Michael Hammer , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:05:09 -0000 On 5/11/12 3:03 PM, Stephen Farrell wrote: > Scalable Cross-domain Identity Migration? Pretty sure "scalable" is not that much of an improvement over "simple." Melinda From stephen.farrell@cs.tcd.ie Fri May 11 16:09:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317C621F8634 for ; Fri, 11 May 2012 16:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTOSTjPazXNe for ; Fri, 11 May 2012 16:09:14 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8154221F862F for ; Fri, 11 May 2012 16:09:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E33BF153570; Sat, 12 May 2012 00:09:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1336777753; bh=ao2+8 8j1hKlo4djGBL7/JJhUUt4zRGOhyreiJhCcApw=; b=Tkd3iR/wdlx+9fkNYNZlP lxz2qkYO0C0FoFkSsWG1fB8Lw6ULGcd8llPMF4yqXDTMivsWC+FSkdfvpRcH8fxI 65Kksp8a6utzEVsZa5t78RqwR3P9APcQZLG0KNrsF2k34LGr/yYI6TGGFam4YS1N l3lzdofEveSAzbgVJLPgMTfUcRbgNAyuVmJNcwA8ywPR/gDpiQxHJtRe0JpvZWeY UhfH8YeH4Kz0vlfew2WeKs871ti1kiuaUG8TtqakzFC8tYiV2KrMuyd5WuUZqTUu TYqFqvRm3wdUWM1/Nh7B9tTv+qvVQrWULVxbh5DNRHgTVCnvvSHImFhxDsM7GaAb A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id AmEOv0B7tjSY; Sat, 12 May 2012 00:09:13 +0100 (IST) Received: from [10.87.48.6] (unknown [86.45.59.27]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0034F15356F; Sat, 12 May 2012 00:09:12 +0100 (IST) References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> In-Reply-To: <4FAD9B21.6070603@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> X-Mailer: iPhone Mail (9B176) From: Stephen Farrell Date: Sat, 12 May 2012 00:09:05 +0100 To: Melinda Shore Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , "tony@yaanatech.com" , Michael Hammer , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:09:15 -0000 On 12 May 2012, at 00:05, Melinda Shore wrote: > On 5/11/12 3:03 PM, Stephen Farrell wrote: >> Scalable Cross-domain Identity Migration? > > Pretty sure "scalable" is not that much of an improvement over "simple." Yeah, nor would secure be. Whatever. S > > Melinda > From phil.hunt@oracle.com Fri May 11 16:10:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112A21F8624 for ; Fri, 11 May 2012 16:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.291 X-Spam-Level: X-Spam-Status: No, score=-10.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWusKoSgcVxp for ; Fri, 11 May 2012 16:10:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 588A921F8664 for ; Fri, 11 May 2012 16:10:51 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BNAiA6029801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 23:10:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BNAgFZ015596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 23:10:43 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BNAgru007329; Fri, 11 May 2012 18:10:42 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 16:10:42 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> Date: Fri, 11 May 2012 16:10:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: <498EEB4D-64AE-4D4A-8B13-D023E3D57B32@oracle.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , Melinda Shore , Michael Hammer , "tony@yaanatech.com" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:10:57 -0000 Sophisticated. Brings a new classy protocol to the IETF. 8-) Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-11, at 4:09 PM, Stephen Farrell wrote: > > > On 12 May 2012, at 00:05, Melinda Shore wrote: > >> On 5/11/12 3:03 PM, Stephen Farrell wrote: >>> Scalable Cross-domain Identity Migration? >> >> Pretty sure "scalable" is not that much of an improvement over "simple." > > Yeah, nor would secure be. Whatever. > > S > >> >> Melinda >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Fri May 11 16:13:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9B921F85D2 for ; Fri, 11 May 2012 16:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.304 X-Spam-Level: X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3ppgT1hvMRw for ; Fri, 11 May 2012 16:13:01 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89321F85D0 for ; Fri, 11 May 2012 16:13:01 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BNCueZ030905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 23:12:56 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BNCtl2028926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 23:12:56 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BNCtlP021739; Fri, 11 May 2012 18:12:55 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 16:12:55 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> Date: Fri, 11 May 2012 16:12:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , Melinda Shore , Michael Hammer , "tony@yaanatech.com" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:13:02 -0000 Service-based Cross-domain Identity Migration Ugh. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-11, at 4:09 PM, Stephen Farrell wrote: > > > On 12 May 2012, at 00:05, Melinda Shore wrote: > >> On 5/11/12 3:03 PM, Stephen Farrell wrote: >>> Scalable Cross-domain Identity Migration? >> >> Pretty sure "scalable" is not that much of an improvement over "simple." > > Yeah, nor would secure be. Whatever. > > S > >> >> Melinda >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.brenner@alcatel-lucent.com Fri May 11 16:45:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEDA9E800A for ; Fri, 11 May 2012 16:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.882 X-Spam-Level: X-Spam-Status: No, score=-7.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXSs9+Tysalz for ; Fri, 11 May 2012 16:45:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 81C2C21F852B for ; Fri, 11 May 2012 16:45:21 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4BNjH6k002752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 18:45:17 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BNjGDd026386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 May 2012 18:45:16 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 11 May 2012 18:45:16 -0500 From: "Brenner, Michael Ralf (Michael)" To: Phil Hunt , Stephen Farrell Date: Fri, 11 May 2012 18:45:15 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0vy5tQZWoXliQ2SRS52qEiZx3K4QABGzdw Message-ID: <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "scim@ietf.org" , Melinda Shore , Michael Hammer , "tony@yaanatech.com" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:45:22 -0000 No "service-based" in the charter text ... -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Friday, May 11, 2012 7:13 PM To: Stephen Farrell Cc: Melinda Shore; Brenner, Michael Ralf (Michael); scim@ietf.org; tony@yaa= natech.com; Michael Hammer Subject: Re: [scim] Feedback on the charter from IESG and IAB Service-based Cross-domain Identity Migration Ugh. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-11, at 4:09 PM, Stephen Farrell wrote: >=20 >=20 > On 12 May 2012, at 00:05, Melinda Shore wrote: >=20 >> On 5/11/12 3:03 PM, Stephen Farrell wrote: >>> Scalable Cross-domain Identity Migration? >>=20 >> Pretty sure "scalable" is not that much of an improvement over "simple." >=20 > Yeah, nor would secure be. Whatever. >=20 > S >=20 >>=20 >> Melinda >>=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.brenner@alcatel-lucent.com Fri May 11 16:46:59 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C089E8022 for ; Fri, 11 May 2012 16:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.699 X-Spam-Level: X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDzju9mkJ84Y for ; Fri, 11 May 2012 16:46:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0A83B9E8021 for ; Fri, 11 May 2012 16:46:58 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4BNktng003267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 18:46:55 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BNksns019251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 May 2012 18:46:54 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 11 May 2012 18:46:54 -0500 From: "Brenner, Michael Ralf (Michael)" To: "Brenner, Michael Ralf (Michael)" , Phil Hunt , Stephen Farrell Date: Fri, 11 May 2012 18:46:53 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0vy5tQZWoXliQ2SRS52qEiZx3K4QABGzdwAAALviA= Message-ID: <219947F0B2242843A0A1E62FDB510DC02511917E6B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "scim@ietf.org" , Melinda Shore , Michael Hammer , "tony@yaanatech.com" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:46:59 -0000 RESTful Identity Migration: RIM ... is the coincidence an issue? -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bre= nner, Michael Ralf (Michael) Sent: Friday, May 11, 2012 7:45 PM To: Phil Hunt; Stephen Farrell Cc: scim@ietf.org; Melinda Shore; Michael Hammer; tony@yaanatech.com Subject: Re: [scim] Feedback on the charter from IESG and IAB No "service-based" in the charter text ... -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Friday, May 11, 2012 7:13 PM To: Stephen Farrell Cc: Melinda Shore; Brenner, Michael Ralf (Michael); scim@ietf.org; tony@yaa= natech.com; Michael Hammer Subject: Re: [scim] Feedback on the charter from IESG and IAB Service-based Cross-domain Identity Migration Ugh. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-11, at 4:09 PM, Stephen Farrell wrote: >=20 >=20 > On 12 May 2012, at 00:05, Melinda Shore wrote: >=20 >> On 5/11/12 3:03 PM, Stephen Farrell wrote: >>> Scalable Cross-domain Identity Migration? >>=20 >> Pretty sure "scalable" is not that much of an improvement over "simple." >=20 > Yeah, nor would secure be. Whatever. >=20 > S >=20 >>=20 >> Melinda >>=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri May 11 16:53:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05A21F85B9 for ; Fri, 11 May 2012 16:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp7ZFZI-n90O for ; Fri, 11 May 2012 16:53:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83F5121F85B7 for ; Fri, 11 May 2012 16:53:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4038500pbc.31 for ; Fri, 11 May 2012 16:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SCSZv6wJsOn/Hw98qXzI6Ig9KZEFOVG/E76SUGoKHnk=; b=gZ3wLHlRvMfzIg4k2fV+FrwSzr94J2WXp6MBXmNKmsr07plFzaxuwa+5ZNXz8OIIX8 +cXKqCieTjE86O1EQk3G3XA0/l0HhYBAqLuVKEBcaFK0DbN1N/fiV1Wfi5niAD/iDblx n0xc1CWfQD2DMIBbX0ZyIZngnk3Xcs9CQ1cK9SyNFojBeTUaYSQ0j1u2/tG/bSN2Adiy L+bGOfKIJeyKxEnoVuG8fjGqbFZtFj5vewNc9dM4VibT4paac12BAN8r56N17RWdzhfT fB4rdwbHE65iY5gQsyUoYoWer1olB8H+k0KQdqRjuVKb6yFozISLhkNdao7HCHCuEg4M QGoQ== Received: by 10.68.193.233 with SMTP id hr9mr58114pbc.99.1336780418014; Fri, 11 May 2012 16:53:38 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id pu10sm14171326pbc.57.2012.05.11.16.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 16:53:37 -0700 (PDT) Message-ID: <4FADA67F.1000405@gmail.com> Date: Fri, 11 May 2012 15:53:35 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Brenner, Michael Ralf (Michael)" References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC02511917E6B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC02511917E6B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Stephen Farrell , Michael Hammer , "tony@yaanatech.com" , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:53:39 -0000 On 5/11/12 3:46 PM, Brenner, Michael Ralf (Michael) wrote: > RESTful Identity Migration: RIM ... is the coincidence an issue? There's about 45 things wrong with that one. I'm personally not a fan of cute IETF acronyms and tend to prefer names that actually describe the thing being named. RESTful Identity Provisioning unfortunately shares an acronym with an important existing protocol's name, but something like Interdomain RESTful Identity Provisioning would get around that (there are obvious problems with "Cross-domain RESTful Identity Provisioning"). At any rate there were some other bullet items in the feedback from the IESG and IAB. Melinda From michael.brenner@alcatel-lucent.com Fri May 11 17:01:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926AD9E800B for ; Fri, 11 May 2012 17:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.561 X-Spam-Level: X-Spam-Status: No, score=-7.561 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ocUrfmWCWVQ for ; Fri, 11 May 2012 17:01:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 102AA9E800A for ; Fri, 11 May 2012 17:01:44 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4C01eKl019260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:01:40 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4C01dOS022211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 May 2012 19:01:40 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 11 May 2012 19:01:39 -0500 From: "Brenner, Michael Ralf (Michael)" To: Melinda Shore Date: Fri, 11 May 2012 19:01:38 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0v0UodRQL01eVBTfG193rhqfvLEgAALeNw Message-ID: <219947F0B2242843A0A1E62FDB510DC02511917E6D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC02511917E6B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FADA67F.1000405@gmail.com> In-Reply-To: <4FADA67F.1000405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "scim@ietf.org" , Stephen Farrell , Michael Hammer , "tony@yaanatech.com" , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 00:01:45 -0000 Nor am I for cute names, but IRIP sounds kind of morbid (and that's not muc= h better than cute). Although it may catch fire with sci-fi fans. -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com]=20 Sent: Friday, May 11, 2012 7:54 PM To: Brenner, Michael Ralf (Michael) Cc: Phil Hunt; Stephen Farrell; scim@ietf.org; Michael Hammer; tony@yaanate= ch.com Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/11/12 3:46 PM, Brenner, Michael Ralf (Michael) wrote: > RESTful Identity Migration: RIM ... is the coincidence an issue? There's about 45 things wrong with that one. I'm personally not a fan of cute IETF acronyms and tend to prefer names that actually describe the thing being named. RESTful Identity Provisioning unfortunately shares an acronym with an important existing protocol's name, but something like Interdomain RESTful Identity Provisioning would get around that (there are obvious problems with "Cross-domain RESTful Identity Provisioning"). At any rate there were some other bullet items in the feedback from the IESG and IAB. Melinda From stpeter@stpeter.im Fri May 11 21:48:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD621F85D5 for ; Fri, 11 May 2012 21:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfN5LuPZTFrk for ; Fri, 11 May 2012 21:48:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7021F85D2 for ; Fri, 11 May 2012 21:48:32 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8FA0B4005A; Fri, 11 May 2012 23:04:00 -0600 (MDT) Message-ID: <4FADEB9E.4080203@stpeter.im> Date: Fri, 11 May 2012 22:48:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Pete Resnick References: <4FAD45B3.8020202@qualcomm.com> In-Reply-To: <4FAD45B3.8020202@qualcomm.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 04:48:33 -0000 On 5/11/12 11:00 AM, Pete Resnick wrote: > On 5/11/12 8:55 AM, Barry Leiba wrote: >> 4. The name did come up (I told you...). It's not getting in the way, >> at least not yet, but folks are balking at both the "simple" and the >> "cloud" parts. They wonder if there isn't a way to keep "scim", but >> to make up something new that it can stand for. Keep in mind that >> this is a minor point, though -- the other three above need to be >> fixed. >> > > "Yet" has arrived. It is getting in the way. Here's more or less what I > said to the IESG: > > Having the word "simple" is just nonsense and I think it should go, but > that's not my big concern. > > Having the word "cloud" is flypaper for the loons to come out of the > woodwork and disrupt this WG. There will obviously be engineering loons > who will come to work on this thing simply because it is about "clouds" > and try to get their cloud nonsense into the work. But there also will > be press loons, and there will be otherwise normal people who end up > pandering to the press loons. I think this will really do damage to the > productivity of the WG. > > (Others in the IESG are equally concerned about "Identity Management", > in that we have lots of work on what people refer to as "Identity > Management", but it normally involves protocols used to log in and log > out, which is not what this is doing.) Pete, I'm surprised that you didn't object to "identity", which as I learned when working on RFC 6125 is awfully vague (it's much better to talk about identifiers and attributes and such, not identity). By contrast, (1) "simple" might be light on content but it I think it was related to one purpose behind this initiative, which was to keep it simple and not add undue complexity, (2) "cloud" hasn't brought out loons yet so I don't see why we're worried about future loonies, and (3) management seems like an apprpriate term for moving information from one place to another. > The "name recognition" argument does nothing for me. Jabber survived > just fine after it got called XMPP in the IETF. You can continue to call > your management scheme "SCIM" in your own circles, but in the IETF it > should have a name that doesn't carry baggage. Having gone through the Jabber=>XMPP transition, I can tell you that ten years later it *still* confuses people. > I am truly opposed to the current name. Come up with a new name. Please. Silly Changes for IESG Mandates? ;-) Although I think the name was a Stupid Choice to Improve Marketing, it doesn't seem actively harmful to me. Most people are just going to call it "SCIM" anyway and won't even know what it stands for. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Sat May 12 06:05:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5590F21F8648 for ; Sat, 12 May 2012 06:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXpbJi4n30lt for ; Sat, 12 May 2012 06:05:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20D21F861F for ; Sat, 12 May 2012 06:05:40 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2798378lbb.31 for ; Sat, 12 May 2012 06:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Gt/3gsqKHBU+KAU3P3Qx4ZMA0oTBd2DO0Ys+QpqZlzU=; b=uGltZnGK6d5neybcTyIDUJ5o5fQv8C60NdU+X8k7+d03Rsf8hBMOBgCDbqhl4y8rhF +J5MfoXqjYiUbDveJX2sKbvkF0lbVk8HQq6uvn8UhGP6rTptvcLEhDQVTcWSHu5qQMS0 h5HlTrwXoedZdp09/vd2VUY5WCfrMSfL4PUSf1JE2ViXwDDSwZucbDW5+DVLsjhqnwZZ zfYHN2rJ1ZAWJZVcJvMgyMIr8lfOyvU0Waus+WR5IbjSPPegYACuEGtKcdbnyJw2HkwP pXu0W6WigqY4R7LgV6lFVFoMGJQop5WtVnDBKvvNlhCS5i5LQO7UBiUHFa5R1LFfRzVW 2vLw== MIME-Version: 1.0 Received: by 10.112.88.98 with SMTP id bf2mr763878lbb.30.1336827940034; Sat, 12 May 2012 06:05:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Sat, 12 May 2012 06:05:39 -0700 (PDT) In-Reply-To: <4FADA67F.1000405@gmail.com> References: <4FAD49DF.6090600@gmail.com> <00C069FD01E0324C9FFCADF539701DB38AA6E2@EX2K10MB1.corp.yaanatech.com> <219947F0B2242843A0A1E62FDB510DC02511917D1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FAD8005.4070706@yaanatech.com> <91DB79DF-0C50-48F0-B353-222BA1A99541@oracle.com> <7276A8C4-44A2-4E5C-AB0B-09A25DAFC78C@cs.tcd.ie> <4FAD9B21.6070603@gmail.com> <2A1166BD-406B-4FBE-83AA-566EBA18FE57@cs.tcd.ie> <219947F0B2242843A0A1E62FDB510DC02511917E6A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC02511917E6B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FADA67F.1000405@gmail.com> Date: Sat, 12 May 2012 09:05:39 -0400 X-Google-Sender-Auth: zYZEBuHzfc-YIfIv1A8lOsQHezg Message-ID: From: Barry Leiba To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 Cc: "tony@yaanatech.com" , "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , Stephen Farrell , Michael Hammer , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 13:05:42 -0000 > At any rate there were some other bullet items in the feedback > from the IESG and IAB. Indeed, and I'd like to fix those up first. How 'bout we say this?: Everyone think about the naming thing, and/or sharpen your twibil for when you see Pete in Vancouver... but *think* about it, letting it roll around in the back of your mind. In the front of your mind, and on the tips of your fingers, work on sorting out the other three items I mentioned: 1. Confirm that I have the milestone changes right. 2. Explain the "gaps" stuff, and help fix up the text so it doesn't give Stephen the willies. 3. Help resolve the point about how to handle the schema with respect to potential problems with the LDAP mapping (and maybe the SAML profile as well). Barry From lear@cisco.com Sun May 13 23:19:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C421F84DE for ; Sun, 13 May 2012 23:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.346 X-Spam-Level: X-Spam-Status: No, score=-110.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puWrD6iUq6WP for ; Sun, 13 May 2012 23:19:35 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70421F85A4 for ; Sun, 13 May 2012 23:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1400; q=dns/txt; s=iport; t=1336976375; x=1338185975; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TTT6bCCUXF3Wqmpug1587ZdRAoM1/LBC4aLjVVZFIlM=; b=OOm034o/Lea5WObMa7X1c2lCKZJupzE/mZLLvUrlEROMsjqeUPSO7gV1 GRYOPH59NnRmaNqFdlcPcHmrC8yb6WT9LOX2XF7/F+4tm35LLeVLogP8v OTPLeKtR04Rqda1DIFavKQzdd4gOi+gUheUYaZzqZ3v49rkHB/tX2Kkz5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHijsE+Q/khR/2dsb2JhbABEhXmtZYEHghUBAQEDARIBEFYQCxgCAgUhAgIPAkYGDQEHAQEeh2cFml6NFpF8gTCOWoEYBJV9jleBaYJr X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="4445000" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 14 May 2012 06:19:33 +0000 Received: from elear-mac.local (ams3-vpn-dhcp4634.cisco.com [10.61.82.25]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4E6JXdG020732; Mon, 14 May 2012 06:19:33 GMT Message-ID: <4FB0A3F5.70300@cisco.com> Date: Mon, 14 May 2012 08:19:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 06:19:36 -0000 Dear Barry, I wanted to comment on your substantial issues 2 and 3: On 5/11/12 3:55 PM, Barry Leiba wrote: > > 2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > What's that really meant to be saying? That is, why shouldn't the > sentence simply end after "good security practices"? We certainly > can't produce documents that *don't* use good security practices, so > if the rest of the sentence is important we have to separate it and > make it clear what we're getting at. +1. Let's just drop the text after practices. > > 3. There's concern by more than one AD that doing the schema > definition without having the LDAP mapping there with it will result > in problems, and will end up with a new schema that ultimately has as > many problems as the existing one(s). The best suggestion to deal > with that is to move the order around, do the LDAP mapping along with > the schema, and send both documents to the IESG together. +1, although I find the interoperability risk in this case low. My logic is that there are at leastnine implementations already in development. In addition, this is sort of what PS is meant to kink out. Eliot From moransar@cisco.com Mon May 14 01:50:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AEC21F85D3 for ; Mon, 14 May 2012 01:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1rfrXxb0-Ge for ; Mon, 14 May 2012 01:50:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD021F85D1 for ; Mon, 14 May 2012 01:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=4755; q=dns/txt; s=iport; t=1336985428; x=1338195028; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Z6AbywLDh/uopg9fDmT6jux/nrlUcytL7wKv8s4fsJU=; b=Ow0B1Sa51hJx4Aq3lcsUInewS7TVy+mbnxKhE0E0y8gOXS2Pfcd2mZG8 7VwHuXhXsxiDcyJO9w20J11BTvmFj0G53cXRkLQhYhAsHNx2UvCRCSJah QR52PEOtCicElcLY4aYpnOmOSa5EdikxdaaJlMbefjTjQVdSFgD1fCjXO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACO4sE+tJV2Y/2dsb2JhbAA7CbNggQeCFQEBAQMBEgEdCkQHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2cFmmOfG4saEIUVYwSIZJtwgWmDBw X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="82885023" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2012 07:47:21 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4E7lLZ6017742; Mon, 14 May 2012 07:47:21 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 02:47:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 02:47:20 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0vfcRR5MWxp9cmSXeUpbm/MLHZEgCJAjVQ References: From: "Morteza Ansari (moransar)" To: "Barry Leiba" , X-OriginalArrivalTime: 14 May 2012 07:47:21.0098 (UTC) FILETIME=[CB21FEA0:01CD31A5] Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:50:35 -0000 Comments inline: -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Friday, May 11, 2012 6:56 AM To: scim@ietf.org Subject: [scim] Feedback on the charter from IESG and IAB The first step in chartering is to get feedback from the IESG and IAB, and I have the first few comments. For the record, the attached charter text is what's being commented on. 1. We should include intended document status in the milestones. To that end, I suggest this: 06/2012 Initial adoption of SCIM use cases, as a living document 06/2012 Initial adoption of SCIM core schema 08/2012 Initial adoption of SCIM restful interface draft | 12/2012 Snapshot version of SCIM use cases to IESG as Informational (possibly) 12/2012 Proposal for client targeting of SCIM endpoints | 02/2013 SCIM core schema to IESG as Proposed Standard | 05/2013 SCIM restful interface to IESG as Proposed Standard 07/2013 Initial adoption of SCIM SAML bindings draft 07/2013 Initial adoption of SCIM LDAP mapping draft | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard | 09/2013 Snapshot update of SCIM use cases as Informational (possibly) | 11/2013 SCIM SAML bindings to IESG as Proposed Standard | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter Are those correct? That is, everything is meant to be Proposed Standard except for the use cases document (which might or might not get published)? MA> I was thinking LDAP mapping would be informational as there are many variations of identity schema in LDAP directories and this would only be an instantiation of such mapping. However if others think this should be proposed standard, I am fine with it. 2. There's concern about the "gaps" text in this part: > In addition, the working group will ensure that the SCIM protocol =20 > embodies good security practices, and will document gaps in its =20 > capabilities and propose a path forward for addressing those gaps. What's that really meant to be saying? That is, why shouldn't the sentence simply end after "good security practices"? We certainly can't produce documents that *don't* use good security practices, so if the rest of the sentence is important we have to separate it and make it clear what we're getting at. MA> I think this is a side effect of tweaking the original paragraph over 9 revision and an unintentional use of gap in the context of "security practices". I originally put the "functional gap" in the charter as we are starting with a list of protocol/schema extensions some of the vendors were interested in, but we felt need additional discussion and thinking so we left them out of 1.0 specs. The goal of this original sentence was that the WG will review this list of gaps and decide what to do with them. This had nothing to do with security. Unfortunately between version 8 and 9, this was changed in addition to "functional gaps" we ended up with "gap" in the new paragraph covering security. I am perfectly find removing it and making it more clear. 3. There's concern by more than one AD that doing the schema definition without having the LDAP mapping there with it will result in problems, and will end up with a new schema that ultimately has as many problems as the existing one(s). The best suggestion to deal with that is to move the order around, do the LDAP mapping along with the schema, and send both documents to the IESG together. MA> I am fine with that change. 4. The name did come up (I told you...). It's not getting in the way, at least not yet, but folks are balking at both the "simple" and the "cloud" parts. They wonder if there isn't a way to keep "scim", but to make up something new that it can stand for. Keep in mind that this is a minor point, though -- the other three above need to be fixed. MA> Personally speaking, I still think we should stick with SCIM. If the current traction of SCIM v1 is any indication, by the time v2 is out there will be quite a few implementations of it out there and we will have many implementations (we are almost at 10 now). A rename between v1 and v2 will only result in confusion and 10 years from now we will be using both SCIM and new name to refer to it. It is not worth it especially if you consider other protocol names that have "simple" in the name (including IETF protocols). If we *really* must change something, let's stay with SCIM and change "cloud" which is the only word there is no precedence for something else like "cross-domain" Stephen suggested. Cheers, Morteza From phil.hunt@oracle.com Mon May 14 06:32:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20E021F859E for ; Mon, 14 May 2012 06:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JabbxgmmtyXA for ; Mon, 14 May 2012 06:32:44 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A27B221F843E for ; Mon, 14 May 2012 06:32:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4EDWfcg022736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2012 13:32:42 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4EDWfP3016636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 13:32:41 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4EDWfFl010250; Mon, 14 May 2012 08:32:41 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 May 2012 06:32:41 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> Date: Mon, 14 May 2012 06:32:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> To: "Morteza Ansari (moransar)" X-Mailer: Apple Mail (2.1257) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:32:46 -0000 Unfortunately, no draft proposal for the LDAP Mapping has been submitted = to IETF for consideration. So it is not clear to me what the objective = of an LDAP mapping draft is -- though I can guess based on the name. As Morteza points out, many LDAP variations are possible and I agree, = very likely given the suggested architecture in the SCIM scenarios.=20 Is the LDAP mapping draft limited to specifying how complex attributes = are handled? Or does it cover more? What is the interop issue being = solved? I'm not saying I'm against it, but I can't comment without seeing more = about it. The same is true for the SAML binding (no draft). Though I can guess = more clearly the scope of such a binding. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-14, at 12:47 AM, Morteza Ansari (moransar) wrote: > Comments inline: >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of > Barry Leiba > Sent: Friday, May 11, 2012 6:56 AM > To: scim@ietf.org > Subject: [scim] Feedback on the charter from IESG and IAB >=20 > The first step in chartering is to get feedback from the IESG and IAB, > and I have the first few comments. For the record, the attached = charter > text is what's being commented on. >=20 > 1. We should include intended document status in the milestones. To > that end, I suggest this: >=20 > 06/2012 Initial adoption of SCIM use cases, as a living document > 06/2012 Initial adoption of SCIM core schema > 08/2012 Initial adoption of SCIM restful interface draft > | 12/2012 Snapshot version of SCIM use cases to IESG as > Informational (possibly) > 12/2012 Proposal for client targeting of SCIM endpoints > | 02/2013 SCIM core schema to IESG as Proposed Standard > | 05/2013 SCIM restful interface to IESG as Proposed Standard > 07/2013 Initial adoption of SCIM SAML bindings draft > 07/2013 Initial adoption of SCIM LDAP mapping draft > | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed > Standard > | 09/2013 Snapshot update of SCIM use cases as Informational > (possibly) > | 11/2013 SCIM SAML bindings to IESG as Proposed Standard > | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard > 01/2014 Work completed; discuss re-charter >=20 > Are those correct? That is, everything is meant to be Proposed = Standard > except for the use cases document (which might or might not get > published)? >=20 > MA> I was thinking LDAP mapping would be informational as there are = many > variations of identity schema in LDAP directories and this would only = be > an instantiation of such mapping. However if others think this should = be > proposed standard, I am fine with it. >=20 > 2. There's concern about the "gaps" text in this part: >=20 >> In addition, the working group will ensure that the SCIM protocol =20 >> embodies good security practices, and will document gaps in its =20 >> capabilities and propose a path forward for addressing those gaps. >=20 > What's that really meant to be saying? That is, why shouldn't the > sentence simply end after "good security practices"? We certainly = can't > produce documents that *don't* use good security practices, so if the > rest of the sentence is important we have to separate it and make it > clear what we're getting at. >=20 > MA> I think this is a side effect of tweaking the original paragraph > over 9 revision and an unintentional use of gap in the context of > "security practices". I originally put the "functional gap" in the > charter as we are starting with a list of protocol/schema extensions > some of the vendors were interested in, but we felt need additional > discussion and thinking so we left them out of 1.0 specs. The goal of > this original sentence was that the WG will review this list of gaps = and > decide what to do with them. This had nothing to do with security. > Unfortunately between version 8 and 9, this was changed in addition to > "functional gaps" we ended up with "gap" in the new paragraph covering > security. I am perfectly find removing it and making it more clear. >=20 > 3. There's concern by more than one AD that doing the schema = definition > without having the LDAP mapping there with it will result in problems, > and will end up with a new schema that ultimately has as many problems > as the existing one(s). The best suggestion to deal with that is to > move the order around, do the LDAP mapping along with the schema, and > send both documents to the IESG together. >=20 > MA> I am fine with that change. >=20 > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but = to > make up something new that it can stand for. Keep in mind that this = is > a minor point, though -- the other three above need to be fixed. >=20 > MA> Personally speaking, I still think we should stick with SCIM. If = the > current traction of SCIM v1 is any indication, by the time v2 is out > there will be quite a few implementations of it out there and we will > have many implementations (we are almost at 10 now). A rename between = v1 > and v2 will only result in confusion and 10 years from now we will be > using both SCIM and new name to refer to it. It is not worth it > especially if you consider other protocol names that have "simple" in > the name (including IETF protocols). If we *really* must change > something, let's stay with SCIM and change "cloud" which is the only > word there is no precedence for something else like "cross-domain" > Stephen suggested. >=20 >=20 > Cheers, > Morteza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Mon May 14 06:35:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8BE21F849A for ; Mon, 14 May 2012 06:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.74 X-Spam-Level: X-Spam-Status: No, score=-3.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-rtFUf-4YB8 for ; Mon, 14 May 2012 06:35:17 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 971FA21F85A3 for ; Mon, 14 May 2012 06:35:17 -0700 (PDT) Received: from mail71-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Mon, 14 May 2012 13:35:12 +0000 Received: from mail71-ch1 (localhost [127.0.0.1]) by mail71-ch1-R.bigfish.com (Postfix) with ESMTP id BC520601E2; Mon, 14 May 2012 13:35:12 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail71-ch1: domain of sailpoint.com designates 157.56.240.85 as permitted sender) client-ip=157.56.240.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail71-ch1 (localhost.localdomain [127.0.0.1]) by mail71-ch1 (MessageSwitch) id 1337002510598492_22524; Mon, 14 May 2012 13:35:10 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail71-ch1.bigfish.com (Postfix) with ESMTP id 839012000CB; Mon, 14 May 2012 13:35:10 +0000 (UTC) Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 14 May 2012 13:35:04 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.108]) by BL2PRD0410HT001.namprd04.prod.outlook.com ([10.255.99.36]) with mapi id 14.16.0152.000; Mon, 14 May 2012 13:35:07 +0000 From: Kelly Grizzle To: "Morteza Ansari (moransar)" , Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33HX/k3k5Flb0qGWMZ8dW6jIZbI7JkAgABfwTA= Date: Mon, 14 May 2012 13:35:06 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:35:18 -0000 +1 on removing the "gaps" text. +1 on at least keeping the SCIM acronym. To Peter's point, as an outsider = I had heard of both Jabber and XMPP, but until recently had no idea that th= e two were the same. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mor= teza Ansari (moransar) Sent: Monday, May 14, 2012 2:47 AM To: Barry Leiba; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB Comments inline: -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Friday, May 11, 2012 6:56 AM To: scim@ietf.org Subject: [scim] Feedback on the charter from IESG and IAB The first step in chartering is to get feedback from the IESG and IAB, and = I have the first few comments. For the record, the attached charter text i= s what's being commented on. 1. We should include intended document status in the milestones. To that e= nd, I suggest this: 06/2012 Initial adoption of SCIM use cases, as a living document 06/2012 Initial adoption of SCIM core schema 08/2012 Initial adoption of SCIM restful interface draft | 12/2012 Snapshot version of SCIM use cases to IESG as Informational (possibly) 12/2012 Proposal for client targeting of SCIM endpoints | 02/2013 SCIM core schema to IESG as Proposed Standard | 05/2013 SCIM restful interface to IESG as Proposed Standard 07/2013 Initial adoption of SCIM SAML bindings draft 07/2013 Initial adoption of SCIM LDAP mapping draft | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard | 09/2013 Snapshot update of SCIM use cases as Informational (possibly) | 11/2013 SCIM SAML bindings to IESG as Proposed Standard | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter Are those correct? That is, everything is meant to be Proposed Standard ex= cept for the use cases document (which might or might not get published)? MA> I was thinking LDAP mapping would be informational as there are many variations of identity schema in LDAP directories and this would only be an= instantiation of such mapping. However if others think this should be prop= osed standard, I am fine with it. 2. There's concern about the "gaps" text in this part: > In addition, the working group will ensure that the SCIM protocol=20 > embodies good security practices, and will document gaps in its=20 > capabilities and propose a path forward for addressing those gaps. What's that really meant to be saying? That is, why shouldn't the sentence= simply end after "good security practices"? We certainly can't produce do= cuments that *don't* use good security practices, so if the rest of the sen= tence is important we have to separate it and make it clear what we're gett= ing at. MA> I think this is a side effect of tweaking the original paragraph over 9 revision and an unintentional use of gap in the context of "security= practices". I originally put the "functional gap" in the charter as we are= starting with a list of protocol/schema extensions some of the vendors we= re interested in, but we felt need additional discussion and thinking so we= left them out of 1.0 specs. The goal of this original sentence was that th= e WG will review this list of gaps and decide what to do with them. This ha= d nothing to do with security. Unfortunately between version 8 and 9, this was changed in addition to "fun= ctional gaps" we ended up with "gap" in the new paragraph covering security= . I am perfectly find removing it and making it more clear. 3. There's concern by more than one AD that doing the schema definition wit= hout having the LDAP mapping there with it will result in problems, and wil= l end up with a new schema that ultimately has as many problems as the exis= ting one(s). The best suggestion to deal with that is to move the order ar= ound, do the LDAP mapping along with the schema, and send both documents to= the IESG together. MA> I am fine with that change. 4. The name did come up (I told you...). It's not getting in the way, at l= east not yet, but folks are balking at both the "simple" and the "cloud" pa= rts. They wonder if there isn't a way to keep "scim", but to make up somet= hing new that it can stand for. Keep in mind that this is a minor point, t= hough -- the other three above need to be fixed. MA> Personally speaking, I still think we should stick with SCIM. If the current traction of SCIM v1 is any indication, by the time v2 is out there = will be quite a few implementations of it out there and we will have many i= mplementations (we are almost at 10 now). A rename between v1 and v2 will o= nly result in confusion and 10 years from now we will be using both SCIM an= d new name to refer to it. It is not worth it especially if you consider ot= her protocol names that have "simple" in the name (including IETF protocols= ). If we *really* must change something, let's stay with SCIM and change "c= loud" which is the only word there is no precedence for something else like= "cross-domain" Stephen suggested. Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From Chris.Phillips@canarie.ca Mon May 14 07:25:50 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7428821F8758 for ; Mon, 14 May 2012 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2gUWbOrYTdX for ; Mon, 14 May 2012 07:25:49 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4F21F8620 for ; Mon, 14 May 2012 07:25:49 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 14 May 2012 10:25:48 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Mon, 14 May 2012 10:25:46 -0400 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0x3XTdvkvRm4OyRXO7t+i22ycy+w== Message-ID: In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:25:50 -0000 +1 to clarifying the gap portion as Morteza offers =20 Working on the LDAP & SAML mapping pieces, there are some interesting places this could go (e.g. How much of a SCIM transaction should be encapsulated within a SAML based trust environment instead of over HTTP with TLS or HTTP+OAUTH? Are the security challenges the same or different for how SCIM reaches the endpoints? what security challenges should be commented on/folded into the spec? Those are the topics I see being fleshed out more deeply as the conversation continues. +1 to keeping the SCIM name/acronym. =20 The longevity of the original name will persist for years as others have pointed out and is confusing as people try to find the right information about the topic.=20 Jabber as XMPP is one, and another I have been observing is Project Moonshot but known as ABFAB in the IETF, which is hard to understand looking from the outside in as to why this was done. I would put forth that existing implementations already out there have some public mindshare in the provisioning space. This attention benefits both 'brands', SCIM, AND the IETF as being seen in the public eye as involved. Keeping the name will fortify it, changing the name will be a less fortified position and still have some confusion in the environment. To the question about LDAP mappings: While there are a number of LDAP variations out there, many schemas descend from inetOrgPerson and extend from there. This is the starting point for the mappings. Stumbling blocks have always been 'what to do with complex objects?' for LDAP (and anything else actually). The high fidelity SCIM schema is great for SCIM-to-SCIM endpoints to preserve data exchange regardless of what your data model is, but it is expected that the SCIM high fidelity schema will be transformed to a lower fidelity one depending on the endpoint's capabilities(e.g. LDAP). Recommending ways to do it will benefit adopters everywhere breeding consistency of mappings, leveraging existing schemas in production, and allow implementers to focus on their data, not how to get it from point A to point B. =20 Chris. On 12-05-14 3:47 AM, "Morteza Ansari (moransar)" wrote: >Comments inline: > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Barry Leiba >Sent: Friday, May 11, 2012 6:56 AM >To: scim@ietf.org >Subject: [scim] Feedback on the charter from IESG and IAB > >The first step in chartering is to get feedback from the IESG and IAB, >and I have the first few comments. For the record, the attached charter >text is what's being commented on. > >1. We should include intended document status in the milestones. To >that end, I suggest this: > > 06/2012 Initial adoption of SCIM use cases, as a living document > 06/2012 Initial adoption of SCIM core schema > 08/2012 Initial adoption of SCIM restful interface draft >| 12/2012 Snapshot version of SCIM use cases to IESG as >Informational (possibly) > 12/2012 Proposal for client targeting of SCIM endpoints >| 02/2013 SCIM core schema to IESG as Proposed Standard >| 05/2013 SCIM restful interface to IESG as Proposed Standard > 07/2013 Initial adoption of SCIM SAML bindings draft > 07/2013 Initial adoption of SCIM LDAP mapping draft >| 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >Standard >| 09/2013 Snapshot update of SCIM use cases as Informational >(possibly) >| 11/2013 SCIM SAML bindings to IESG as Proposed Standard >| 12/2013 SCIM LDAP mapping to IESG as Proposed Standard > 01/2014 Work completed; discuss re-charter > >Are those correct? That is, everything is meant to be Proposed Standard >except for the use cases document (which might or might not get >published)? > >MA> I was thinking LDAP mapping would be informational as there are many >variations of identity schema in LDAP directories and this would only be >an instantiation of such mapping. However if others think this should be >proposed standard, I am fine with it. > >2. There's concern about the "gaps" text in this part: > >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices, and will document gaps in its >> capabilities and propose a path forward for addressing those gaps. > >What's that really meant to be saying? That is, why shouldn't the >sentence simply end after "good security practices"? We certainly can't >produce documents that *don't* use good security practices, so if the >rest of the sentence is important we have to separate it and make it >clear what we're getting at. > >MA> I think this is a side effect of tweaking the original paragraph >over 9 revision and an unintentional use of gap in the context of >"security practices". I originally put the "functional gap" in the >charter as we are starting with a list of protocol/schema extensions >some of the vendors were interested in, but we felt need additional >discussion and thinking so we left them out of 1.0 specs. The goal of >this original sentence was that the WG will review this list of gaps and >decide what to do with them. This had nothing to do with security. >Unfortunately between version 8 and 9, this was changed in addition to >"functional gaps" we ended up with "gap" in the new paragraph covering >security. I am perfectly find removing it and making it more clear. > >3. There's concern by more than one AD that doing the schema definition >without having the LDAP mapping there with it will result in problems, >and will end up with a new schema that ultimately has as many problems >as the existing one(s). The best suggestion to deal with that is to >move the order around, do the LDAP mapping along with the schema, and >send both documents to the IESG together. > >MA> I am fine with that change. > >4. The name did come up (I told you...). It's not getting in the way, >at least not yet, but folks are balking at both the "simple" and the >"cloud" parts. They wonder if there isn't a way to keep "scim", but to >make up something new that it can stand for. Keep in mind that this is >a minor point, though -- the other three above need to be fixed. > >MA> Personally speaking, I still think we should stick with SCIM. If the >current traction of SCIM v1 is any indication, by the time v2 is out >there will be quite a few implementations of it out there and we will >have many implementations (we are almost at 10 now). A rename between v1 >and v2 will only result in confusion and 10 years from now we will be >using both SCIM and new name to refer to it. It is not worth it >especially if you consider other protocol names that have "simple" in >the name (including IETF protocols). If we *really* must change >something, let's stay with SCIM and change "cloud" which is the only >word there is no precedence for something else like "cross-domain" >Stephen suggested. > > >Cheers, >Morteza >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From wmills@yahoo-inc.com Mon May 14 10:05:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF92121F88B8 for ; Mon, 14 May 2012 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.233 X-Spam-Level: X-Spam-Status: No, score=-17.233 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KFVx+SZs41s for ; Mon, 14 May 2012 10:05:48 -0700 (PDT) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) by ietfa.amsl.com (Postfix) with SMTP id AE02421F88B4 for ; Mon, 14 May 2012 10:05:47 -0700 (PDT) Received: from [98.139.212.146] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 17:05:46 -0000 Received: from [98.139.212.216] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 17:05:46 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 14 May 2012 17:05:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 735297.39296.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 53601 invoked by uid 60001); 14 May 2012 17:05:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337015145; bh=eWBWLQ9onEhiSsSK74AaYYoTvZgkqDPG1f89u7JDC9A=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FC/WOZYpI3Nf0v9RUFaTzP+WaMj4B0kGEmFARKGV6m/CMvG6rv7mJqLRJcfBt58J0Q1vsVxw3XI2TJFw1ePPab5EugzL+yyh471yXAjRKpFkMCmI8AWVJB8Smgz9NKfM4zNHWZsSvxjwhe5d5CZiqJhrZGs+Cs+UVIfmUhfQR7k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ffbqb3Ke4viVesfUAHuXYP1cq9qAy+usPtFhz+m7cRlRreZYfj3wjP1OaFZyz/f3no/7PKL9ZEU/FUz3K5/A6+pqmjeIMehN9QDWcK2uJ32ZTa4uDAHKycgymz9LHBZNO8SDQB2mApswsAx4shuJE4FQ5WH7cx5Un2LqvRiuCus=; X-YMail-OSG: z1sPXKAVM1lRqgelmfQ3xV9sXp2VR0cySzlN1GK9nSjcmxM RkQI4caDO38L7om.s8aaN2A3Qae5xIHpnryORBpuzq6WWBEPAk6bTOBiG9g7 27X2ouaYkkLtmHsve8Wz2eiLAJBxPqC6EshKR10j73w5Yf0TfDW1MJp6zSMr UiB8TLYq_DOrNxqBQ5UGxOv6AytGmxNUZ7yyUrZRoO0nCmrRIut5PDSLoJ_Q eci.v9Y_.L.dsP5sYJVIMpZtz1xpqit2HHrSgl2sXsRo7zK1nfo0bMRfmt9s p87vMzYNCXc93AoQ0Ce7Q33TFkIAhjXBVlIFk.ZY9sxD0h2y7326o6iOn51H 6FUFdpT5DSWQ9oTB8TvP7dRV7yZbSW1vTz.iyXTVhoOXhbsTtbxsGWRofcy8 1ZOLwgSKq_KaF_ITJlY0.UghAIJcfe3e6Qrni Received: from [209.131.62.114] by web31807.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 10:05:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> Message-ID: <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Mon, 14 May 2012 10:05:45 -0700 (PDT) From: William Mills To: Kelly Grizzle , "Morteza Ansari \(moransar\)" , Barry Leiba , "scim@ietf.org" In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-2031769109-1337015145=:53055" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:05:56 -0000 ---125733401-2031769109-1337015145=:53055 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On naming persistency, I'll add TLS and SSL...=0A=0A=0A=0A=0A>_____________= ___________________=0A> From: Kelly Grizzle = =0A>To: Morteza Ansari (moransar) ; Barry Leiba ; "scim@ietf.org" =0A>Sent: Monday, May 1= 4, 2012 6:35 AM=0A>Subject: Re: [scim] Feedback on the charter from IESG an= d IAB=0A> =0A>+1 on removing the "gaps" text.=0A>=0A>+1 on at least keeping= the SCIM acronym.=A0 To Peter's point, as an outsider I had heard of both = Jabber and XMPP, but until recently had no idea that the two were the same.= =0A>=0A>--Kelly=0A>=0A>-----Original Message-----=0A>From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)= =0A>Sent: Monday, May 14, 2012 2:47 AM=0A>To: Barry Leiba; scim@ietf.org=0A= >Subject: Re: [scim] Feedback on the charter from IESG and IAB=0A>=0A>Comme= nts inline:=0A>=0A>-----Original Message-----=0A>From: scim-bounces@ietf.or= g [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba=0A>Sent: Friday, = May 11, 2012 6:56 AM=0A>To: scim@ietf.org=0A>Subject: [scim] Feedback on th= e charter from IESG and IAB=0A>=0A>The first step in chartering is to get f= eedback from the IESG and IAB, and I have the first few comments.=A0 For th= e record, the attached charter text is what's being commented on.=0A>=0A>1.= We should include intended document status in the milestones.=A0 To that e= nd, I suggest this:=0A>=0A>=A0 06/2012=A0 =A0 Initial adoption of SCIM use = cases, as a living document=0A>=A0 06/2012=A0 =A0 Initial adoption of SCIM = core schema=0A>=A0 08/2012=A0 =A0 Initial adoption of SCIM restful interfac= e draft=0A>| 12/2012=A0 =A0 Snapshot version of SCIM use cases to IESG as= =0A>Informational (possibly)=0A>=A0 12/2012=A0 =A0 Proposal for client targ= eting of SCIM endpoints=0A>| 02/2013=A0 =A0 SCIM core schema to IESG as Pro= posed Standard=0A>| 05/2013=A0 =A0 SCIM restful interface to IESG as Propos= ed Standard=0A>=A0 07/2013=A0 =A0 Initial adoption of SCIM SAML bindings dr= aft=0A>=A0 07/2013=A0 =A0 Initial adoption of SCIM LDAP mapping draft=0A>| = 08/2013=A0 =A0 Client targeting of SCIM endpoints to IESG as Proposed=0A>St= andard=0A>| 09/2013=A0 =A0 Snapshot update of SCIM use cases as Information= al=0A>(possibly)=0A>| 11/2013=A0 =A0 SCIM SAML bindings to IESG as Proposed= Standard=0A>| 12/2013=A0 =A0 SCIM LDAP mapping to IESG as Proposed Standar= d=0A>=A0 01/2014=A0 =A0 Work completed; discuss re-charter=0A>=0A>Are those= correct?=A0 That is, everything is meant to be Proposed Standard except fo= r the use cases document (which might or might not get published)?=0A>=0A>M= A> I was thinking LDAP mapping would be informational as there are many=0A>= variations of identity schema in LDAP directories and this would only be an= instantiation of such mapping. However if others think this should be prop= osed standard, I am fine with it.=0A>=0A>2. There's concern about the "gaps= " text in this part:=0A>=0A>>=A0 In addition, the working group will ensure= that the SCIM protocol =0A>> embodies good security practices, and will do= cument gaps in its =0A>> capabilities and propose a path forward for addres= sing those gaps.=0A>=0A>What's that really meant to be saying?=A0 That is, = why shouldn't the sentence simply end after "good security practices"?=A0 W= e certainly can't produce documents that *don't* use good security practice= s, so if the rest of the sentence is important we have to separate it and m= ake it clear what we're getting at.=0A>=0A>MA> I think this is a side effec= t of tweaking the original paragraph=0A>over 9 revision and an unintentiona= l use of gap in the context of "security practices". I originally put the "= functional gap" in the charter as we are starting=A0 with a list of protoco= l/schema extensions some of the vendors were interested in, but we felt nee= d additional discussion and thinking so we left them out of 1.0 specs. The = goal of this original sentence was that the WG will review this list of gap= s and decide what to do with them. This had nothing to do with security.=0A= >Unfortunately between version 8 and 9, this was changed in addition to "fu= nctional gaps" we ended up with "gap" in the new paragraph covering securit= y.=A0 I am perfectly find removing it and making it more clear.=0A>=0A>3. T= here's concern by more than one AD that doing the schema definition without= having the LDAP mapping there with it will result in problems, and will en= d up with a new schema that ultimately has as many problems as the existing= one(s).=A0 The best suggestion to deal with that is to move the order arou= nd, do the LDAP mapping along with the schema, and send both documents to t= he IESG together.=0A>=0A>MA> I am fine with that change.=0A>=0A>4. The name= did come up (I told you...).=A0 It's not getting in the way, at least not = yet, but folks are balking at both the "simple" and the "cloud" parts.=A0 T= hey wonder if there isn't a way to keep "scim", but to make up something ne= w that it can stand for.=A0 Keep in mind that this is a minor point, though= -- the other three above need to be fixed.=0A>=0A>MA> Personally speaking,= I still think we should stick with SCIM. If the=0A>current traction of SCI= M v1 is any indication, by the time v2 is out there will be quite a few imp= lementations of it out there and we will have many implementations (we are = almost at 10 now). A rename between v1 and v2 will only result in confusion= and 10 years from now we will be using both SCIM and new name to refer to = it. It is not worth it especially if you consider other protocol names that= have "simple" in the name (including IETF protocols). If we *really* must = change something, let's stay with SCIM and change "cloud" which is the only= word there is no precedence for something else like "cross-domain"=0A>Step= hen suggested.=0A>=0A>=0A>Cheers,=0A>Morteza=0A>___________________________= ____________________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.i= etf.org/mailman/listinfo/scim=0A>=0A>=0A>__________________________________= _____________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org= /mailman/listinfo/scim=0A>=0A>=0A> ---125733401-2031769109-1337015145=:53055 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
On naming persistency, I'll add TLS and SSL...

From: Kelly Grizzle <kelly.gr= izzle@sailpoint.com>
To: Morteza Ansari (moransar) <moransar@cisco.com>; Barry Leiba <= ;barryleiba@computer.org>; "scim@ietf.org" <scim@ietf.org>
Sent: Monday, May 14, 2012 6= :35 AM
Subject: Re: [scim] Feedb= ack on the charter from IESG and IAB

=0A+1 on removi= ng the "gaps" text.

+1 on at least keeping the SCIM acronym.  T= o Peter's point, as an outsider I had heard of both Jabber and XMPP, but un= til recently had no idea that the two were the same.

--Kelly

= -----Original Message-----
From: scim-bounces@ietf.org [mailt= o:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)<= br>Sent: Monday, May 14, 2012 2:47 AM
To: Barry Leiba; scim@ietf.org
Subje= ct: Re: [scim] Feedback on the charter from IESG and IAB

Comments in= line:

-----Original Message-----
From: scim-bounces@ietf.o= rg [mailto:scim-bounces@ietf.org] On Behalf= Of Barry Leiba
Sent: Friday, May 11, 2012 6:56 AM
To: scim@ietf.org
Su= bject: [scim] Feedback on the charter from IESG and IAB

The first st= ep in chartering is to get feedback from the IESG and IAB, and I have the f= irst few comments.  For the record, the attached charter text is what'= s being commented on.

1. We should include intended document status = in the milestones.  To that end, I suggest this:

  06/2012=     Initial adoption of SCIM use cases, as a living document
&= nbsp; 06/2012    Initial adoption of SCIM core schema
  0= 8/2012    Initial adoption of SCIM restful interface draft
| 1= 2/2012    Snapshot version of SCIM use cases to IESG as
Inform= ational (possibly)
  12/2012    Proposal for client targeting of SCIM endpoints
| 02/2013    SCIM core schema to = IESG as Proposed Standard
| 05/2013    SCIM restful interface = to IESG as Proposed Standard
  07/2013    Initial adoptio= n of SCIM SAML bindings draft
  07/2013    Initial adopti= on of SCIM LDAP mapping draft
| 08/2013    Client targeting of= SCIM endpoints to IESG as Proposed
Standard
| 09/2013    S= napshot update of SCIM use cases as Informational
(possibly)
| 11/201= 3    SCIM SAML bindings to IESG as Proposed Standard
| 12/2013=     SCIM LDAP mapping to IESG as Proposed Standard
  01/2= 014    Work completed; discuss re-charter

Are those correc= t?  That is, everything is meant to be Proposed Standard except for th= e use cases document (which might or might not get published)?

MA>= ; I was thinking LDAP mapping would be informational as there are many
variations of identity schema in LDAP directories and this would o= nly be an instantiation of such mapping. However if others think this shoul= d be proposed standard, I am fine with it.

2. There's concern about = the "gaps" text in this part:

>  In addition, the working gr= oup will ensure that the SCIM protocol
> embodies good security prac= tices, and will document gaps in its
> capabilities and propose a pa= th forward for addressing those gaps.

What's that really meant to be= saying?  That is, why shouldn't the sentence simply end after "good s= ecurity practices"?  We certainly can't produce documents that *don't*= use good security practices, so if the rest of the sentence is important w= e have to separate it and make it clear what we're getting at.

MA>= ; I think this is a side effect of tweaking the original paragraph
over = 9 revision and an unintentional use of gap in the context of "security practices". I originally put the "functional gap" in the charter= as we are starting  with a list of protocol/schema extensions some of= the vendors were interested in, but we felt need additional discussion and= thinking so we left them out of 1.0 specs. The goal of this original sente= nce was that the WG will review this list of gaps and decide what to do wit= h them. This had nothing to do with security.
Unfortunately between vers= ion 8 and 9, this was changed in addition to "functional gaps" we ended up = with "gap" in the new paragraph covering security.  I am perfectly fin= d removing it and making it more clear.

3. There's concern by more t= han one AD that doing the schema definition without having the LDAP mapping= there with it will result in problems, and will end up with a new schema t= hat ultimately has as many problems as the existing one(s).  The best = suggestion to deal with that is to move the order around, do the LDAP mapping along with the schema, and send both documents to the IESG to= gether.

MA> I am fine with that change.

4. The name did co= me up (I told you...).  It's not getting in the way, at least not yet,= but folks are balking at both the "simple" and the "cloud" parts.  Th= ey wonder if there isn't a way to keep "scim", but to make up something new= that it can stand for.  Keep in mind that this is a minor point, thou= gh -- the other three above need to be fixed.

MA> Personally spea= king, I still think we should stick with SCIM. If the
current traction o= f SCIM v1 is any indication, by the time v2 is out there will be quite a fe= w implementations of it out there and we will have many implementations (we= are almost at 10 now). A rename between v1 and v2 will only result in conf= usion and 10 years from now we will be using both SCIM and new name to refe= r to it. It is not worth it especially if you consider other protocol names that have "simple" in the name (including IETF protocols). = If we *really* must change something, let's stay with SCIM and change "clou= d" which is the only word there is no precedence for something else like "c= ross-domain"
Stephen suggested.


Cheers,
Morteza
_______= ________________________________________
scim mailing list
scim@ietf.org= https://www.ietf.org/mailman/listinfo/scim


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


---125733401-2031769109-1337015145=:53055-- From barryleiba.mailing.lists@gmail.com Mon May 14 10:40:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF2F21F8921 for ; Mon, 14 May 2012 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQwtI-KjW0LP for ; Mon, 14 May 2012 10:40:26 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC6B21F8920 for ; Mon, 14 May 2012 10:40:25 -0700 (PDT) Received: by lagv3 with SMTP id v3so2561296lag.31 for ; Mon, 14 May 2012 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=einsRZt0cyC4uVlADsw22BPgaO/UzftrdUTLB1YryGQ=; b=f6zc/l8qkV9rqX96J2ljknhJdcRf83B4TVh69cTURVmbH1ayrE0U1X3+LkRI4Ilu+3 xjCGMaq+7b1RaCz1Oy4axuLYsP8AdqKMChIM6JpnaD1SBM8fYWh9pcs6f/UrmaG1w87G W+D6UBO5oU8pJPJDlUe/oWweYG8iP+ENfcPDL1Mt2O5W023pJ8dIsQx3QLSkRzTkGnPT tTMaVBQ+bfiXv4Uk2zMXn3GDGAV7H9aeLCpSFRYGJfGKa2wabcLYmTXVU3K7r6nETC+y I/K4UQ1AKcowLd6E8qs2XiiwLAI0eDdgwdn5YB4ADQqWsT8l/Nv013MqVV/VHbm5bWk9 mu+g== MIME-Version: 1.0 Received: by 10.152.46.232 with SMTP id y8mr9247401lam.18.1337017224445; Mon, 14 May 2012 10:40:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Mon, 14 May 2012 10:40:24 -0700 (PDT) In-Reply-To: <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Mon, 14 May 2012 13:40:24 -0400 X-Google-Sender-Auth: TrOptt0p4XT_zcgffb6cl55C3yM Message-ID: From: Barry Leiba To: William Mills Content-Type: text/plain; charset=ISO-8859-1 Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:40:26 -0000 On Mon, May 14, 2012 at 1:05 PM, William Mills wrote: > On naming persistency, I'll add TLS and SSL... Insufficient information to be useful. Are you mentioning this by way of support for NOT renaming, or as an example of why it doesn't matter. Some explanation would be helpful. Barry From stpeter@stpeter.im Mon May 14 10:55:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308AC11E8095 for ; Mon, 14 May 2012 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcQqdk1Y09tb for ; Mon, 14 May 2012 10:55:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC1011E808A for ; Mon, 14 May 2012 10:55:54 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D3DA40067; Mon, 14 May 2012 12:11:31 -0600 (MDT) Message-ID: <4FB14728.6090609@stpeter.im> Date: Mon, 14 May 2012 11:55:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Chris Phillips References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:55:55 -0000 On 5/14/12 8:25 AM, Chris Phillips wrote: > To the question about LDAP mappings: > > While there are a number of LDAP variations out there, many schemas > descend from inetOrgPerson and extend from there. This is the starting > point for the mappings. > Stumbling blocks have always been 'what to do with complex objects?' for > LDAP (and anything else actually). > The high fidelity SCIM schema is great for SCIM-to-SCIM endpoints to > preserve data exchange regardless of what your data model is, but it is > expected that the SCIM high fidelity schema will be transformed to a lower > fidelity one depending on the endpoint's capabilities(e.g. LDAP). > Recommending ways to do it will benefit adopters everywhere breeding > consistency of mappings, leveraging existing schemas in production, and > allow implementers to focus on their data, not how to get it from point A > to point B. If the SCIM WG (if formed) decides to pursue another approach to the schema representation, e.g. vCard4, then we might be able to work together with other folks on the LDAP mapping (I know that a mapping between LDAP and vCard4 was under consideration in the VCARDDAV WG). Peter -- Peter Saint-Andre https://stpeter.im/ From alan.sill@ttu.edu Mon May 14 11:02:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1C511E8098 for ; Mon, 14 May 2012 11:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw8064XjHEtZ for ; Mon, 14 May 2012 11:02:02 -0700 (PDT) Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by ietfa.amsl.com (Postfix) with ESMTP id DF5C611E8095 for ; Mon, 14 May 2012 11:02:01 -0700 (PDT) Received: from hippolytus.net.ttu.edu (129.118.1.212) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 13:02:00 -0500 Received: from [129.118.90.16] (129.118.90.16) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 May 2012 13:02:00 -0500 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: Alan Sill In-Reply-To: <4FB14728.6090609@stpeter.im> Date: Mon, 14 May 2012 13:01:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9340F189-A943-4B29-B0EB-95CA961F8A24@ttu.edu> References: <4FB14728.6090609@stpeter.im> To: X-Mailer: Apple Mail (2.1278) Received-SPF: Pass (eurymedon.net.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurymedon.net.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: Alan Sill Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:02:02 -0000 I can't resist an entry into the naming sweepstakes - as it is my = personal belief that the naming *should* stand for something substantial = and provide a summary for those looking to understand things further. SChemas for Identity Management Atrtibutes -- SCIMA (It even sounds right when pronounced!) Alan= From melinda.shore@gmail.com Mon May 14 11:12:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD57B21F885A for ; Mon, 14 May 2012 11:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx47vPrkLK1U for ; Mon, 14 May 2012 11:12:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2677C21F8859 for ; Mon, 14 May 2012 11:12:05 -0700 (PDT) Received: by dacx6 with SMTP id x6so6444382dac.31 for ; Mon, 14 May 2012 11:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=x2l7+b4mMNpQTL7jm1ldy1qUCWLql1WTvnMSyOE7KyI=; b=chj6htY3MzspwO6xtaagLTCfiU1waFd3NTzimTe/awgBWPRx7lRny/EiRlO+RERw6i i1A8STFWYwcWa2rD+PGY1+aH6SGqTLp5XRon20FcEM6mtCvMwbWGWsRka+hEYCgdPoN2 /ATe4WpbMGhb87zt592lWOCcl3LZxxz4JEujH3NN1Dc1kQoZYcJS9yCkUWini0KinkHA YM8NifMRkrZqHNTyAr1VMZY9IHTpqzy9whsOvbYYj2b2TRXucxCZpbECCuxlCXP0rh6d ZIYSStbwUQJUjsu7BCFMlSqUl6Ryamf0ypWHACfk77dkM7KoOiUWqW2mlkvgYw9r7K3t Pu4A== Received: by 10.68.237.166 with SMTP id vd6mr5353886pbc.139.1337019124936; Mon, 14 May 2012 11:12:04 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id ou5sm967608pbb.54.2012.05.14.11.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 11:12:04 -0700 (PDT) Message-ID: <4FB14AF2.7070503@gmail.com> Date: Mon, 14 May 2012 10:12:02 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <4FB0A3F5.70300@cisco.com> In-Reply-To: <4FB0A3F5.70300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:12:05 -0000 On 5/13/12 10:19 PM, Eliot Lear wrote: > +1. Let's just drop the text after practices. "In addition, the working group will ensure that the SCIM protocol embodies good security practices" struck me as awfully thin so I took a look at several other charters and it seems consistent with those, so this is probably good for the purpose of getting the charter approved. > +1, although I find the interoperability risk in this case low. Having been through an attempted SPML deployment I think the risk is potentially considerable. As I mentioned earlier I think an appendix with a proposed LDAP mapping is probably a good, useful thing, with the mapping not necessarily needing to be normative. Melinda From igor.faynberg@alcatel-lucent.com Mon May 14 11:20:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAC421F8889 for ; Mon, 14 May 2012 11:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.454 X-Spam-Level: X-Spam-Status: No, score=-9.454 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCA2zXOuiNsR for ; Mon, 14 May 2012 11:20:01 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id ED93721F8555 for ; Mon, 14 May 2012 11:20:00 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4EIJxW7009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 May 2012 13:19:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4EIJwgW015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 May 2012 13:19:59 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4EIJwtu003649; Mon, 14 May 2012 13:19:58 -0500 (CDT) Message-ID: <4FB14CCE.6060903@alcatel-lucent.com> Date: Mon, 14 May 2012 14:19:58 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <4FB0A3F5.70300@cisco.com> <4FB14AF2.7070503@gmail.com> In-Reply-To: <4FB14AF2.7070503@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:20:01 -0000 If the mapping is informative, how can it effect interoperability? (I am neither +1 nor -1 on this; I am just trying to understand.) Igor On 5/14/2012 2:12 PM, Melinda Shore wrote: > ... > >> +1, although I find the interoperability risk in this case low. > > Having been through an attempted SPML deployment I think the > risk is potentially considerable. As I mentioned earlier I > think an appendix with a proposed LDAP mapping is probably a > good, useful thing, with the mapping not necessarily needing to > be normative. > > Melinda > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Mon May 14 11:39:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A247C21F889F for ; Mon, 14 May 2012 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq-0iMOBjaWs for ; Mon, 14 May 2012 11:39:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41D21F85AF for ; Mon, 14 May 2012 11:39:42 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6669055pbc.31 for ; Mon, 14 May 2012 11:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rXc/eHhwx0hLSpfoEXRNowE+f4BVQfSeTSorEAPihVY=; b=RZ4cJaPwk3RwZzkrGWlDcG/rY7d743dGKTqz5JxPEHlUhfRrBtS6xD5A9mKvw1NwHH xLA+HMIoy1y1gxIG2zQwUnIpjGbtX4hTFGtSPGoYj3DCt25sC2oEL6R8MBJzt9YISMRs msbe5IMt7g74KQZ49v2ia3zQYzdlkeUo9IbkCDVk820NvpieS9wgxzWz7sHkvgprLbJx bTpHhhZ3fvtfHnITPoej35p/N6qYlRIuC4SM7zDYLLC0B6MAfspTF7s3TBzBp6DYs8yH Jm2FsiRjcUjG/TnB6hn/jRC17VUP1m/tNkAoIVdhVU3vhZ8bvORIVibXASaQOCum1tfp X7nQ== Received: by 10.68.132.34 with SMTP id or2mr25602513pbb.118.1337020778247; Mon, 14 May 2012 11:39:38 -0700 (PDT) Received: from polypro.local (66-230-101-239-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.239]) by mx.google.com with ESMTPS id rv5sm8338324pbc.56.2012.05.14.11.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 11:39:37 -0700 (PDT) Message-ID: <4FB15166.7090500@gmail.com> Date: Mon, 14 May 2012 10:39:34 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <4FB0A3F5.70300@cisco.com> <4FB14AF2.7070503@gmail.com> <4FB14CCE.6060903@alcatel-lucent.com> In-Reply-To: <4FB14CCE.6060903@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:39:44 -0000 On 5/14/12 10:19 AM, Igor Faynberg wrote: > If the mapping is informative, how can it effect interoperability? That's a fair question and I'm going to be candid, here: 1) getting informative text through is a lot easier than getting normative text through, and I think we need to allow for a fair amount of flexibility here, anyway 2) a complete mapping of inetOrgPerson will be difficult, for reasons discussed here previously 3) implementers, frankly, tend not to distinguish between normative and informational text, anyway. They generally implement what's recommended but I don't think we want to say that an implementation that doesn't strictly conform to the suggested mapping is broken. i.e. mostly for political reasons. Melinda From wmills@yahoo-inc.com Mon May 14 11:43:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC7421F88A7 for ; Mon, 14 May 2012 11:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.5 X-Spam-Level: X-Spam-Status: No, score=-16.5 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-k1+QN46yKG for ; Mon, 14 May 2012 11:43:37 -0700 (PDT) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with SMTP id 55F9921F88A3 for ; Mon, 14 May 2012 11:43:37 -0700 (PDT) Received: from [98.139.212.147] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 18:43:36 -0000 Received: from [98.139.212.218] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 18:43:36 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 14 May 2012 18:43:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 560617.21806.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 78748 invoked by uid 60001); 14 May 2012 18:43:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337021015; bh=Hmmlp9MnZNco8KF5Jyi9BVdrTyQMUmZyEj2Ul5dNTFE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Vw2B1RXNSbmnGv9PO9pABg2CZzTceXqqLHfGv2Bj87ZyTKBQj9XqjZApMO4ZKmm6aMwr7dfUOPj9vCCCRajjiS2cWrSwSlYiGxaL0Ups/pMfuGfhjAV2Ps2RVI4gp1Nn3klO+24r7uUw6gZXWxsBkxpOoOtczhYlcVSYf9I4s+E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=d0Kt4vxf3BRdTz1Ln3h222BvrA8bYTrGvmVe2wR+yq/0bJowuIdosvThaY58987mspaJw7zhcorN82aIDTPyRUwwsF2FqnMtzWIpV8CLvacEhvgZ8sZohxlQByJWv9Rh+3TZp2n+HSd6GU+dzcFCx9mQ3qecZctuzN5Vnq4vG+c=; X-YMail-OSG: qHOtOTkVM1nIbdk2lCZgBf9_.iMuu7MlQ4rQGo86snudrGr Y0wjnGr.Olxj_ytMcr0hqIKfB4_pRbKf_ZXqx9A9pEJgZKHF5l5hYP4BNoBq Ry89vJg8QEYA7vo5sA5CCULb4NTr8IVHwL3Bd9gDoCVu6iFF2vMpv_OrNfmz nA2AiWXbNVME0qoVKZhwHAlEdkqrz_BhhciGcFpYRrxtricUp6DiFsf0BxaU DXsiBDV0kMAvns0J.iXj3lDspmeyn5GSt0dKBJPlqTrQGpZpsy.owLpjQB_A KJ6.Fjw7BFWCTlr_F3jbFKHhkks2j12lDc0rDqcSzuTNtnhIMgoL.EIWjMtn YDNyWHnyZB5e8mgWJ_Wag0Jkrj5Qi1bBXgYc_35qeJVbuw2ncEZ1g.fGG40A nfxcMyASA4H_M0FO93PCKC0rW5U1K5w3bnNe1jLWgbNin83kHpPOE2fI- Received: from [209.131.62.120] by web31806.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 11:43:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> Message-ID: <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 14 May 2012 11:43:35 -0700 (PDT) From: William Mills To: Barry Leiba In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1026235247-1337021015=:75586" Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:43:38 -0000 ---1055047407-1026235247-1337021015=:75586 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ah, that the common usage for many is still "SSL", and that "TLS" will stil= l get you a "you mean SSL right?"=0A=0A=0A=0A=0A>__________________________= ______=0A> From: Barry Leiba =0A>To: William Mills= =0A>Cc: "scim@ietf.org" =0A>Sent: M= onday, May 14, 2012 10:40 AM=0A>Subject: Re: [scim] Feedback on the charter= from IESG and IAB=0A> =0A>On Mon, May 14, 2012 at 1:05 PM, William Mills <= wmills@yahoo-inc.com> wrote:=0A>> On naming persistency, I'll add TLS and S= SL...=0A>=0A>Insufficient information to be useful.=0A>=0A>Are you mentioni= ng this by way of support for NOT renaming, or as an=0A>example of why it d= oesn't matter.=A0 Some explanation would be helpful.=0A>=0A>Barry=0A>______= _________________________________________=0A>scim mailing list=0A>scim@ietf= .org=0A>https://www.ietf.org/mailman/listinfo/scim=0A>=0A>=0A> ---1055047407-1026235247-1337021015=:75586 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ah, that the common usage for many is still "SSL", and that "TLS" will st= ill get you a "you mean SSL right?"

From: Barry Leiba <barryleiba@computer= .org>
To: William M= ills <wmills@yahoo-inc.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Sent: Monday, May 14, 2012 10:40 AM
Subject: Re: [scim] Feedback on the char= ter from IESG and IAB

=0AOn Mon, May 14, 2012 at 1:0= 5 PM, William Mills <wmills@yahoo-inc.com> wrote:
> On= naming persistency, I'll add TLS and SSL...

Insufficient informatio= n to be useful.

Are you mentioning this by way of support for NOT re= naming, or as an
example of why it doesn't matter.  Some explanatio= n would be helpful.

Barry
_______________________________________= ________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/l= istinfo/scim


---1055047407-1026235247-1337021015=:75586-- From barryleiba@gmail.com Mon May 14 11:49:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE60D21F88B8 for ; Mon, 14 May 2012 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOlCCrz+QkIx for ; Mon, 14 May 2012 11:49:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5E321F88BB for ; Mon, 14 May 2012 11:49:54 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9483895obb.31 for ; Mon, 14 May 2012 11:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+7leA65X63oK4tktwu6nfV3uH0YAXVai22ctKKZIAQM=; b=bYvTE146Wz3dtTacQLu1TUzioqrBW0uR903TEOkHnbvUzdZ9seyYKbgFVXlBUXAoif kKL4DUEcduY7hbnbFWiFgjCJ5awNV6kcHJW+seBGRj18uM2gWjy08aYWBuUOJ80BbxOo WaXFFxV/vFaUzzrjJwmxsPn9nBKs6eVbYFa8Vy/9tEOt8jeBZuz8L/OzfdPB6WgdYkoZ 35n3eq+XKGaUVx4qomF6IgqWEV22o6y8k0Uw0eR6BujgQNzX/y/Pdk5MK9kqW7TsLoL9 vo1ZGnQx50TRu/ed2i1zzLUhDO9BRa/tGGi9jjG0qVraXvUNAqTAN737fmllbx3NXU7t B/jg== MIME-Version: 1.0 Received: by 10.182.38.1 with SMTP id c1mr13092363obk.18.1337021393866; Mon, 14 May 2012 11:49:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Mon, 14 May 2012 11:49:53 -0700 (PDT) In-Reply-To: <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 14 May 2012 14:49:53 -0400 X-Google-Sender-Auth: HfDZqkhuAwXvCw--GANZUyoUtFw Message-ID: From: Barry Leiba To: William Mills Content-Type: text/plain; charset=ISO-8859-1 Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:49:55 -0000 >>> On naming persistency, I'll add TLS and SSL... >> >> Are you mentioning this by way of support for NOT renaming, or as an >> example of why it doesn't matter. Some explanation would be helpful. > > Ah, that the common usage for many is still "SSL", and that "TLS" will still > get you a "you mean SSL right?" And does that mean that you think we should NOT rename "SCIM", are you just making a neutral comment, or something else? Barry From wmills@yahoo-inc.com Mon May 14 12:06:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD6B21F88BD for ; Mon, 14 May 2012 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.233 X-Spam-Level: X-Spam-Status: No, score=-17.233 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGmdJC7myi-p for ; Mon, 14 May 2012 12:06:18 -0700 (PDT) Received: from nm19.bullet.mail.bf1.yahoo.com (nm19.bullet.mail.bf1.yahoo.com [98.139.212.178]) by ietfa.amsl.com (Postfix) with SMTP id 5C10221F88BF for ; Mon, 14 May 2012 12:06:17 -0700 (PDT) Received: from [98.139.214.32] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 19:06:15 -0000 Received: from [98.139.215.254] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 19:06:15 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 14 May 2012 19:06:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 825888.73133.bm@omp1067.mail.bf1.yahoo.com Received: (qmail 26168 invoked by uid 60001); 14 May 2012 19:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337022375; bh=CEWkdnPzbukkRV6ha2NIhpKo2RoU//y9/PAIEDJhyg0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fXEx8G6OvrfpEaoMGnEYXeEVWmUC4A0+YNrPhzMj4iM2cOhCjfMb5OHUOHFCxC/VlEiXJ0erJaX6y2HcbST6m38dHp1VC09vHK9GQtuEYG65ud7j+B5t63h2vLz26sHdxVKGt+OzuPhogSnq3PzGE+9gwhNwvU6JD9Dcz2lngZw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mXRrmn37SoDUbq7HxBvr8HUYWfcsvZ/3/pZRKCJAwTHL4cyJaLPgKdpFoqEn6uMiWiDotORwbZxshV0P6FR8sjI7P565ycLcIBCHp/odXRVqujNbcmlngTe4ebHaCqqoRHkeXnt0rZ+lnfGGwDSPL1cq0Xd/Y5xLLQb7EzCSnhI=; X-YMail-OSG: ojcoVQUVM1nOK_ToJVvhzwh0IG14d_E9mC24owaiYX_9wfn kSPValpR7Wrwq7fn2vq7go9Oj2g2W_YyZFIPzZgkY9hpQTC3LJo08fTzSMxD nzu5iBlpuhmc4huinlcl.J3uOIiQpHcvn5jJrl2D_4pHEgA8lQNaRgDsf3EA ch6NIgQ.nC_mrSEh6k1.fX0CAf2Awd2rIGxxZC6aLasTT5Otn1sGH2y6O6ym dCthZcVhDVHwfLzQeZwPjLpoU2RNaNA8UsnxyJ6E9K.JDgdgdSBcE3jgAAXE 8ihS1yyZFywPlHHtqZO5wrYsIstR2gVC0bp51TVpemt289JLol77Uz3KgL.. PXo2WziqQN_KDV0sW5eTEKmi64EuVdL.YmiYqtwHTPnyKqZCg9aDXPPrTsS2 fEvpTRUVTOcFotv_7aUShDDyJJUVOSQOnLx5MixlezNFLO4eEXy.CQUk- Received: from [209.131.62.120] by web31804.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 12:06:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1337022375.22882.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 14 May 2012 12:06:15 -0700 (PDT) From: William Mills To: Barry Leiba In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-698896236-1337022375=:22882" Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:06:19 -0000 --835683298-698896236-1337022375=:22882 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am agreeing that name changes are hard.=A0 At this point I'd almost sugge= st pulling the "RFC" naming trick, SCIM can be a brand name that no longer = means what it used to.=A0 Trying to find a name that matches the acronym, w= hile amusing, is perhaps pointless.=A0 I'll take my go now though with "Syn= diCated Identity Management".=0A=0A=0A=0A=0A>______________________________= __=0A> From: Barry Leiba =0A>To: William Mills =0A>Cc: "scim@ietf.org" =0A>Sent: Monda= y, May 14, 2012 11:49 AM=0A>Subject: Re: [scim] Feedback on the charter fro= m IESG and IAB=0A> =0A>>>> On naming persistency, I'll add TLS and SSL...= =0A>>>=0A>>> Are you mentioning this by way of support for NOT renaming, or= as an=0A>>> example of why it doesn't matter.=A0 Some explanation would be= helpful.=0A>>=0A>> Ah, that the common usage for many is still "SSL", and = that "TLS" will still=0A>> get you a "you mean SSL right?"=0A>=0A>And does = that mean that you think we should NOT rename "SCIM", are you=0A>just makin= g a neutral comment, or something else?=0A>=0A>Barry=0A>=0A>=0A> --835683298-698896236-1337022375=:22882 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am agreeing that name changes are hard.  At this point I'd almost = suggest pulling the "RFC" naming trick, SCIM can be a brand name that no lo= nger means what it used to.  Trying to find a name that matches the ac= ronym, while amusing, is perhaps pointless.  I'll take my go now thoug= h with "SyndiCated Identity Management".

From: Barry Leiba <barryleiba@computer.org>
= To: William Mills <wmills@yahoo-inc.com>
Cc: "scim@ietf.org" <scim@ietf.org&g= t;
Sent: Monday, May = 14, 2012 11:49 AM
Subject:= Re: [scim] Feedback on the charter from IESG and IAB
=0A>>> On naming persistency, I'll add TLS and SSL...
>= ;>
>> Are you mentioning this by way of support for NOT renamin= g, or as an
>> example of why it doesn't matter.  Some explan= ation would be helpful.
>
> Ah, that the common usage for many = is still "SSL", and that "TLS" will still
> get you a "you mean SSL r= ight?"

And does that mean that you think we should NOT rename "SCIM"= , are you
just making a neutral comment, or something else?

Barry=


--835683298-698896236-1337022375=:22882-- From phil.hunt@oracle.com Mon May 14 13:20:17 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D721F8898 for ; Mon, 14 May 2012 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.327 X-Spam-Level: X-Spam-Status: No, score=-10.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umtt09tWD+Sq for ; Mon, 14 May 2012 13:20:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3421F8897 for ; Mon, 14 May 2012 13:20:16 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4EKKBox026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2012 20:20:12 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4EKKAaD008505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 20:20:11 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4EKKASS014459; Mon, 14 May 2012 15:20:10 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 May 2012 13:20:09 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB47178F-90D1-4D22-A964-50DB214373B6" From: Phil Hunt In-Reply-To: <1337022375.22882.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 14 May 2012 13:20:08 -0700 Message-Id: <825D4208-7A3A-44BC-BC9E-11CBF134F58C@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> <1337022375.22882.YahooMailNeo@web31804.mail.mud.yahoo.com> To: Barry Leiba X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:20:18 -0000 --Apple-Mail=_DB47178F-90D1-4D22-A964-50DB214373B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Please keep the SCIM name as it is. =20 I agree, XMPP/Jabber, TLS/SSL are all examples of serious confusion = caused by IETF renaming.=20 IMHO it is important to see the WG formed before the Vancouver meeting. = Let's focus on the other issues and get them resolved now. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-14, at 12:06 PM, William Mills wrote: > I am agreeing that name changes are hard. At this point I'd almost = suggest pulling the "RFC" naming trick, SCIM can be a brand name that no = longer means what it used to. Trying to find a name that matches the = acronym, while amusing, is perhaps pointless. I'll take my go now = though with "SyndiCated Identity Management". >=20 > From: Barry Leiba > To: William Mills =20 > Cc: "scim@ietf.org" =20 > Sent: Monday, May 14, 2012 11:49 AM > Subject: Re: [scim] Feedback on the charter from IESG and IAB >=20 > >>> On naming persistency, I'll add TLS and SSL... > >> > >> Are you mentioning this by way of support for NOT renaming, or as = an > >> example of why it doesn't matter. Some explanation would be = helpful. > > > > Ah, that the common usage for many is still "SSL", and that "TLS" = will still > > get you a "you mean SSL right?" >=20 > And does that mean that you think we should NOT rename "SCIM", are you > just making a neutral comment, or something else? >=20 > Barry >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_DB47178F-90D1-4D22-A964-50DB214373B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Phil

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





On 2012-05-14, at 12:06 PM, William Mills wrote:

I am = agreeing that name changes are hard.  At this point I'd almost = suggest pulling the "RFC" naming trick, SCIM can be a brand name that no = longer means what it used to.  Trying to find a name that matches = the acronym, while amusing, is perhaps pointless.  I'll take my go = now though with "SyndiCated Identity = Management".

=
From: = Barry Leiba <barryleiba@computer.org> To: William Mills = <wmills@yahoo-inc.com> =
Cc: "scim@ietf.org" <scim@ietf.org>
Sent: Monday, May 14, 2012 11:49 = AM
Subject: Re: = [scim] Feedback on the charter from IESG and IAB

>>> On naming persistency, I'll add TLS and = SSL...
>>
>> Are you mentioning this by way of support = for NOT renaming, or as an
>> example of why it doesn't = matter.  Some explanation would be helpful.
>
> Ah, = that the common usage for many is still "SSL", and that "TLS" will = still
> get you a "you mean SSL right?"

And does that mean = that you think we should NOT rename "SCIM", are you
just making a = neutral comment, or something else?

Barry


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

= --Apple-Mail=_DB47178F-90D1-4D22-A964-50DB214373B6-- From igor.faynberg@alcatel-lucent.com Mon May 14 13:34:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1D821F88A0 for ; Mon, 14 May 2012 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.568 X-Spam-Level: X-Spam-Status: No, score=-9.568 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGUm96SXtf6W for ; Mon, 14 May 2012 13:34:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDFD21F884E for ; Mon, 14 May 2012 13:34:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4EKYrLA001818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 May 2012 15:34:53 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4EKYqfX022227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 May 2012 15:34:53 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4EKYqNp016725; Mon, 14 May 2012 15:34:52 -0500 (CDT) Message-ID: <4FB16C6C.60701@alcatel-lucent.com> Date: Mon, 14 May 2012 16:34:52 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437220F0B14@BL2PRD0410MB351.namprd04.prod.outlook.com> <1337015145.53055.YahooMailNeo@web31807.mail.mud.yahoo.com> <1337021015.75586.YahooMailNeo@web31806.mail.mud.yahoo.com> <1337022375.22882.YahooMailNeo@web31804.mail.mud.yahoo.com> <825D4208-7A3A-44BC-BC9E-11CBF134F58C@oracle.com> In-Reply-To: <825D4208-7A3A-44BC-BC9E-11CBF134F58C@oracle.com> Content-Type: multipart/alternative; boundary="------------080500030102050508050405" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:34:55 -0000 This is a multi-part message in MIME format. --------------080500030102050508050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 on both proposals. Igor On 5/14/2012 4:20 PM, Phil Hunt wrote: > Please keep the SCIM name as it is. > > I agree, XMPP/Jabber, TLS/SSL are all examples of serious confusion > caused by IETF renaming. > > IMHO it is important to see the WG formed before the Vancouver > meeting. Let's focus on the other issues and get them resolved now. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-05-14, at 12:06 PM, William Mills wrote: > >> I am agreeing that name changes are hard. At this point I'd almost >> suggest pulling the "RFC" naming trick, SCIM can be a brand name that >> no longer means what it used to. Trying to find a name that matches >> the acronym, while amusing, is perhaps pointless. I'll take my go >> now though with "SyndiCated Identity Management". >> >> ------------------------------------------------------------------------ >> *From:* Barry Leiba > > >> *To:* William Mills > > >> *Cc:* "scim@ietf.org " > > >> *Sent:* Monday, May 14, 2012 11:49 AM >> *Subject:* Re: [scim] Feedback on the charter from IESG and IAB >> >> >>> On naming persistency, I'll add TLS and SSL... >> >> >> >> Are you mentioning this by way of support for NOT renaming, or >> as an >> >> example of why it doesn't matter. Some explanation would be >> helpful. >> > >> > Ah, that the common usage for many is still "SSL", and that >> "TLS" will still >> > get you a "you mean SSL right?" >> >> And does that mean that you think we should NOT rename "SCIM", >> are you >> just making a neutral comment, or something else? >> >> Barry >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------080500030102050508050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 on both proposals.

Igor

On 5/14/2012 4:20 PM, Phil Hunt wrote:
Please keep the SCIM name as it is.  

I agree, XMPP/Jabber, TLS/SSL are all examples of serious confusion caused by IETF renaming. 

IMHO it is important to see the WG formed before the Vancouver meeting. Let's focus on the other issues and get them resolved now.


On 2012-05-14, at 12:06 PM, William Mills wrote:

I am agreeing that name changes are hard.  At this point I'd almost suggest pulling the "RFC" naming trick, SCIM can be a brand name that no longer means what it used to.  Trying to find a name that matches the acronym, while amusing, is perhaps pointless.  I'll take my go now though with "SyndiCated Identity Management".

From: Barry Leiba <barryleiba@computer.org>
To: William Mills <wmills@yahoo-inc.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Sent: Monday, May 14, 2012 11:49 AM
Subject: Re: [scim] Feedback on the charter from IESG and IAB

>>> On naming persistency, I'll add TLS and SSL...
>>
>> Are you mentioning this by way of support for NOT renaming, or as an
>> example of why it doesn't matter.  Some explanation would be helpful.
>
> Ah, that the common usage for many is still "SSL", and that "TLS" will still
> get you a "you mean SSL right?"

And does that mean that you think we should NOT rename "SCIM", are you
just making a neutral comment, or something else?

Barry


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


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------080500030102050508050405-- From michael.brenner@alcatel-lucent.com Mon May 14 14:34:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09AF21F88B0 for ; Mon, 14 May 2012 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.204 X-Spam-Level: X-Spam-Status: No, score=-7.204 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGxCtptuAZ9G for ; Mon, 14 May 2012 14:34:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D382621F88AD for ; Mon, 14 May 2012 14:34:34 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4ELYYS0008505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 May 2012 16:34:34 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4ELYXxF026769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 May 2012 16:34:34 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 14 May 2012 16:34:34 -0500 From: "Brenner, Michael Ralf (Michael)" To: "Faynberg, Igor (Igor)" , "'scim@ietf.org'" Date: Mon, 14 May 2012 16:34:33 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0yEQfv5vuht51iQCaxY3kUdUSSKQACFKkh Message-ID: <219947F0B2242843A0A1E62FDB510DC0251184013C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <4FB16C6C.60701@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_219947F0B2242843A0A1E62FDB510DC0251184013CUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:34:37 -0000 --_000_219947F0B2242843A0A1E62FDB510DC0251184013CUSNAVSXCHMBSA_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIGxvb2tzIGxpa2Uga2VlcGluZyB0aGUgbmFtZSBjYW4gYmUganVzdGlmaWVkLg0KDQpGcm9t OiBJZ29yIEZheW5iZXJnIFttYWlsdG86aWdvci5mYXluYmVyZ0BhbGNhdGVsLWx1Y2VudC5jb21d DQpTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiAwMzozNCBQTQ0KVG86IHNjaW1AaWV0Zi5vcmcg PHNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBjaGFy dGVyIGZyb20gSUVTRyBhbmQgSUFCDQoNCisxIG9uIGJvdGggcHJvcG9zYWxzLg0KDQpJZ29yDQoN Ck9uIDUvMTQvMjAxMiA0OjIwIFBNLCBQaGlsIEh1bnQgd3JvdGU6DQpQbGVhc2Uga2VlcCB0aGUg U0NJTSBuYW1lIGFzIGl0IGlzLg0KDQpJIGFncmVlLCBYTVBQL0phYmJlciwgVExTL1NTTCBhcmUg YWxsIGV4YW1wbGVzIG9mIHNlcmlvdXMgY29uZnVzaW9uIGNhdXNlZCBieSBJRVRGIHJlbmFtaW5n Lg0KDQpJTUhPIGl0IGlzIGltcG9ydGFudCB0byBzZWUgdGhlIFdHIGZvcm1lZCBiZWZvcmUgdGhl IFZhbmNvdXZlciBtZWV0aW5nLiBMZXQncyBmb2N1cyBvbiB0aGUgb3RoZXIgaXNzdWVzIGFuZCBn ZXQgdGhlbSByZXNvbHZlZCBub3cuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIDIwMTIt MDUtMTQsIGF0IDEyOjA2IFBNLCBXaWxsaWFtIE1pbGxzIHdyb3RlOg0KDQpJIGFtIGFncmVlaW5n IHRoYXQgbmFtZSBjaGFuZ2VzIGFyZSBoYXJkLiAgQXQgdGhpcyBwb2ludCBJJ2QgYWxtb3N0IHN1 Z2dlc3QgcHVsbGluZyB0aGUgIlJGQyIgbmFtaW5nIHRyaWNrLCBTQ0lNIGNhbiBiZSBhIGJyYW5k IG5hbWUgdGhhdCBubyBsb25nZXIgbWVhbnMgd2hhdCBpdCB1c2VkIHRvLiAgVHJ5aW5nIHRvIGZp bmQgYSBuYW1lIHRoYXQgbWF0Y2hlcyB0aGUgYWNyb255bSwgd2hpbGUgYW11c2luZywgaXMgcGVy aGFwcyBwb2ludGxlc3MuICBJJ2xsIHRha2UgbXkgZ28gbm93IHRob3VnaCB3aXRoICJTeW5kaUNh dGVkIElkZW50aXR5IE1hbmFnZW1lbnQiLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4+DQpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzQHlhaG9v LWluYy5jb208bWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tPj4NCkNjOiAic2NpbUBpZXRmLm9y ZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4iIDxzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPj4NClNlbnQ6IE1vbmRheSwgTWF5IDE0LCAyMDEyIDExOjQ5IEFNDQpTdWJqZWN0OiBSZTog W3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBjaGFydGVyIGZyb20gSUVTRyBhbmQgSUFCDQoNCj4+PiBP biBuYW1pbmcgcGVyc2lzdGVuY3ksIEknbGwgYWRkIFRMUyBhbmQgU1NMLi4uDQo+Pg0KPj4gQXJl IHlvdSBtZW50aW9uaW5nIHRoaXMgYnkgd2F5IG9mIHN1cHBvcnQgZm9yIE5PVCByZW5hbWluZywg b3IgYXMgYW4NCj4+IGV4YW1wbGUgb2Ygd2h5IGl0IGRvZXNuJ3QgbWF0dGVyLiAgU29tZSBleHBs YW5hdGlvbiB3b3VsZCBiZSBoZWxwZnVsLg0KPg0KPiBBaCwgdGhhdCB0aGUgY29tbW9uIHVzYWdl IGZvciBtYW55IGlzIHN0aWxsICJTU0wiLCBhbmQgdGhhdCAiVExTIiB3aWxsIHN0aWxsDQo+IGdl dCB5b3UgYSAieW91IG1lYW4gU1NMIHJpZ2h0PyINCg0KQW5kIGRvZXMgdGhhdCBtZWFuIHRoYXQg eW91IHRoaW5rIHdlIHNob3VsZCBOT1QgcmVuYW1lICJTQ0lNIiwgYXJlIHlvdQ0KanVzdCBtYWtp bmcgYSBuZXV0cmFsIGNvbW1lbnQsIG9yIHNvbWV0aGluZyBlbHNlPw0KDQpCYXJyeQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxp bmcgbGlzdA0Kc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2Np bUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2NpbQ0KDQo= --_000_219947F0B2242843A0A1E62FDB510DC0251184013CUSNAVSXCHMBSA_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCiAgPGhlYWQ+DQogICAgPG1ldGEgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PUlTTy04ODU5LTEiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNmZmZmZmYiPjxmb250IHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCisxLCBsb29rcyBsaWtlIGtlZXBp bmcgdGhlIG5hbWUgY2FuIGJlIGp1c3RpZmllZC48L2ZvbnQ+PGJyPiZuYnNwOzxicj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxiPkZy b208L2I+OiBJZ29yIEZheW5iZXJnIFttYWlsdG86aWdvci5mYXluYmVyZ0BhbGNhdGVsLWx1Y2Vu dC5jb21dDTxicj48Yj5TZW50PC9iPjogTW9uZGF5LCBNYXkgMTQsIDIwMTIgMDM6MzQgUE08YnI+ PGI+VG88L2I+OiBzY2ltQGlldGYub3JnICZsdDtzY2ltQGlldGYub3JnJmd0Ow08YnI+PGI+U3Vi amVjdDwvYj46IFJlOiBbc2NpbV0gRmVlZGJhY2sgb24gdGhlIGNoYXJ0ZXIgZnJvbSBJRVNHIGFu ZCBJQUINPGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+DQoNCiAgICArMSBvbiBib3RoIHByb3Bv c2Fscy48YnI+DQogICAgPGJyPg0KICAgIElnb3I8YnI+DQogICAgPGJyPg0KICAgIE9uIDUvMTQv MjAxMiA0OjIwIFBNLCBQaGlsIEh1bnQgd3JvdGU6DQogICAgPGJsb2NrcXVvdGUNCiAgICAgIGNp dGU9Im1pZDo4MjVENDIwOC03QTNBLTQ0QkMtQkM5RS0xMUNCRjEzNEY1OENAb3JhY2xlLmNvbSIN CiAgICAgIHR5cGU9ImNpdGUiPlBsZWFzZSBrZWVwIHRoZSBTQ0lNIG5hbWUgYXMgaXQgaXMuICZu YnNwOw0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXY+DQogICAgICAg IDxkaXY+SSBhZ3JlZSwgWE1QUC9KYWJiZXIsIFRMUy9TU0wgYXJlIGFsbCBleGFtcGxlcyBvZiBz ZXJpb3VzDQogICAgICAgICAgY29uZnVzaW9uIGNhdXNlZCBieSBJRVRGIHJlbmFtaW5nLiZuYnNw OzwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+ SU1ITyBpdCBpcyBpbXBvcnRhbnQgdG8gc2VlIHRoZSBXRyBmb3JtZWQgYmVmb3JlIHRoZQ0KICAg ICAgICAgIFZhbmNvdXZlciBtZWV0aW5nLiBMZXQncyBmb2N1cyBvbiB0aGUgb3RoZXIgaXNzdWVz IGFuZCBnZXQNCiAgICAgICAgICB0aGVtIHJlc29sdmVkIG5vdy48L2Rpdj4NCiAgICAgICAgPGRp dj48YnI+DQogICAgICAgICAgPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSI+DQogICAg ICAgICAgICA8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xs YXBzZToNCiAgICAgICAgICAgICAgc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7DQogICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0Og0KICAgICAgICAgICAgICBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAg IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAg ICAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzog MHB4Ow0KICAgICAgICAgICAgICBmb250LXNpemU6IG1lZGl1bTsiPjxzcGFuIGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIg0KICAgICAgICAgICAgICAgIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyBmb250LXN0eWxlOg0KICAgICAgICAgICAg ICAgIG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQog ICAgICAgICAgICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogMjsNCiAgICAgICAgICAgICAgICB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6DQogICAgICAgICAgICAgICAgbm9ybWFsOyB3aWRv d3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyI+DQogICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6DQogICAgICAgICAgICAg ICAgICAgIHNlcGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseToNCiAgICAg ICAgICAgICAgICAgICAgSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsgZm9udC1zdHlsZTog bm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgb3JwaGFuczogMjsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICAgICAgICAgICAg ICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7Ij4N CiAgICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyI+ PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz dHlsZT0iYm9yZGVyLWNvbGxhcHNlOg0KICAgICAgICAgICAgICAgICAgICAgICAgc2VwYXJhdGU7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAg ICAgSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAg ICAgICAgICAgICAgICAgICAgIGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgIG9ycGhhbnM6IDI7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOg0KICAgICAgICAgICAgICAgICAgICAgICAg bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0KICAgICAgICAgICAgICAgICAg ICAgICAgd29yZC1zcGFjaW5nOiAwcHg7Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsiPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2PlBoaWw8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PkBpbmRlcGVuZGVudGlkPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwOi8vd3d3Lmlu ZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9kaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgPC9zcGFuPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAg ICAgIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L3NwYW4+PGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg PC9zcGFuPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQogICAgICAgICAg ICA8L3NwYW4+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCiAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxk aXY+T24gMjAxMi0wNS0xNCwgYXQgMTI6MDYgUE0sIFdpbGxpYW0gTWlsbHMgd3JvdGU6PC9kaXY+ DQogICAgICAgICAgICA8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KICAg ICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgIDxkaXY+DQog ICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjoNCiAgICAgICAgICAgICAgICAgIHJnYigyNTUsIDI1NSwgMjU1KTsgZm9udC1mYW1p bHk6IENvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyxjb3VyaWVyLG1vbmFjbyxtb25vc3Bh Y2Usc2Fucy1zZXJpZjsgZm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAgMTRwdDsiPg0KICAg ICAgICAgICAgICAgICAgPGRpdj48c3Bhbj5JIGFtIGFncmVlaW5nIHRoYXQgbmFtZSBjaGFuZ2Vz IGFyZSBoYXJkLiZuYnNwOw0KICAgICAgICAgICAgICAgICAgICAgIEF0IHRoaXMgcG9pbnQgSSdk IGFsbW9zdCBzdWdnZXN0IHB1bGxpbmcgdGhlICJSRkMiDQogICAgICAgICAgICAgICAgICAgICAg bmFtaW5nIHRyaWNrLCBTQ0lNIGNhbiBiZSBhIGJyYW5kIG5hbWUgdGhhdCBubw0KICAgICAgICAg ICAgICAgICAgICAgIGxvbmdlciBtZWFucyB3aGF0IGl0IHVzZWQgdG8uJm5ic3A7IFRyeWluZyB0 byBmaW5kIGENCiAgICAgICAgICAgICAgICAgICAgICBuYW1lIHRoYXQgbWF0Y2hlcyB0aGUgYWNy b255bSwgd2hpbGUgYW11c2luZywgaXMNCiAgICAgICAgICAgICAgICAgICAgICBwZXJoYXBzIHBv aW50bGVzcy4mbmJzcDsgSSdsbCB0YWtlIG15IGdvIG5vdyB0aG91Z2gNCiAgICAgICAgICAgICAg ICAgICAgICB3aXRoICJTeW5kaUNhdGVkIElkZW50aXR5IE1hbmFnZW1lbnQiLjxicj4NCiAgICAg ICAgICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4 IHNvbGlkIHJnYigxNiwNCiAgICAgICAgICAgICAgICAgICAgICAxNiwgMjU1KTsgbWFyZ2luLWxl ZnQ6IDVweDsgbWFyZ2luLXRvcDogNXB4Ow0KICAgICAgICAgICAgICAgICAgICAgIHBhZGRpbmct bGVmdDogNXB4OyI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldyxjb3VyaWVyLG1vbmFjbyxt b25vc3BhY2Usc2Fucy1zZXJpZjsNCiAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTog MTRwdDsiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IHRpbWVzIG5ldyByb21hbixuZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgeW9yayx0aW1l cyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXYgZGlyPSJsdHIiPiA8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8aHIgc2l6ZT0iMSI+IDxiPjxzcGFuDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+RnJvbTo8L3NwYW4+ PC9iPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFycnkgTGVpYmEgJmx0OzxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9y ZzwvYT4mZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+VG86PC9zcGFuPjwvYj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdpbGxpYW0gTWlsbHMgJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaHJlZj0ibWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tIj53bWlsbHNAeWFob28t aW5jLmNvbTwvYT4mZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJv bGQ7Ij5DYzo8L3NwYW4+PC9iPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIjxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+Ig0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1A aWV0Zi5vcmc8L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBi b2xkOyI+U2VudDo8L3NwYW4+PC9iPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9u ZGF5LCBNYXkgMTQsIDIwMTIgMTE6NDkgQU08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5TdWJqZWN0Ojwvc3Bhbj48 L2I+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZTogW3NjaW1dIEZlZWRiYWNrIG9u IHRoZSBjaGFydGVyIGZyb20NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElFU0cgYW5k IElBQjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2ZvbnQ+IDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsmZ3Q7Jmd0OyBPbiBuYW1pbmcgcGVyc2lzdGVuY3ksIEknbGwgYWRkDQogICAgICAgICAgICAg ICAgICAgICAgICAgIFRMUyBhbmQgU1NMLi4uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgQXJlIHlv dSBtZW50aW9uaW5nIHRoaXMgYnkgd2F5IG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN1 cHBvcnQgZm9yIE5PVCByZW5hbWluZywgb3IgYXMgYW48YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7IGV4YW1wbGUgb2Ygd2h5IGl0IGRvZXNuJ3QgbWF0dGVyLiZuYnNwOw0K ICAgICAgICAgICAgICAgICAgICAgICAgICBTb21lIGV4cGxhbmF0aW9uIHdvdWxkIGJlIGhlbHBm dWwuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7IEFoLCB0aGF0IHRoZSBjb21tb24gdXNhZ2UgZm9yIG1hbnkgaXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgc3RpbGwgIlNTTCIsIGFuZCB0aGF0ICJUTFMiIHdp bGwgc3RpbGw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgZ2V0IHlvdSBhICJ5 b3UgbWVhbiBTU0wgcmlnaHQ/Ijxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICBBbmQgZG9lcyB0aGF0IG1lYW4gdGhhdCB5b3UgdGhp bmsgd2Ugc2hvdWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgIE5PVCByZW5hbWUgIlNDSU0i LCBhcmUgeW91PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBqdXN0IG1ha2luZyBhIG5l dXRyYWwgY29tbWVudCwgb3Igc29tZXRoaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIGVs c2U/PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgIEJhcnJ5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Js b2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KICAgICAgICAgICAgICBzY2ltIG1h aWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBo cmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQogICAgICAg ICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zY2ltPC9hPjxicj4NCiAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9k aXY+DQogICAgICA8cHJlIHdyYXA9IiI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50 SGVhZGVyIj48L2ZpZWxkc2V0Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi YnJldmlhdGVkIiBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4N CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zY2ltPC9hPg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0KICA8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_219947F0B2242843A0A1E62FDB510DC0251184013CUSNAVSXCHMBSA_-- From moransar@cisco.com Mon May 14 15:08:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68B21F88D4 for ; Mon, 14 May 2012 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsd2BnUjizU8 for ; Mon, 14 May 2012 15:08:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E793521F88C1 for ; Mon, 14 May 2012 15:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=6801; q=dns/txt; s=iport; t=1337033334; x=1338242934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DzDgCg1hjq+l4DPlEKm+F1yAFk8+/1yOhL9aRhic5Ok=; b=jdHtti1XT4A8h9Ud2SSFZy22xToAy22EPhBIVTWVL1yQXI5pwsUQpBmJ VbMj9GgWpGEI+dXbK1inu/2MsCSDB5vDGUqczu5F7zoQN5Y2ob+B/M+XA +sgHJSHnW6MN5cKle1Vbbm6upwGSstqNWI1+IZunc983ggUKHAmIl7Oo1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD+BsU+tJXG//2dsb2JhbAA7CbN0gQeCFQEBAQMBAQEBDwEdCg8lCwUHBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQTCBqHZwULmnWff4saEAOFCmMEiGSbcIFpgweBOA X-IronPort-AV: E=Sophos;i="4.75,589,1330905600"; d="scan'208";a="83178173" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 14 May 2012 22:08:53 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EM8jrk006313; Mon, 14 May 2012 22:08:52 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 17:08:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 17:08:46 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0x1gsLObQMg1vUSAuryRl3UupzXgARxl0w References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> From: "Morteza Ansari (moransar)" To: "Phil Hunt" X-OriginalArrivalTime: 14 May 2012 22:08:47.0322 (UTC) FILETIME=[2285E3A0:01CD321E] Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 22:08:55 -0000 Given this is new work it is hard to define what the mapping document will contain. However, my thinking was that it describes how one would map between inetOrgPerson and SCIM schema. Given this mapping is provided more for informational purposes and also the fact RFC 2798 itself is an informational RFC, I had assumed the mapping document will be informational. Does anyone think otherwise and this should be a proposed standard? Cheers, Morteza -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Monday, May 14, 2012 6:33 AM To: Morteza Ansari (moransar) Cc: Barry Leiba; scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB Unfortunately, no draft proposal for the LDAP Mapping has been submitted to IETF for consideration. So it is not clear to me what the objective of an LDAP mapping draft is -- though I can guess based on the name. As Morteza points out, many LDAP variations are possible and I agree, very likely given the suggested architecture in the SCIM scenarios.=20 Is the LDAP mapping draft limited to specifying how complex attributes are handled? Or does it cover more? What is the interop issue being solved? I'm not saying I'm against it, but I can't comment without seeing more about it. The same is true for the SAML binding (no draft). Though I can guess more clearly the scope of such a binding. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-14, at 12:47 AM, Morteza Ansari (moransar) wrote: > Comments inline: >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 > Of Barry Leiba > Sent: Friday, May 11, 2012 6:56 AM > To: scim@ietf.org > Subject: [scim] Feedback on the charter from IESG and IAB >=20 > The first step in chartering is to get feedback from the IESG and IAB, > and I have the first few comments. For the record, the attached=20 > charter text is what's being commented on. >=20 > 1. We should include intended document status in the milestones. To=20 > that end, I suggest this: >=20 > 06/2012 Initial adoption of SCIM use cases, as a living document > 06/2012 Initial adoption of SCIM core schema > 08/2012 Initial adoption of SCIM restful interface draft > | 12/2012 Snapshot version of SCIM use cases to IESG as > Informational (possibly) > 12/2012 Proposal for client targeting of SCIM endpoints > | 02/2013 SCIM core schema to IESG as Proposed Standard > | 05/2013 SCIM restful interface to IESG as Proposed Standard > 07/2013 Initial adoption of SCIM SAML bindings draft > 07/2013 Initial adoption of SCIM LDAP mapping draft > | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed > Standard > | 09/2013 Snapshot update of SCIM use cases as Informational > (possibly) > | 11/2013 SCIM SAML bindings to IESG as Proposed Standard > | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard > 01/2014 Work completed; discuss re-charter >=20 > Are those correct? That is, everything is meant to be Proposed=20 > Standard except for the use cases document (which might or might not=20 > get published)? >=20 > MA> I was thinking LDAP mapping would be informational as there are=20 > MA> many > variations of identity schema in LDAP directories and this would only=20 > be an instantiation of such mapping. However if others think this=20 > should be proposed standard, I am fine with it. >=20 > 2. There's concern about the "gaps" text in this part: >=20 >> In addition, the working group will ensure that the SCIM protocol=20 >> embodies good security practices, and will document gaps in its=20 >> capabilities and propose a path forward for addressing those gaps. >=20 > What's that really meant to be saying? That is, why shouldn't the=20 > sentence simply end after "good security practices"? We certainly=20 > can't produce documents that *don't* use good security practices, so=20 > if the rest of the sentence is important we have to separate it and=20 > make it clear what we're getting at. >=20 > MA> I think this is a side effect of tweaking the original paragraph > over 9 revision and an unintentional use of gap in the context of=20 > "security practices". I originally put the "functional gap" in the=20 > charter as we are starting with a list of protocol/schema extensions=20 > some of the vendors were interested in, but we felt need additional=20 > discussion and thinking so we left them out of 1.0 specs. The goal of=20 > this original sentence was that the WG will review this list of gaps=20 > and decide what to do with them. This had nothing to do with security. > Unfortunately between version 8 and 9, this was changed in addition to > "functional gaps" we ended up with "gap" in the new paragraph covering > security. I am perfectly find removing it and making it more clear. >=20 > 3. There's concern by more than one AD that doing the schema=20 > definition without having the LDAP mapping there with it will result=20 > in problems, and will end up with a new schema that ultimately has as=20 > many problems as the existing one(s). The best suggestion to deal=20 > with that is to move the order around, do the LDAP mapping along with=20 > the schema, and send both documents to the IESG together. >=20 > MA> I am fine with that change. >=20 > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the=20 > "cloud" parts. They wonder if there isn't a way to keep "scim", but=20 > to make up something new that it can stand for. Keep in mind that=20 > this is a minor point, though -- the other three above need to be fixed. >=20 > MA> Personally speaking, I still think we should stick with SCIM. If=20 > MA> the > current traction of SCIM v1 is any indication, by the time v2 is out=20 > there will be quite a few implementations of it out there and we will=20 > have many implementations (we are almost at 10 now). A rename between=20 > v1 and v2 will only result in confusion and 10 years from now we will=20 > be using both SCIM and new name to refer to it. It is not worth it=20 > especially if you consider other protocol names that have "simple" in=20 > the name (including IETF protocols). If we *really* must change=20 > something, let's stay with SCIM and change "cloud" which is the only=20 > word there is no precedence for something else like "cross-domain" > Stephen suggested. >=20 >=20 > Cheers, > Morteza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Mon May 14 16:28:24 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7421F8927 for ; Mon, 14 May 2012 16:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+N0y28IRRKN for ; Mon, 14 May 2012 16:28:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id B1F0621F885E for ; Mon, 14 May 2012 16:28:23 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4ENSLLs009173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 May 2012 23:28:22 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4ENSKwR021932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 23:28:21 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4ENSKjx015720; Mon, 14 May 2012 18:28:20 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 May 2012 16:28:20 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> Date: Mon, 14 May 2012 16:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51D8B286-F549-4CB3-BDB3-D70976EF9ECC@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> To: "Morteza Ansari (moransar)" X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 23:28:24 -0000 I think it is worth having the SCIM LDAP Mapping proposal submitted as a = draft so it can be discussed more broadly in the IETF. You may be right - it only needs to be informational from a the proposed = SCIM WG charter perspective. However, it might be that another WG should = take the proposal on -- especially the issue of evolving LDAP to support = complex attributes. In the LDAP perspective, inter-operability becomes a = potential issue. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-14, at 3:08 PM, Morteza Ansari (moransar) wrote: > Given this is new work it is hard to define what the mapping document > will contain. However, my thinking was that it describes how one = would > map between inetOrgPerson and SCIM schema. >=20 > Given this mapping is provided more for informational purposes and = also > the fact RFC 2798 itself is an informational RFC, I had assumed the > mapping document will be informational. Does anyone think otherwise = and > this should be a proposed standard? >=20 >=20 > Cheers, > Morteza >=20 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, May 14, 2012 6:33 AM > To: Morteza Ansari (moransar) > Cc: Barry Leiba; scim@ietf.org > Subject: Re: [scim] Feedback on the charter from IESG and IAB >=20 > Unfortunately, no draft proposal for the LDAP Mapping has been = submitted > to IETF for consideration. So it is not clear to me what the = objective > of an LDAP mapping draft is -- though I can guess based on the name. >=20 > As Morteza points out, many LDAP variations are possible and I agree, > very likely given the suggested architecture in the SCIM scenarios.=20 >=20 > Is the LDAP mapping draft limited to specifying how complex attributes > are handled? Or does it cover more? What is the interop issue being > solved? >=20 > I'm not saying I'm against it, but I can't comment without seeing more > about it. >=20 > The same is true for the SAML binding (no draft). Though I can guess > more clearly the scope of such a binding. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-05-14, at 12:47 AM, Morteza Ansari (moransar) wrote: >=20 >> Comments inline: >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20= >> Of Barry Leiba >> Sent: Friday, May 11, 2012 6:56 AM >> To: scim@ietf.org >> Subject: [scim] Feedback on the charter from IESG and IAB >>=20 >> The first step in chartering is to get feedback from the IESG and = IAB, >=20 >> and I have the first few comments. For the record, the attached=20 >> charter text is what's being commented on. >>=20 >> 1. We should include intended document status in the milestones. To=20= >> that end, I suggest this: >>=20 >> 06/2012 Initial adoption of SCIM use cases, as a living document >> 06/2012 Initial adoption of SCIM core schema >> 08/2012 Initial adoption of SCIM restful interface draft >> | 12/2012 Snapshot version of SCIM use cases to IESG as >> Informational (possibly) >> 12/2012 Proposal for client targeting of SCIM endpoints >> | 02/2013 SCIM core schema to IESG as Proposed Standard >> | 05/2013 SCIM restful interface to IESG as Proposed Standard >> 07/2013 Initial adoption of SCIM SAML bindings draft >> 07/2013 Initial adoption of SCIM LDAP mapping draft >> | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >> Standard >> | 09/2013 Snapshot update of SCIM use cases as Informational >> (possibly) >> | 11/2013 SCIM SAML bindings to IESG as Proposed Standard >> | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard >> 01/2014 Work completed; discuss re-charter >>=20 >> Are those correct? That is, everything is meant to be Proposed=20 >> Standard except for the use cases document (which might or might not=20= >> get published)? >>=20 >> MA> I was thinking LDAP mapping would be informational as there are=20= >> MA> many >> variations of identity schema in LDAP directories and this would only=20= >> be an instantiation of such mapping. However if others think this=20 >> should be proposed standard, I am fine with it. >>=20 >> 2. There's concern about the "gaps" text in this part: >>=20 >>> In addition, the working group will ensure that the SCIM protocol=20 >>> embodies good security practices, and will document gaps in its=20 >>> capabilities and propose a path forward for addressing those gaps. >>=20 >> What's that really meant to be saying? That is, why shouldn't the=20 >> sentence simply end after "good security practices"? We certainly=20 >> can't produce documents that *don't* use good security practices, so=20= >> if the rest of the sentence is important we have to separate it and=20= >> make it clear what we're getting at. >>=20 >> MA> I think this is a side effect of tweaking the original paragraph >> over 9 revision and an unintentional use of gap in the context of=20 >> "security practices". I originally put the "functional gap" in the=20 >> charter as we are starting with a list of protocol/schema extensions=20= >> some of the vendors were interested in, but we felt need additional=20= >> discussion and thinking so we left them out of 1.0 specs. The goal of=20= >> this original sentence was that the WG will review this list of gaps=20= >> and decide what to do with them. This had nothing to do with = security. >> Unfortunately between version 8 and 9, this was changed in addition = to >=20 >> "functional gaps" we ended up with "gap" in the new paragraph = covering >=20 >> security. I am perfectly find removing it and making it more clear. >>=20 >> 3. There's concern by more than one AD that doing the schema=20 >> definition without having the LDAP mapping there with it will result=20= >> in problems, and will end up with a new schema that ultimately has as=20= >> many problems as the existing one(s). The best suggestion to deal=20 >> with that is to move the order around, do the LDAP mapping along with=20= >> the schema, and send both documents to the IESG together. >>=20 >> MA> I am fine with that change. >>=20 >> 4. The name did come up (I told you...). It's not getting in the = way, >=20 >> at least not yet, but folks are balking at both the "simple" and the=20= >> "cloud" parts. They wonder if there isn't a way to keep "scim", but=20= >> to make up something new that it can stand for. Keep in mind that=20 >> this is a minor point, though -- the other three above need to be > fixed. >>=20 >> MA> Personally speaking, I still think we should stick with SCIM. If=20= >> MA> the >> current traction of SCIM v1 is any indication, by the time v2 is out=20= >> there will be quite a few implementations of it out there and we will=20= >> have many implementations (we are almost at 10 now). A rename between=20= >> v1 and v2 will only result in confusion and 10 years from now we will=20= >> be using both SCIM and new name to refer to it. It is not worth it=20 >> especially if you consider other protocol names that have "simple" in=20= >> the name (including IETF protocols). If we *really* must change=20 >> something, let's stay with SCIM and change "cloud" which is the only=20= >> word there is no precedence for something else like "cross-domain" >> Stephen suggested. >>=20 >>=20 >> Cheers, >> Morteza >> _______________________________________________ >> 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 stpeter@stpeter.im Mon May 14 18:10:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B6121F8938 for ; Mon, 14 May 2012 18:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IozkK-QpIMBj for ; Mon, 14 May 2012 18:10:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F13A121F863E for ; Mon, 14 May 2012 18:10:19 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8181D40067; Mon, 14 May 2012 19:25:57 -0600 (MDT) Message-ID: <4FB1ACFA.1080107@stpeter.im> Date: Mon, 14 May 2012 19:10:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Morteza Ansari (moransar)" References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Barry Leiba , Phil Hunt Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 01:10:21 -0000 It seems informational to me. On 5/14/12 4:08 PM, Morteza Ansari (moransar) wrote: > Given this is new work it is hard to define what the mapping document > will contain. However, my thinking was that it describes how one would > map between inetOrgPerson and SCIM schema. > > Given this mapping is provided more for informational purposes and also > the fact RFC 2798 itself is an informational RFC, I had assumed the > mapping document will be informational. Does anyone think otherwise and > this should be a proposed standard? > > > Cheers, > Morteza > > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Monday, May 14, 2012 6:33 AM > To: Morteza Ansari (moransar) > Cc: Barry Leiba; scim@ietf.org > Subject: Re: [scim] Feedback on the charter from IESG and IAB > > Unfortunately, no draft proposal for the LDAP Mapping has been submitted > to IETF for consideration. So it is not clear to me what the objective > of an LDAP mapping draft is -- though I can guess based on the name. > > As Morteza points out, many LDAP variations are possible and I agree, > very likely given the suggested architecture in the SCIM scenarios. > > Is the LDAP mapping draft limited to specifying how complex attributes > are handled? Or does it cover more? What is the interop issue being > solved? > > I'm not saying I'm against it, but I can't comment without seeing more > about it. > > The same is true for the SAML binding (no draft). Though I can guess > more clearly the scope of such a binding. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-05-14, at 12:47 AM, Morteza Ansari (moransar) wrote: > >> Comments inline: >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf >> Of Barry Leiba >> Sent: Friday, May 11, 2012 6:56 AM >> To: scim@ietf.org >> Subject: [scim] Feedback on the charter from IESG and IAB >> >> The first step in chartering is to get feedback from the IESG and IAB, > >> and I have the first few comments. For the record, the attached >> charter text is what's being commented on. >> >> 1. We should include intended document status in the milestones. To >> that end, I suggest this: >> >> 06/2012 Initial adoption of SCIM use cases, as a living document >> 06/2012 Initial adoption of SCIM core schema >> 08/2012 Initial adoption of SCIM restful interface draft >> | 12/2012 Snapshot version of SCIM use cases to IESG as >> Informational (possibly) >> 12/2012 Proposal for client targeting of SCIM endpoints >> | 02/2013 SCIM core schema to IESG as Proposed Standard >> | 05/2013 SCIM restful interface to IESG as Proposed Standard >> 07/2013 Initial adoption of SCIM SAML bindings draft >> 07/2013 Initial adoption of SCIM LDAP mapping draft >> | 08/2013 Client targeting of SCIM endpoints to IESG as Proposed >> Standard >> | 09/2013 Snapshot update of SCIM use cases as Informational >> (possibly) >> | 11/2013 SCIM SAML bindings to IESG as Proposed Standard >> | 12/2013 SCIM LDAP mapping to IESG as Proposed Standard >> 01/2014 Work completed; discuss re-charter >> >> Are those correct? That is, everything is meant to be Proposed >> Standard except for the use cases document (which might or might not >> get published)? >> >> MA> I was thinking LDAP mapping would be informational as there are >> MA> many >> variations of identity schema in LDAP directories and this would only >> be an instantiation of such mapping. However if others think this >> should be proposed standard, I am fine with it. >> >> 2. There's concern about the "gaps" text in this part: >> >>> In addition, the working group will ensure that the SCIM protocol >>> embodies good security practices, and will document gaps in its >>> capabilities and propose a path forward for addressing those gaps. >> >> What's that really meant to be saying? That is, why shouldn't the >> sentence simply end after "good security practices"? We certainly >> can't produce documents that *don't* use good security practices, so >> if the rest of the sentence is important we have to separate it and >> make it clear what we're getting at. >> >> MA> I think this is a side effect of tweaking the original paragraph >> over 9 revision and an unintentional use of gap in the context of >> "security practices". I originally put the "functional gap" in the >> charter as we are starting with a list of protocol/schema extensions >> some of the vendors were interested in, but we felt need additional >> discussion and thinking so we left them out of 1.0 specs. The goal of >> this original sentence was that the WG will review this list of gaps >> and decide what to do with them. This had nothing to do with security. >> Unfortunately between version 8 and 9, this was changed in addition to > >> "functional gaps" we ended up with "gap" in the new paragraph covering > >> security. I am perfectly find removing it and making it more clear. >> >> 3. There's concern by more than one AD that doing the schema >> definition without having the LDAP mapping there with it will result >> in problems, and will end up with a new schema that ultimately has as >> many problems as the existing one(s). The best suggestion to deal >> with that is to move the order around, do the LDAP mapping along with >> the schema, and send both documents to the IESG together. >> >> MA> I am fine with that change. >> >> 4. The name did come up (I told you...). It's not getting in the way, > >> at least not yet, but folks are balking at both the "simple" and the >> "cloud" parts. They wonder if there isn't a way to keep "scim", but >> to make up something new that it can stand for. Keep in mind that >> this is a minor point, though -- the other three above need to be > fixed. >> >> MA> Personally speaking, I still think we should stick with SCIM. If >> MA> the >> current traction of SCIM v1 is any indication, by the time v2 is out >> there will be quite a few implementations of it out there and we will >> have many implementations (we are almost at 10 now). A rename between >> v1 and v2 will only result in confusion and 10 years from now we will >> be using both SCIM and new name to refer to it. It is not worth it >> especially if you consider other protocol names that have "simple" in >> the name (including IETF protocols). If we *really* must change >> something, let's stay with SCIM and change "cloud" which is the only >> word there is no precedence for something else like "cross-domain" >> Stephen suggested. >> >> >> Cheers, >> Morteza >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From barryleiba.mailing.lists@gmail.com Tue May 15 08:46:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFA621F8998 for ; Tue, 15 May 2012 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR6xNnv6SyrD for ; Tue, 15 May 2012 08:46:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC5FD21F898B for ; Tue, 15 May 2012 08:46:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4847114lbb.31 for ; Tue, 15 May 2012 08:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=22rVCwahTEHAO5XsjP8b38O7Q8dSOiqE3Bcx09m2tKM=; b=aMftULxRaScedirkh+ev1Q9YIVB4aPHiejRTs8wQIgbFkfaENNttP82X/b8f4X9S5v UzUvTw1Sd6/cvF+xEdggoKSpQXHlWEa8jsNN941zLYeMjJNcRN8vvHZMT4JEPLkjZgvG dXxaLh5SyEYTlgrLNYzRc5JwjvUCY5NHS78r8L0WuLnxsBf7J/bne7OSSZn9GxB1YqDt nj+xsxcnJX/cuWuVeZRhOyAISa9t92poVUzSGDzaemgrrjawdO3TwuQA19WnypcDHfym zHJQsoK/gRmO65j4LYfAejqewASKRLf1VFgqKPpohNYImESTKKwpQP1SE4cOtnlkbS9C qjEA== MIME-Version: 1.0 Received: by 10.152.108.178 with SMTP id hl18mr3156234lab.11.1337096800649; Tue, 15 May 2012 08:46:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Tue, 15 May 2012 08:46:40 -0700 (PDT) In-Reply-To: <4FB1ACFA.1080107@stpeter.im> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> Date: Tue, 15 May 2012 11:46:40 -0400 X-Google-Sender-Auth: dbVIn3mL6FnPCJXF2hLJpEfthZQ Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:46:42 -0000 > It seems informational to me. OK, so I have done the following in my copy of the charter: - Changed the milestones as I noted above, but made the LDAP one Informational (I presume the SAML bindings doc will still be PS). - Removed the "gaps" part of the sentence about good security practices. Shall I also move the LDAP milestone, and/or put text into the charter that LDAP mapping(s) will be developed alongside the schema definition? Someone want to be specific about what text to change to make this work in the charter? Barry From kelly.grizzle@sailpoint.com Tue May 15 14:19:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EFE21F8753 for ; Tue, 15 May 2012 14:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg-vT4+Aepc5 for ; Tue, 15 May 2012 14:19:57 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id B95E521F8703 for ; Tue, 15 May 2012 14:19:56 -0700 (PDT) Received: from mail61-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 21:19:49 +0000 Received: from mail61-db3 (localhost [127.0.0.1]) by mail61-db3-R.bigfish.com (Postfix) with ESMTP id EC0461402B4; Tue, 15 May 2012 21:19:48 +0000 (UTC) X-SpamScore: -37 X-BigFish: PS-37(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail61-db3: domain of sailpoint.com designates 157.56.240.85 as permitted sender) client-ip=157.56.240.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail61-db3 (localhost.localdomain [127.0.0.1]) by mail61-db3 (MessageSwitch) id 1337116786749618_20671; Tue, 15 May 2012 21:19:46 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.241]) by mail61-db3.bigfish.com (Postfix) with ESMTP id A730C1E00CC; Tue, 15 May 2012 21:19:46 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 21:19:45 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.174]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0152.000; Tue, 15 May 2012 21:19:47 +0000 From: Kelly Grizzle To: Phil Hunt , Samuel Erdtman Thread-Topic: [scim] Conflict with extensions (consider for SICM 2.0) Thread-Index: AQHNIgebPv1XH9AlVkODZSnlthHQQJaqRU0AgCE1zlA= Date: Tue, 15 May 2012 21:19:46 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437220F22AA@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <533825DB-3E7E-4BA0-8C3E-8F96377D94D7@oracle.com> In-Reply-To: <533825DB-3E7E-4BA0-8C3E-8F96377D94D7@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:19:58 -0000 Sorry for the late reply - just digging through some old emails. The "schemas" attribute combined with the extension-specific sub-attributes= is meant to be a JSON representation of XML namespaces. The XML represent= ation does disambiguate the object type: ... Maybe the JSON representation needs something akin to the root element name= in the XML representation. Perhaps an "objectType" attribute? --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Tuesday, April 24, 2012 1:04 PM To: Samuel Erdtman Cc: scim@ietf.org Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) I think there may be a more complex issue. The URN listed is usually the e= xtension namespace and not the extension object. So if you defined: urn:scim:schemas:ext:corporate as an extended schema and within that define= d an "employee" and a "contractor" objects, then the following json would b= e ambiguous > { > "schemas":["urn:scim:schemas:core:1.0",=20 > urn:scim:schemas:ext:corporate], > "userName": "kalle", > "urn:scim:schemas:ext:corporate": { > employeeNumber: "abc123" > } > } Unless you can tell by the attributes, it is unclear whether the User above= is a "contractor" or an "employee". Should the schema URN in the extends= ion be the object URN? --> urn:scim:schemas:ext:corporate:contractor Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-24, at 3:47 AM, Samuel Erdtman wrote: > Since extensions are not contained within an extension node there are=20 > the possibility of conflicts with existing and future attributes. > Would it be desirable to put extensions within an extension node=20 > (since extensions as Kelly mentioned are defined by URN:s conflicts=20 > are in worst cases rare). > Today a user with two extensions could look like this {=20 > "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1,=20 > urn:scim:schemas:ext2], > "userName": "kalle", > "urn:scim:schemas:ext1": { > employeeNumber: "abc123" > }, > "urn:scim:schemas:ext2": { > employeeNumber: "123abc" > } > } > Would it be better to change it to this {=20 > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "extension": { > "urn:scim:schemas:ext1": { > employeeNumber: "abc123" > }, > "urn:scim:schemas:ext2": { > employeeNumber: "123abc" > } > } > } >=20 > Thoughts? > (for details see the thread > http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and=20 > the http://www.simplecloud.info/ page) //Samuel=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue May 15 14:40:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A408011E8093 for ; Tue, 15 May 2012 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.603 X-Spam-Level: X-Spam-Status: No, score=-8.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBXnk8HPSXRb for ; Tue, 15 May 2012 14:40:08 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C95AB11E8074 for ; Tue, 15 May 2012 14:40:08 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4FLe6CE005141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 21:40:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4FLe5GN019707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 21:40:05 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4FLe4Bw016507; Tue, 15 May 2012 16:40:05 -0500 Received: from [25.73.204.230] (/74.198.150.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 May 2012 14:40:04 -0700 References: <533825DB-3E7E-4BA0-8C3E-8F96377D94D7@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437220F22AA@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437220F22AA@BL2PRD0410MB351.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5572750C-69A2-4172-9CE2-4D5627FD5F14@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Tue, 15 May 2012 14:41:53 -0700 To: Kelly Grizzle X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Samuel Erdtman , "scim@ietf.org" Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:40:09 -0000 Either way works for me. What is more json friendly? Phil On 2012-05-15, at 14:19, Kelly Grizzle wrote: > Sorry for the late reply - just digging through some old emails. >=20 > The "schemas" attribute combined with the extension-specific sub-attribute= s is meant to be a JSON representation of XML namespaces. The XML represent= ation does disambiguate the object type: >=20 > > ... > >=20 > Maybe the JSON representation needs something akin to the root element nam= e in the XML representation. Perhaps an "objectType" attribute? >=20 > --Kelly >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ph= il Hunt > Sent: Tuesday, April 24, 2012 1:04 PM > To: Samuel Erdtman > Cc: scim@ietf.org > Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) >=20 > I think there may be a more complex issue. The URN listed is usually the e= xtension namespace and not the extension object. >=20 > So if you defined: >=20 > urn:scim:schemas:ext:corporate as an extended schema and within that defin= ed an "employee" and a "contractor" objects, then the following json would b= e ambiguous >=20 >> { >> "schemas":["urn:scim:schemas:core:1.0",=20 >> urn:scim:schemas:ext:corporate], >> "userName": "kalle", >> "urn:scim:schemas:ext:corporate": { >> employeeNumber: "abc123" >> } >> } >=20 > Unless you can tell by the attributes, it is unclear whether the User abov= e is a "contractor" or an "employee". Should the schema URN in the extends= ion be the object URN? --> urn:scim:schemas:ext:corporate:contractor >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-24, at 3:47 AM, Samuel Erdtman wrote: >=20 >> Since extensions are not contained within an extension node there are=20 >> the possibility of conflicts with existing and future attributes. >> Would it be desirable to put extensions within an extension node=20 >> (since extensions as Kelly mentioned are defined by URN:s conflicts=20 >> are in worst cases rare). >> Today a user with two extensions could look like this {=20 >> "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1,=20 >> urn:scim:schemas:ext2], >> "userName": "kalle", >> "urn:scim:schemas:ext1": { >> employeeNumber: "abc123" >> }, >> "urn:scim:schemas:ext2": { >> employeeNumber: "123abc" >> } >> } >> Would it be better to change it to this {=20 >> "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], >> "userName": "kalle", >> "extension": { >> "urn:scim:schemas:ext1": { >> employeeNumber: "abc123" >> }, >> "urn:scim:schemas:ext2": { >> employeeNumber: "123abc" >> } >> } >> } >>=20 >> Thoughts? >> (for details see the thread >> http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and=20 >> the http://www.simplecloud.info/ page) //Samuel=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From mrutkows@us.ibm.com Tue May 15 16:32:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF5821F8675 for ; Tue, 15 May 2012 16:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FCEUvoK9r8b for ; Tue, 15 May 2012 16:32:38 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4221F866E for ; Tue, 15 May 2012 16:32:38 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 May 2012 17:32:37 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 15 May 2012 17:32:36 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 876283E4004C for ; Tue, 15 May 2012 17:32:34 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4FNWYog165776 for ; Tue, 15 May 2012 17:32:34 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4FNXHAP031967 for ; Tue, 15 May 2012 17:33:17 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4FNXH01031961 for ; Tue, 15 May 2012 17:33:17 -0600 Auto-Submitted: auto-generated From: Matt Rutkowski To: scim@ietf.org Message-ID: Date: Tue, 15 May 2012 17:32:32 -0600 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Release 8.5.3HF266 | January 13, 2012) at 05/15/2012 17:32:33 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF36CDF12D4158f9e8a93df938690918c08BBF36CDF12D415" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12051523-7606-0000-0000-0000006053B0 Subject: [scim] AUTO: Matt Rutkowski/Austin/IBM is travelling (returning 05/21/2012) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 23:32:39 -0000 --0__=08BBF36CDF12D4158f9e8a93df938690918c08BBF36CDF12D415 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 05/21/2012. I will be travelling and unable to reliably respond to email or mobile messages. For emergencies please contact my manager Johanna Koester. Note: This is an automated response to your message "scim Digest, Vol = 5, Issue 15" sent on 05/15/2012 13:00:42. This is the only notification you will receive while this person is awa= y.= --0__=08BBF36CDF12D4158f9e8a93df938690918c08BBF36CDF12D415 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 05= /21/2012.

I will be travelling and un= able to reliably respond to email or mobile messages.  For emergen= cies please contact my manager Johanna Koester.


Note: Thi= s is an automated response to your message  "scim Digest, Vol 5, Issue 15" sent = on 05/15/2012 13:00:42.

This is t= he only notification you will receive while this person is away.= = --0__=08BBF36CDF12D4158f9e8a93df938690918c08BBF36CDF12D415-- From kelly.grizzle@sailpoint.com Wed May 16 06:33:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33721F863C for ; Wed, 16 May 2012 06:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvm0ycZMWWay for ; Wed, 16 May 2012 06:33:00 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7421F863E for ; Wed, 16 May 2012 06:32:58 -0700 (PDT) Received: from mail167-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 May 2012 13:32:50 +0000 Received: from mail167-va3 (localhost [127.0.0.1]) by mail167-va3-R.bigfish.com (Postfix) with ESMTP id DA67936033F; Wed, 16 May 2012 13:32:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT003.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25h) Received-SPF: pass (mail167-va3: domain of sailpoint.com designates 157.56.240.85 as permitted sender) client-ip=157.56.240.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0410HT003.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail167-va3 (localhost.localdomain [127.0.0.1]) by mail167-va3 (MessageSwitch) id 133717516975604_6896; Wed, 16 May 2012 13:32:49 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.240]) by mail167-va3.bigfish.com (Postfix) with ESMTP id 0C49E20046; Wed, 16 May 2012 13:32:49 +0000 (UTC) Received: from BL2PRD0410HT003.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 May 2012 13:32:47 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.112]) by BL2PRD0410HT003.namprd04.prod.outlook.com ([10.255.99.38]) with mapi id 14.16.0152.000; Wed, 16 May 2012 13:32:53 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Conflict with extensions (consider for SICM 2.0) Thread-Index: AQHNIgebPv1XH9AlVkODZSnlthHQQJaqRU0AgCE1zlCAAAfrgIABBsfQ Date: Wed, 16 May 2012 13:32:53 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437220F242D@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <533825DB-3E7E-4BA0-8C3E-8F96377D94D7@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437220F22AA@BL2PRD0410MB351.namprd04.prod.outlook.com> <5572750C-69A2-4172-9CE2-4D5627FD5F14@oracle.com> In-Reply-To: <5572750C-69A2-4172-9CE2-4D5627FD5F14@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: Samuel Erdtman , "scim@ietf.org" Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:33:01 -0000 I have seen it both ways - a top-level object wrapper and an attribute. { "Contractor": { "id": "1234", ... } } vs { "id": "1234", "objectType": "Contractor" } I prefer the latter because it looks cleaner (IMHO) and is in line with man= y other programming languages (eg - Object.getClass()). --Kelly -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Tuesday, May 15, 2012 4:42 PM To: Kelly Grizzle Cc: Samuel Erdtman; scim@ietf.org Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) Either way works for me. What is more json friendly? Phil On 2012-05-15, at 14:19, Kelly Grizzle wrote: > Sorry for the late reply - just digging through some old emails. >=20 > The "schemas" attribute combined with the extension-specific sub-attribut= es is meant to be a JSON representation of XML namespaces. The XML represe= ntation does disambiguate the object type: >=20 > xmlns:corporate=3D"urn:scim:schemas:ext:corporate"> > ... > >=20 > Maybe the JSON representation needs something akin to the root element na= me in the XML representation. Perhaps an "objectType" attribute? >=20 > --Kelly >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 > Of Phil Hunt > Sent: Tuesday, April 24, 2012 1:04 PM > To: Samuel Erdtman > Cc: scim@ietf.org > Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0) >=20 > I think there may be a more complex issue. The URN listed is usually the= extension namespace and not the extension object. >=20 > So if you defined: >=20 > urn:scim:schemas:ext:corporate as an extended schema and within that=20 > defined an "employee" and a "contractor" objects, then the following=20 > json would be ambiguous >=20 >> { >> "schemas":["urn:scim:schemas:core:1.0", >> urn:scim:schemas:ext:corporate], >> "userName": "kalle", >> "urn:scim:schemas:ext:corporate": { >> employeeNumber: "abc123" >> } >> } >=20 > Unless you can tell by the attributes, it is unclear whether the User abo= ve is a "contractor" or an "employee". Should the schema URN in the exten= dsion be the object URN? --> urn:scim:schemas:ext:corporate:contractor >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-24, at 3:47 AM, Samuel Erdtman wrote: >=20 >> Since extensions are not contained within an extension node there are=20 >> the possibility of conflicts with existing and future attributes. >> Would it be desirable to put extensions within an extension node=20 >> (since extensions as Kelly mentioned are defined by URN:s conflicts=20 >> are in worst cases rare). >> Today a user with two extensions could look like this {=20 >> "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1,=20 >> urn:scim:schemas:ext2], >> "userName": "kalle", >> "urn:scim:schemas:ext1": { >> employeeNumber: "abc123" >> }, >> "urn:scim:schemas:ext2": { >> employeeNumber: "123abc" >> } >> } >> Would it be better to change it to this {=20 >> "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], >> "userName": "kalle", >> "extension": { >> "urn:scim:schemas:ext1": { >> employeeNumber: "abc123" >> }, >> "urn:scim:schemas:ext2": { >> employeeNumber: "123abc" >> } >> } >> } >>=20 >> Thoughts? >> (for details see the thread >> http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and=20 >> the http://www.simplecloud.info/ page) //Samuel=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From jeremy@palenchar.net Wed May 16 10:31:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF11E21F8701 for ; Wed, 16 May 2012 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXaX6PKmkuv8 for ; Wed, 16 May 2012 10:31:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54D9921F86D6 for ; Wed, 16 May 2012 10:31:45 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1423612pbc.31 for ; Wed, 16 May 2012 10:31:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :content-language:thread-index:x-gm-message-state; bh=nhJJvaVdM1CwRQ2mslVBGLidQRpjbPcjmZKBMYcbNAk=; b=OLWaDt2oWJLmSkedSzce4E+1igGnImSbAhJcblXRnaCub8nbeVZdjRqTFbOeS6m4XL 1YWtzAxBjiYPbcHVpk8cKU4pN4euEMy6/jiadDJS+7D7KiimCpKCZ+O5VEa/LGISAkP3 z0aWdqVKJZn5glEtI8deFYXdV69n98MXQeT0I9hLZm6e1o2ZID9ECuEictWJIpqqOGhO ckl7wzUKRcLiHOE9u1qlFG1n19MxgW58WXZssAfEm5YmFEA3VSmRmyC0ywJya9Xntb0h 4mkXK0Hrp954FUWCUNxJpiBTSXk6SelB//OvnSQV0r7nyDLeUsnK8eCdk+r7mOYuQ2Sj K9dQ== Received: by 10.68.192.74 with SMTP id he10mr18228856pbc.69.1337189504861; Wed, 16 May 2012 10:31:44 -0700 (PDT) Received: from W5202008R2JP (c-67-183-220-246.hsd1.wa.comcast.net. [67.183.220.246]) by mx.google.com with ESMTPS id pj5sm6089562pbb.51.2012.05.16.10.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 10:31:43 -0700 (PDT) From: "Jeremy Palenchar" To: , Date: Wed, 16 May 2012 10:33:56 -0700 Message-ID: <04b201cd338a$14d46660$3e7d3320$@palenchar.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B3_01CD334F.687651B0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac0zifaOU/Ikx3dLQ8ylahQRqL8rzA== X-Gm-Message-State: ALoCoQnNeCMjVilRjFEt/ozX5ftfkO9CvVLFZdggFbIZGHgvWvUIJoGmMv7Zo6cEOnm0cs8gB9bn Subject: [scim] SCIM for Amazon AWS X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:31:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B3_01CD334F.687651B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am interested to know if Amazon is planning on supporting SCIM for provisioning users into AWS. Please let me know if you have information on this. Thanks! -Jeremy ------=_NextPart_000_04B3_01CD334F.687651B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = interested to know if Amazon is planning on supporting SCIM for = provisioning users into AWS.

 

Please let = me know if you have information on this.

 

Thanks!

 

-Jeremy

------=_NextPart_000_04B3_01CD334F.687651B0-- From moransar@cisco.com Wed May 16 23:23:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F90511E8081 for ; Wed, 16 May 2012 23:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uZnS0PtzrF8 for ; Wed, 16 May 2012 23:23:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2947B11E8072 for ; Wed, 16 May 2012 23:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3054; q=dns/txt; s=iport; t=1337235783; x=1338445383; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Fdr+CMbp/mc7vigf1dNZ8VQO/q3LRE2SlV/ehzNPPJI=; b=g3HohacePYHQGlU0zY1xgItBL1T5B9su8BFn3EeJeNWAqBbSSM+2vOgG +ONzMur86osD2hW7+OA37kNx8i0UTZ4zkMGnjL+Nn95rAUiXeXGL40nxa YIQqZ+kitpPN/IUd08CAwW39tKpKA4aOpPIHNFE14HyKNgY5ObiZjwvt8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACSVtE+tJV2Y/2dsb2JhbAA6CrNFgQeCFQEBAQMBAQEBDwEdCjQQBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZwULm3KfcASLEw+EZmIDiGObboFpgwc X-IronPort-AV: E=Sophos;i="4.75,607,1330905600"; d="scan'208";a="80988185" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 17 May 2012 06:23:02 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4H6N2TJ005202; Thu, 17 May 2012 06:23:02 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 01:23:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2012 01:23:01 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0yse/0tYFqKbaXT4OUCzQGclljNAAGOvNA References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com><4FB1ACFA.1080107@stpeter.im> From: "Morteza Ansari (moransar)" To: "Barry Leiba" , X-OriginalArrivalTime: 17 May 2012 06:23:02.0614 (UTC) FILETIME=[8347D760:01CD33F5] Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 06:23:04 -0000 Barry, How about this (if you give me your changes, I can roll them in or you can apply these changes to your version): *** charter9.txt 2012-04-30 06:56:43.000000000 -0700 --- charter10.txt 2012-05-16 23:20:14.000000000 -0700 *************** *** 42,50 **** - schema discovery - read and search - bulk operations It will follow that by considering extensions for client targeting of ! specific SCIM endpoints, SAML binding, and LDAP mapping. The approach ! will be extensible. =20 The group will use, as starting points, the following drafts in the following ways: --- 42,51 ---- - schema discovery - read and search - bulk operations + - mapping between inetOrgPerson (RFC2798) and SCIM schema It will follow that by considering extensions for client targeting of ! specific SCIM endpoints and SAML binding. The approach will be ! extensible. =20 The group will use, as starting points, the following drafts in the following ways: *************** *** 60,69 **** including the OASIS Provisioning TC. =20 The group will produce Proposed Standards for a schema, a REST-based ! protocol, a SAML binding, and an LDAP mapping. In doing so, the group ! will make the terminology consistent, identify any functional gaps ! that would be useful for future work, address internationalization, ! and provide guidelines and mechanisms for extensibility. =20 In addition, the working group will ensure that the SCIM protocol embodies good security practices, and will document gaps in its --- 61,71 ---- including the OASIS Provisioning TC. =20 The group will produce Proposed Standards for a schema, a REST-based ! protocol, a SAML binding, and an LDAP mapping Informational document. ! In doing so, the group will make the terminology consistent, identify ! any functional gaps that would be useful for future work, address ! internationalization, and provide guidelines and mechanisms for ! extensibility. =20 In addition, the working group will ensure that the SCIM protocol embodies good security practices, and will document gaps in its -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, May 15, 2012 8:47 AM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB > It seems informational to me. OK, so I have done the following in my copy of the charter: - Changed the milestones as I noted above, but made the LDAP one Informational (I presume the SAML bindings doc will still be PS). - Removed the "gaps" part of the sentence about good security practices. Shall I also move the LDAP milestone, and/or put text into the charter that LDAP mapping(s) will be developed alongside the schema definition? Someone want to be specific about what text to change to make this work in the charter? Barry _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From barryleiba@gmail.com Thu May 17 07:47:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1E21F85F0 for ; Thu, 17 May 2012 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr3kKEfuQJ3b for ; Thu, 17 May 2012 07:47:03 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2687B21F85D8 for ; Thu, 17 May 2012 07:47:03 -0700 (PDT) Received: by yenq13 with SMTP id q13so2180761yen.31 for ; Thu, 17 May 2012 07:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=z/gQSJUBVixepl0DjwtXNvcNqkJ8SJPUV9ZFoxQcEGk=; b=Om70nmIuN20tJLFkuQZdWGGKljOgmf2LuULrpsr9x+nBBavzWskhy1tFt6pT0uckPO SKRcQIV3pqGKe/GOOc8MRMgncYLL8ampTsUjCkd7+cvG1Max0Z1I4Sn0CUjWHuPrJiHP FWDuKtwCBnIl2CBORYOKPSH1aVub+SKXKcgtRxY97bu0SWtyvOp8O9fupyuaaEmzVpSr G6oKo08utImBWMFlkEj0oXLNoPLtI0FY1ClORh9FxgQnyvqlfYp49ww2AMTZnxbSypMR 0k/zyLMpHIWsGiEBxa0NH7R1A0pfYXg/AWQsBwoCzu5e2ftrNKv4/81L4tRVdHBEyJpW X7ug== MIME-Version: 1.0 Received: by 10.60.29.41 with SMTP id g9mr6755894oeh.18.1337266022588; Thu, 17 May 2012 07:47:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Thu, 17 May 2012 07:47:02 -0700 (PDT) In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> Date: Thu, 17 May 2012 10:47:02 -0400 X-Google-Sender-Auth: oU0RxdlWr8Y_efkVgGjMDCYGwvc Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: multipart/mixed; boundary=e89a8fb2033a3f20a104c03c8216 Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:47:04 -0000 --e89a8fb2033a3f20a104c03c8216 Content-Type: text/plain; charset=ISO-8859-1 > How about this (if you give me your changes, I can roll them in or you > can apply these changes to your version): That looks good, and attached is the next draft version that includes these changes (with some text tweaks from me). The only question left before I send this version in and schedule it for the telechat is whether we want to move the LDAP milestone dates. Right now, the initial adoption of a draft for the LDAP mapping is 5 months after the completion of the SCIM schema. I suggest pulling that back significantly, perhaps thus: OLD 12/2012 Proposal for client targeting of SCIM endpoints 02/2013 SCIM core schema to IESG as Proposed Standard 05/2013 SCIM restful interface to IESG as Proposed Standard 07/2013 Initial adoption of SCIM SAML bindings draft | 07/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard 09/2013 Snapshot update of SCIM use cases as Informational (possibly) 11/2013 SCIM SAML bindings to IESG as Proposed Standard | 12/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational 01/2014 Work completed; discuss re-charter NEW 12/2012 Proposal for client targeting of SCIM endpoints | 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft 02/2013 SCIM core schema to IESG as Proposed Standard 05/2013 SCIM restful interface to IESG as Proposed Standard | 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational 07/2013 Initial adoption of SCIM SAML bindings draft 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard 09/2013 Snapshot update of SCIM use cases as Informational (possibly) 11/2013 SCIM SAML bindings to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter Does that work? I should get the update in today in order to put it on next week's telechat. Barry --e89a8fb2033a3f20a104c03c8216 Content-Type: text/plain; charset=US-ASCII; name="charter-ietf-scim-00-01.txt" Content-Disposition: attachment; filename="charter-ietf-scim-00-01.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2bxk7ie0 U2ltcGxlIENsb3VkIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pCgpDaGFpcihzKTogVEJEIAoK QXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3Iocyk6CiAgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0Bx dWFsY29tbS5jb20+IAogIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gCgpN YWlsaW5nIExpc3RzOgogIEdlbmVyYWwgRGlzY3Vzc2lvbjogc2NpbUBpZXRmLm9yZwogIFRvIFN1 YnNjcmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt CiAgQXJjaGl2ZTogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvc2NpbS8KIApEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOgoKVGhlIFNpbXBsZSBDbG91 ZCBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSB3b3JraW5nIGdyb3VwIHdpbGwKc3RhbmRhcmRp emUgbWV0aG9kcyBmb3IgY3JlYXRpbmcsIHJlYWRpbmcsIHNlYXJjaGluZywgbW9kaWZ5aW5nLCBh bmQKZGVsZXRpbmcgdXNlciBpZGVudGl0aWVzIGFuZCBpZGVudGl0eS1yZWxhdGVkIG9iamVjdHMg YWNyb3NzCmFkbWluaXN0cmF0aXZlIGRvbWFpbnMsIHdpdGggdGhlIGdvYWwgb2Ygc2ltcGxpZnlp bmcgY29tbW9uIHRhc2tzCnJlbGF0ZWQgdG8gdXNlciBpZGVudGl0eSBtYW5hZ2VtZW50IGluIHNl cnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMuCgoiU3RhbmRhcmRpemUiIGRvZXMgbm90IG5lY2Vzc2Fy aWx5IG1lYW4gdGhhdCB0aGUgd29ya2luZyBncm91cCB3aWxsCmRldmVsb3AgbmV3IHRlY2hub2xv Z2llcy4gIEZvciBleGFtcGxlLCB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMKZm9yICJTQ0lN IDEuMCIgcHJvdmlkZSBSRVNUZnVsIGludGVyZmFjZXMgb24gdG9wIG9mIEhUVFAgcmF0aGVyIHRo YW4KZGVmaW5pbmcgYSBuZXcgYXBwbGljYXRpb24gcHJvdG9jb2wuCgpUb2RheSwgZGlzdHJpYnV0 ZWQgaWRlbnRpdHkgbWFuYWdlbWVudCBhY3Jvc3MgYWRtaW5pc3RyYXRpdmUgZG9tYWlucwppcyBj b21wbGljYXRlZCBieSBhIGxhY2sgb2YgcHJvdG9jb2wgYW5kIHNjaGVtYSBzdGFuZGFyZGl6YXRp b24KYmV0d2VlbiBjb25zdW1lcnMgYW5kIHByb2R1Y2VycyBvZiBpZGVudGl0aWVzLiAgVGhpcyBo YXMgbGVkIHRvIGEKbnVtYmVyIG9mIGFwcHJvYWNoZXMsIGluY2x1ZGluZyBlcnJvci1wcm9uZSBt YW51YWwgYWRtaW5pc3RyYXRpb24gYW5kCmJ1bGsgZmlsZSB1cGxvYWRzLCBhcyB3ZWxsIGFzIHBy b3ByaWV0YXJ5IHByb3RvY29scyBhbmQgbWVkaWF0aW9uCmRldmljZXMgdGhhdCBtdXN0IGJlIGFk YXB0ZWQgdG8gZWFjaCBzZXJ2aWNlIGZvciBlYWNoIG9yZ2FuaXphdGlvbi4gCldoaWxlIHRoZXJl IGlzIGV4aXN0aW5nIHdvcmsgaW4gdGhlIGZpZWxkLCBpdCBoYXMgbm90IGJlZW4gd2lkZWx5CmFk b3B0ZWQgZm9yIGEgdmFyaWV0eSBvZiByZWFzb25zLCBpbmNsdWRpbmcgYSBsYWNrIG9mIGNvbW1v biBhcnRpZmFjdHMKc3VjaCBhcyBzY2hlbWEsIHRvb2xzZXRzLCBhbmQgbGlicmFyaWVzLgoKVGhl IFNDSU0gd29ya2luZyBncm91cCB3aWxsIGRldmVsb3AgdGhlIGNvcmUgc2NoZW1hIGFuZCBSRVNU ZnVsCmludGVyZmFjZXMgdG8gYWRkcmVzcyB0aGVzZSBwcm9ibGVtcy4gIEluaXRpYWxseSwgdGhl IGdyb3VwIHdpbGwgZm9jdXMKb24KLSBhIHNjaGVtYSBkZWZpbml0aW9uCi0gYSBzZXQgb2Ygb3Bl cmF0aW9ucyBmb3IgY3JlYXRpb24sIG1vZGlmaWNhdGlvbiwgYW5kIGRlbGV0aW9uIG9mIHVzZXJz Ci0gc2NoZW1hIGRpc2NvdmVyeQotIHJlYWQgYW5kIHNlYXJjaAotIGJ1bGsgb3BlcmF0aW9ucwot IG1hcHBpbmcgYmV0d2VlbiB0aGUgaW5ldE9yZ1BlcnNvbiBMREFQIG9iamVjdCBjbGFzcyAoUkZD IDI3OTgpIGFuZAogIHRoZSBTQ0lNIHNjaGVtYQoKSXQgd2lsbCBmb2xsb3cgdGhhdCBieSBjb25z aWRlcmluZyBleHRlbnNpb25zIGZvciBjbGllbnQgdGFyZ2V0aW5nIG9mCnNwZWNpZmljIFNDSU0g ZW5kcG9pbnRzIGFuZCBTQU1MIGJpbmRpbmcuICBUaGUgYXBwcm9hY2ggd2lsbCBiZQpleHRlbnNp YmxlLgoKVGhlIGdyb3VwIHdpbGwgdXNlLCBhcyBzdGFydGluZyBwb2ludHMsIHRoZSBmb2xsb3dp bmcgZHJhZnRzIGluIHRoZQpmb2xsb3dpbmcgd2F5czoKICAgICBkcmFmdC1zY2ltLXVzZS1jYXNl cy0wMCBhcyB0aGUgaW5pdGlhbCB1c2UgY2FzZXMgZm9yIFNDSU0KICAgICBkcmFmdC1zY2ltLWNv cmUtc2NoZW1hLTAwIGFzIHRoZSBzY2hlbWEgc3BlY2lmaWNhdGlvbgogICAgIGRyYWZ0LXNjaW0t YXBpLTAwIGFzIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uCgpUaGVzZSBkcmFmdHMgYXJlIGJh c2VkIG9uIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zLCB3aGljaCB0b2dldGhlciBhcmUKY29tbW9u bHkga25vd24gYXMgU0NJTSAxLjAuICBCZWNhdXNlIHRoZXJlIGlzIGV4aXN0aW5nIHdvcmsgd2l0 aApleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIHNvbWUgY29uc2lkZXJhdGlvbiBzaG91bGQgYmUg Z2l2ZW4gdG8KYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgdGhvdWdoIGdldHRpbmcgaXQgcmlnaHQg dGFrZXMgcHJpb3JpdHkuICBUaGlzCmdyb3VwIHdpbGwgY29uc2lkZXIgdGhlIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2UgZ2F0aGVyZWQgZnJvbSB0aGUKZXhpc3Rpbmcgd29yaywgYXMgd2VsbCBhcyBl eHBlcmllbmNlcyB3aXRoIHdvcmsgZG9uZSBieSBvdGhlciBib2RpZXMsCmluY2x1ZGluZyB0aGUg T0FTSVMgUHJvdmlzaW9uaW5nIFRDLgoKVGhlIHVzZSBjYXNlcyBkb2N1bWVudCB3aWxsIGJlIGEg ImxpdmluZyBkb2N1bWVudCIsIGd1aWRpbmcgdGhlCndvcmtpbmcgZ3JvdXAgZHVyaW5nIGl0cyBk ZXZlbG9wbWVudCBvZiB0aGUgc3RhbmRhcmRzLiAgVGhlIGdyb3VwIG1heQp0YWtlIHNuYXBzaG90 cyBvZiB0aGF0IGRvY3VtZW50IGZvciBJbmZvcm1hdGlvbmFsIHB1YmxpY2F0aW9uLCB0bwpzZXJ2 ZSBhcyBkb2N1bWVudGF0aW9uIG9mIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUgd29yayBpbiBwcm9n cmVzcwphbmQgdG8gc2ltaWxhcmx5IGd1aWRlIHBsYW5uaW5nIGFuZCBpbXBsZW1lbnRhdGlvbi4K ClRoZSBncm91cCB3aWxsIHByb2R1Y2UgUHJvcG9zZWQgU3RhbmRhcmRzIGZvciBhIHNjaGVtYSwg YSBSRVNULWJhc2VkCnByb3RvY29sLCBhbmQgYSBTQU1MIGJpbmRpbmcsIGFzIHdlbGwgYXMgYW4g SW5mb3JtYXRpb25hbCBkb2N1bWVudApkZWZpbmluZyBhbiBMREFQIG1hcHBpbmcuIEluIGRvaW5n IHNvLCB0aGUgZ3JvdXAgd2lsbCBtYWtlIHRoZQp0ZXJtaW5vbG9neSBjb25zaXN0ZW50LCBpZGVu dGlmeSBhbnkgZnVuY3Rpb25hbCBnYXBzIHRoYXQgd291bGQgYmUKdXNlZnVsIGZvciBmdXR1cmUg d29yaywgYWRkcmVzcyBpbnRlcm5hdGlvbmFsaXphdGlvbiwgYW5kIHByb3ZpZGUKZ3VpZGVsaW5l cyBhbmQgbWVjaGFuaXNtcyBmb3IgZXh0ZW5zaWJpbGl0eS4KCkluIGFkZGl0aW9uLCB0aGUgd29y a2luZyBncm91cCB3aWxsIGVuc3VyZSB0aGF0IHRoZSBTQ0lNIHByb3RvY29sCmVtYm9kaWVzIGdv b2Qgc2VjdXJpdHkgcHJhY3RpY2VzLiBHaXZlbiBib3RoIHRoZSBzZW5zaXRpdml0eSBvZiB0aGUK aW5mb3JtYXRpb24gYmVpbmcgY29udmV5ZWQgaW4gU0NJTSBtZXNzYWdlcyBhbmQgdGhlIHJlZ3Vs YXRvcnkKcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyB0aGUgcHJpdmFjeSBvZiBwZXJzb25hbGx5IGlk ZW50aWZpYWJsZQppbmZvcm1hdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwYXkgcGFydGlj dWxhciBhdHRlbnRpb24gdG8gaXNzdWVzCmFyb3VuZCBhdXRoZW50aWNpdHkgYW5kIHByaXZhY3ku CgpUaGUgZ3JvdXAgY29uc2lkZXJzIHRoZSBmb2xsb3dpbmcgb3V0IG9mIHNjb3BlIGZvciB0aGlz IGdyb3VwOgogICAgIERlZmluaW5nIG5ldyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzCiAgICAgRGVm aW5pbmcgbmV3IHBvbGljeS9hdXRob3JpemF0aW9uIHNjaGVtZXMKCk1pbGVzdG9uZXMKCjA2LzIw MTIgICAgSW5pdGlhbCBhZG9wdGlvbiBvZiBTQ0lNIHVzZSBjYXNlcywgYXMgYSBsaXZpbmcgZG9j dW1lbnQKMDYvMjAxMiAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gY29yZSBzY2hlbWEKMDgv MjAxMiAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gcmVzdGZ1bCBpbnRlcmZhY2UgZHJhZnQK MTIvMjAxMiAgICBTbmFwc2hvdCB2ZXJzaW9uIG9mIFNDSU0gdXNlIGNhc2VzIHRvIElFU0cgYXMg SW5mb3JtYXRpb25hbCAocG9zc2libHkpCjEyLzIwMTIgICAgUHJvcG9zYWwgZm9yIGNsaWVudCB0 YXJnZXRpbmcgb2YgU0NJTSBlbmRwb2ludHMKMDIvMjAxMyAgICBTQ0lNIGNvcmUgc2NoZW1hIHRv IElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQKMDUvMjAxMyAgICBTQ0lNIHJlc3RmdWwgaW50ZXJm YWNlIHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQKMDcvMjAxMyAgICBJbml0aWFsIGFkb3B0 aW9uIG9mIFNDSU0gU0FNTCBiaW5kaW5ncyBkcmFmdAowNy8yMDEzICAgIEluaXRpYWwgYWRvcHRp b24gb2YgU0NJTSBMREFQIGluZXRPcmdQZXJzb24gbWFwcGluZyBkcmFmdAowOC8yMDEzICAgIENs aWVudCB0YXJnZXRpbmcgb2YgU0NJTSBlbmRwb2ludHMgdG8gSUVTRyBhcyBQcm9wb3NlZCBTdGFu ZGFyZAowOS8yMDEzICAgIFNuYXBzaG90IHVwZGF0ZSBvZiBTQ0lNIHVzZSBjYXNlcyBhcyBJbmZv cm1hdGlvbmFsIChwb3NzaWJseSkKMTEvMjAxMyAgICBTQ0lNIFNBTUwgYmluZGluZ3MgdG8gSUVT RyBhcyBQcm9wb3NlZCBTdGFuZGFyZAoxMi8yMDEzICAgIFNDSU0gTERBUCBpbmV0T3JnUGVyc29u IG1hcHBpbmcgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsCjAxLzIwMTQgICAgV29yayBjb21wbGV0 ZWQ7IGRpc2N1c3MgcmUtY2hhcnRlcgo= --e89a8fb2033a3f20a104c03c8216-- From moransar@cisco.com Thu May 17 14:53:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A262B21F86A3 for ; Thu, 17 May 2012 14:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT-IEPO0KeJp for ; Thu, 17 May 2012 14:53:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CA82621F8629 for ; Thu, 17 May 2012 14:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=2308; q=dns/txt; s=iport; t=1337291598; x=1338501198; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=G6oumjyaFLxOLJm1ghXH/WGs10xJEysvChLdrqKpYPY=; b=ZE7f0Y5yhui7t2GYpEOf5NUycloazU8xfPQxSAUGWx8mm2GtCVoZUQVv zz6sGRuOquDZZVfQwec0DnlMDZmjwHSQy/O1nd7Dn8HYyoKBrMJmiLhPl WbmaNg8Hh10BIJrBhirLeh111wHN0CWIWKjKiqywtvvYi8piWQygq/XHd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACJytU+tJXG8/2dsb2JhbABEs0qBB4IVAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHZwWcHKACiwSEaWIDiFubNYFkgwc X-IronPort-AV: E=Sophos;i="4.75,612,1330905600"; d="scan'208";a="84281056" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 May 2012 21:53:18 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4HLrIqI030705; Thu, 17 May 2012 21:53:18 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 16:53:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2012 16:53:17 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac00O+76oEV4wv6AQ5aUNXEST6dJNwAOvjOw References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com><4FB1ACFA.1080107@stpeter.im><93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> From: "Morteza Ansari (moransar)" To: "Barry Leiba" X-OriginalArrivalTime: 17 May 2012 21:53:18.0073 (UTC) FILETIME=[77E2FE90:01CD3477] Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:53:19 -0000 Looks good to me. Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Thursday, May 17, 2012 7:47 AM To: Morteza Ansari (moransar) Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB > How about this (if you give me your changes, I can roll them in or you > can apply these changes to your version): That looks good, and attached is the next draft version that includes these changes (with some text tweaks from me). The only question left before I send this version in and schedule it for the telechat is whether we want to move the LDAP milestone dates. Right now, the initial adoption of a draft for the LDAP mapping is 5 months after the completion of the SCIM schema. I suggest pulling that back significantly, perhaps thus: OLD 12/2012 Proposal for client targeting of SCIM endpoints 02/2013 SCIM core schema to IESG as Proposed Standard 05/2013 SCIM restful interface to IESG as Proposed Standard 07/2013 Initial adoption of SCIM SAML bindings draft | 07/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard 09/2013 Snapshot update of SCIM use cases as Informational (possibly) 11/2013 SCIM SAML bindings to IESG as Proposed Standard | 12/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational 01/2014 Work completed; discuss re-charter NEW 12/2012 Proposal for client targeting of SCIM endpoints | 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft 02/2013 SCIM core schema to IESG as Proposed Standard 05/2013 SCIM restful interface to IESG as Proposed Standard | 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational 07/2013 Initial adoption of SCIM SAML bindings draft 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard 09/2013 Snapshot update of SCIM use cases as Informational (possibly) 11/2013 SCIM SAML bindings to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter Does that work? I should get the update in today in order to put it on next week's telechat. Barry From surenck@gmail.com Mon May 21 17:57:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2021F85A1; Mon, 21 May 2012 17:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIRuQxvGRy4g; Mon, 21 May 2012 17:57:27 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5721F8569; Mon, 21 May 2012 17:57:22 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4440164qcs.31 for ; Mon, 21 May 2012 17:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=pNK8gEqjsYvVQaZaKe1ryUySoP+jPfELmzKTVFfOE4E=; b=eu5LSAUJnfkER+zPFPJdxad/25hIzyEF8qxuhvg9jkyl/er80ktrMZTf3Jmj2y2PSK 8XvS37KgGQ9b/qmB9DgOIJrVJ3YjLz7iYnPWcowxPOKt1LqxNScdAFaZy6lgA/KmT4i1 Orvxm9CaXOmR1UZ0HroNa65wAqukl5DMpbXeSYNHtxfiGEgmxYjZ/r1l4oSkXeFpaLh6 mphdsjJbrrfIddFM74i1Pcw7/tIGGjo/HuroyS2ezJ4mxwPlKa0Te6hgjwj5TeIfecna QI9locV6XRIL5ruGvKXHcrQF4aAMKbY0BQHufFcsuaIRCLdEdE4d6jUjE9tbMpowz8CR d4pA== Received: by 10.229.136.66 with SMTP id q2mr11082811qct.32.1337648242183; Mon, 21 May 2012 17:57:22 -0700 (PDT) Received: from TRAYAATESURENK (c-24-147-245-141.hsd1.ma.comcast.net. [24.147.245.141]) by mx.google.com with ESMTPS id gw2sm42269429qab.10.2012.05.21.17.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 17:57:20 -0700 (PDT) From: "Suren Karavettil" To: , , , References: In-Reply-To: Date: Mon, 21 May 2012 20:57:24 -0400 Message-ID: <005001cd37b5$daf6fb80$90e4f280$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CD3794.53E55B80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0SgPdvFz4TADxpRGyKOPN6fV7xuQlMyQLw Content-Language: en-us X-Mailman-Approved-At: Mon, 21 May 2012 18:02:58 -0700 Cc: wei.dong@tek.com, ning.so@tatacommunications.com, vumip1@gmail.com Subject: [scim] Virtual Data Center Security Framework - Informational Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 00:57:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01CD3794.53E55B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm in the process of getting this Information Draft for the Cloud Security Framework in a Virtual Data Center Operations updated in the next 2-3 weeks. The security concepts and areas are equally applicable in the network, systems and applications environment. I would like hear from members who like to share their ideas in the security area (specifically how it would impact the Cloud) and interested in contributing to this Draft. IETF draft URL: http://tools.ietf.org/html/draft-karavettil-vdcs-security-framework-03 Please reach out to anyone of the authors listed in cc. Look forward to hearing from the team members. Thank you. -- Best Regards, Suren Karavettil 978-857-5461 surenck@gmail.com http://www.linkedin.com/in/skaravettil ------=_NextPart_000_0051_01CD3794.53E55B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’m in the = process of getting this Information Draft for the Cloud Security = Framework in a Virtual Data Center Operations updated in the next 2-3 = weeks. The security concepts and areas are equally applicable in the = network, systems and applications environment.

 

I would like hear = from members who like to share their ideas in the security area = (specifically how it would impact the Cloud) and interested in = contributing to this Draft.

 

 

Please reach out to anyone of the authors listed in = cc. Look forward to hearing from the team members.

 

Thank = you.

 

-- =

Best Regards,
Suren = Karavettil
978-857-5461
surenck@gmail.com

http://www.linkedin.com/in/skaravettil=

 <= /o:p>

------=_NextPart_000_0051_01CD3794.53E55B80-- From barryleiba.mailing.lists@gmail.com Thu May 24 11:15:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9611E8083 for ; Thu, 24 May 2012 11:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuZcwB---nzF for ; Thu, 24 May 2012 11:15:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3B11E8076 for ; Thu, 24 May 2012 11:15:32 -0700 (PDT) Received: by lagv3 with SMTP id v3so58696lag.31 for ; Thu, 24 May 2012 11:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=c0qmK9ChFMebI4t85OlwINIMw6Z8KJLnMVARyTTet0k=; b=cFx8DWFZIJFJTrKSN3VKQ8TmZHjQpUfD5Zvk9bqlz6fJpGWD6GdfOjj+pkm4JgnJ4r y6zsGMcVJ9nvQdq8jCQjlFpOYVrjGeNwGqyLbAtYNSWm3V2s14eA69KSj2Bz9RfRQhLF UfXKlZl7zWNKfk365bN6MS6/1YTbmNZfftDAjLmKhtmJkNKo3pBXhIpianLEUXNsj4+i Q/oGvVljENOlhGVfpKl6cTx3g+bpmLBfhigriW3MZlgka1MtNK0cp3KRUBZ50rm/gAHy kkw+JC+udoR7PmKHrGuYdzHMjb4cP/ZNkcNAQdxG1OmqPfjD8/y7d/Ypp6yXgTEYxJ/j w9kg== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr413570lab.20.1337883331362; Thu, 24 May 2012 11:15:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 24 May 2012 11:15:31 -0700 (PDT) In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> Date: Thu, 24 May 2012 14:15:31 -0400 X-Google-Sender-Auth: FwYKzw8QtqjBSD6yrd4Ww3jQ8no Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:15:33 -0000 I have good news and bad news from the IESG telechat today. The good news is that the IESG is happy with the charter. The only change they asked for was a one-word addition to make it clear that "authorization" will also be included in the security bit: OLD In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues | around authenticity and privacy. NEW In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues | around authorization, authenticity, and privacy. The bad news is on the name, "SCIM": that dog will not hunt. It's not just Pete, who fought it on this list: at least three other ADs want the name changed before we can approve the charter for external review. The IESG is working on an alternative name -- one that was suggested was "Inter-Domain User Identity Management", giving a working group acronym of "iduim". This group can, of course, propose other names... in the end, the IESG will pick the name, though it would be nice to have agreement from the community. But here's the thing: - Give up on "simple". There've been too many protocols with that in the name, and none of them are. - Give up on "cloud". This will certainly be used by cloud providers, but is not specific to that use, and the name "cloud" carries too much baggage and too many other assumptions. - "Identity management" by itself is a broader topic than what we're talking about here. "User identity management" might work (see the suggestion above), as might other formulations you may come up with. Barry From melinda.shore@gmail.com Thu May 24 11:27:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A4B11E80A3 for ; Thu, 24 May 2012 11:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W43aebw+D40W for ; Thu, 24 May 2012 11:27:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E611E80AB for ; Thu, 24 May 2012 11:27:01 -0700 (PDT) Received: by dacx6 with SMTP id x6so98806dac.31 for ; Thu, 24 May 2012 11:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lOjGLwttaTJlkHF736o5IEyN1US7AnLTVVfV+U8Uah4=; b=CZIK4U8RiDBa6qngji+JA+MofyB5pFZAY/W/1ZkMB8wnJC7+EtiQRmMcQAc0TdWPBe 1KKTddogOSToPuhY9keg/vJlf8C++nbKavgeRGs4Rc4m2zUmF28lXRWA79SkvmsqZKCu 5buK2popCUs4zqIOOnTFx28uzgeVLFSHoUspkz9gOuQvhftl78EnLDUwPIFVm+k12WqT +QlELdzfIMZ0WAzzEfAQOk6yq9cJghFxX3MyJKeWPReG3zKflln5FzHRX/20V8lKUOuU L3hcm7KHPd6lSdXft7u4kwUTHb7MiyiOAXTnDfXfZgR5HCIcrUnxRXwDLVGq4NpMPTA5 kQdA== Received: by 10.68.227.163 with SMTP id sb3mr24146979pbc.74.1337884020771; Thu, 24 May 2012 11:27:00 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id ve6sm6196196pbc.75.2012.05.24.11.26.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 11:27:00 -0700 (PDT) Message-ID: <4FBE7D72.4050205@gmail.com> Date: Thu, 24 May 2012 10:26:58 -0800 From: Melinda Shore User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Barry Leiba References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:27:02 -0000 Barry Leiba wrote: > The bad news is on the name, "SCIM": that dog will not hunt. *GOOD*. > The IESG is working on an alternative name -- one that was suggested > was "Inter-Domain User Identity Management", giving a working group > acronym of "iduim". I'd drop "user" and switch "management" to "provisioning." I hope the days of cute, tortured working group names are over. Melinda From stpeter@stpeter.im Thu May 24 11:29:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9F11E80AB for ; Thu, 24 May 2012 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMd4K3Pa8VtQ for ; Thu, 24 May 2012 11:29:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6617411E8076 for ; Thu, 24 May 2012 11:29:28 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD64140067; Thu, 24 May 2012 12:45:36 -0600 (MDT) Message-ID: <4FBE7E04.6080505@stpeter.im> Date: Thu, 24 May 2012 12:29:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melinda Shore References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7D72.4050205@gmail.com> In-Reply-To: <4FBE7D72.4050205@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:29:29 -0000 On 5/24/12 12:26 PM, Melinda Shore wrote: > Barry Leiba wrote: >> The bad news is on the name, "SCIM": that dog will not hunt. > > *GOOD*. > > >> The IESG is working on an alternative name -- one that was suggested >> was "Inter-Domain User Identity Management", giving a working group >> acronym of "iduim". > > I'd drop "user" and switch "management" to "provisioning." > > I hope the days of cute, tortured working group names are > over. Inter Domain Identity Operation Tools is catchy. Peter -- Peter Saint-Andre https://stpeter.im/ From melinda.shore@gmail.com Thu May 24 11:31:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167E311E80A4 for ; Thu, 24 May 2012 11:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRvuFJp922ld for ; Thu, 24 May 2012 11:31:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85F11E8076 for ; Thu, 24 May 2012 11:31:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so104526dac.31 for ; Thu, 24 May 2012 11:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6U2R5FvQ5lZs2Pr1rS403LvGUVOB8BVySi//cKzlRvo=; b=DQTs9IWof0yg/jR0ImssliOmvPrTxb44x+qV3ArOZYP7oe4XSLeLDr51F9/Kg2O8Ub nJ1rmfMIsai+pN8ICGUKMNKQxoP21R929tPHVniAPp1JzuxLEPnvZ+UDTiZYxWIWBQjg lxHhPH/oEuVZ7q1ukVeSIHv5OoGGQJQewyNiMzqB9b6TRsBm8ysNQVlWTt+6QmjE+JVi LqbQo56Q1TKzUoRYTOA4tNnrd39f1IsJ+iT7ijrR8Y7BGYNFbO6PpBKMvSeMgRMFq0Qj DrHaAc/eFOGTTgL6Ve2Qol7DqoxiJk0pTjkIIJavUJKt9bqsQx/Y81qYkj8pvoXw0oB6 lEDg== Received: by 10.68.228.132 with SMTP id si4mr23015051pbc.86.1337884304392; Thu, 24 May 2012 11:31:44 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id x1sm6219496pbp.50.2012.05.24.11.31.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 11:31:43 -0700 (PDT) Message-ID: <4FBE7E8D.5030802@gmail.com> Date: Thu, 24 May 2012 10:31:41 -0800 From: Melinda Shore User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7D72.4050205@gmail.com> <4FBE7E04.6080505@stpeter.im> In-Reply-To: <4FBE7E04.6080505@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:31:45 -0000 Peter Saint-Andre wrote: > Inter Domain Identity Operation Tools is catchy. Okay, that one I can live with. Melinda From lear@cisco.com Thu May 24 11:35:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7111E80A4; Thu, 24 May 2012 11:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.832 X-Spam-Level: X-Spam-Status: No, score=-110.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzJgYLBgfasc; Thu, 24 May 2012 11:35:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD111E80AF; Thu, 24 May 2012 11:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2784; q=dns/txt; s=iport; t=1337884521; x=1339094121; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dmdAhKEjcg99R7mk2qBJCiVszOmF9C4uCkxJAD16gmY=; b=OSw1cZ7ji2ZAzaMouzhaZwayxjmTdPXbTDChuhfwfbCPmjR6s6W6N4cr j9JXgF3bi/VDTNjXS3NsoHR7dslx+21s7xOJDWRCgVFIOLpTK9u5yYX/S tH5qkHksl1naq1UD1WCrmGW92oEte3KGypa2cvWxmDvQBlVB1Coe0d35B Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAZ/vk+tJV2a/2dsb2JhbAA6CYUxrzSBB4IVAQEBBAEBAQ8BEEQHCgEQCxgCAgUWCwICCQMCAQIBFTAGDQEFAgEBEAYIh2sLm0qNFJJqBIEkiWyDfYESA5UYjgyBZIJs X-IronPort-AV: E=Sophos;i="4.75,652,1330905600"; d="scan'208";a="86435045" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 24 May 2012 18:35:21 +0000 Received: from rtp-vpn6-1950.cisco.com (rtp-vpn6-1950.cisco.com [10.82.255.165]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4OIZITB013132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 18:35:20 GMT Message-ID: <4FBE7F66.4030500@cisco.com> Date: Thu, 24 May 2012 20:35:18 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:35:22 -0000 Barry, I'm sorry but arguing over a name is not something that should be done by the IESG. It impacts the wire not one little bit, and it's disrespectful to those who brought the work into the IETF. It also wastes the time of many people diverting them from what I'm sure we'd all prefer them to work on- things that DO effect the wire. Honestly, can't we PLEASE move along? Eliot On 5/24/12 8:15 PM, Barry Leiba wrote: > I have good news and bad news from the IESG telechat today. > > The good news is that the IESG is happy with the charter. The only > change they asked for was a one-word addition to make it clear that > "authorization" will also be included in the security bit: > > OLD > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authenticity and privacy. > > NEW > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authorization, authenticity, and privacy. > > > The bad news is on the name, "SCIM": that dog will not hunt. It's not > just Pete, who fought it on this list: at least three other ADs want > the name changed before we can approve the charter for external > review. > > The IESG is working on an alternative name -- one that was suggested > was "Inter-Domain User Identity Management", giving a working group > acronym of "iduim". > > This group can, of course, propose other names... in the end, the IESG > will pick the name, though it would be nice to have agreement from the > community. But here's the thing: > - Give up on "simple". There've been too many protocols with that in > the name, and none of them are. > - Give up on "cloud". This will certainly be used by cloud providers, > but is not specific to that use, and the name "cloud" carries too much > baggage and too many other assumptions. > - "Identity management" by itself is a broader topic than what we're > talking about here. "User identity management" might work (see the > suggestion above), as might other formulations you may come up with. > > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > From phil.hunt@oracle.com Thu May 24 11:38:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7818D11E80AF for ; Thu, 24 May 2012 11:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2csG9M5XPO91 for ; Thu, 24 May 2012 11:38:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB1D11E8076 for ; Thu, 24 May 2012 11:38:08 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4OIc4oE007231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 18:38:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4OIc3p1018299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 18:38:04 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4OIc3xY016261; Thu, 24 May 2012 13:38:03 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 May 2012 11:38:03 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4FBE7E8D.5030802@gmail.com> Date: Thu, 24 May 2012 11:38:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4F43627F-03A3-4E05-B883-F6995E877D4C@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7D72.4050205@gmail.com> <4FBE7E04.6080505@stpeter.im> <4FBE7E8D.5030802@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim@ietf.org, Barry Leiba , Peter Saint-Andre Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:38:09 -0000 Peter, You are joking yes? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-24, at 11:31 AM, Melinda Shore wrote: > Peter Saint-Andre wrote: >> Inter Domain Identity Operation Tools is catchy. > > Okay, that one I can live with. > > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Thu May 24 11:56:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA621F850B for ; Thu, 24 May 2012 11:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgZ7WrxRCoJK for ; Thu, 24 May 2012 11:56:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9B95511E8076 for ; Thu, 24 May 2012 11:56:37 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A2DD640067; Thu, 24 May 2012 13:12:45 -0600 (MDT) Message-ID: <4FBE8461.5090706@stpeter.im> Date: Thu, 24 May 2012 12:56:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phil Hunt References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7D72.4050205@gmail.com> <4FBE7E04.6080505@stpeter.im> <4FBE7E8D.5030802@gmail.com> <4F43627F-03A3-4E05-B883-F6995E877D4C@oracle.com> In-Reply-To: <4F43627F-03A3-4E05-B883-F6995E877D4C@oracle.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Melinda Shore , Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:56:38 -0000 On 5/24/12 12:38 PM, Phil Hunt wrote: > You are joking yes? Just trying to inject a little levity. From michael.brenner@alcatel-lucent.com Thu May 24 12:08:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8792C11E80C5; Thu, 24 May 2012 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geYXZw4douwJ; Thu, 24 May 2012 12:08:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5911E80C1; Thu, 24 May 2012 12:08:02 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4OJ7vxP005321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 14:07:57 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4OJ7uSY020715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 May 2012 14:07:56 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 24 May 2012 14:07:56 -0500 From: "Brenner, Michael Ralf (Michael)" To: Eliot Lear , Barry Leiba Date: Thu, 24 May 2012 14:07:53 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac052/vZAmN+72CHRzKbZjbKLbRTKgABIFSQ Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> In-Reply-To: <4FBE7F66.4030500@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "scim@ietf.org" , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:08:03 -0000 Why can't we keep SCIM and have it stand for Schema for Cross-domain Identi= ty Management? Michael -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eli= ot Lear Sent: Thursday, May 24, 2012 2:35 PM To: Barry Leiba Cc: scim@ietf.org; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB Barry, I'm sorry but arguing over a name is not something that should be done by the IESG. It impacts the wire not one little bit, and it's disrespectful to those who brought the work into the IETF. It also wastes the time of many people diverting them from what I'm sure we'd all prefer them to work on- things that DO effect the wire. Honestly, can't we PLEASE move along? Eliot On 5/24/12 8:15 PM, Barry Leiba wrote: > I have good news and bad news from the IESG telechat today. > > The good news is that the IESG is happy with the charter. The only > change they asked for was a one-word addition to make it clear that > "authorization" will also be included in the security bit: > > OLD > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authenticity and privacy. > > NEW > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authorization, authenticity, and privacy. > > > The bad news is on the name, "SCIM": that dog will not hunt. It's not > just Pete, who fought it on this list: at least three other ADs want > the name changed before we can approve the charter for external > review. > > The IESG is working on an alternative name -- one that was suggested > was "Inter-Domain User Identity Management", giving a working group > acronym of "iduim". > > This group can, of course, propose other names... in the end, the IESG > will pick the name, though it would be nice to have agreement from the > community. But here's the thing: > - Give up on "simple". There've been too many protocols with that in > the name, and none of them are. > - Give up on "cloud". This will certainly be used by cloud providers, > but is not specific to that use, and the name "cloud" carries too much > baggage and too many other assumptions. > - "Identity management" by itself is a broader topic than what we're > talking about here. "User identity management" might work (see the > suggestion above), as might other formulations you may come up with. > > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From alan.sill@ttu.edu Thu May 24 12:12:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CCC11E80C5; Thu, 24 May 2012 12:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMCDRgYqlCTJ; Thu, 24 May 2012 12:12:08 -0700 (PDT) Received: from eurynome.ttu.edu (eurynome.ttu.edu [129.118.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22311E80C1; Thu, 24 May 2012 12:12:08 -0700 (PDT) Received: from hippolytus.net.ttu.edu (129.118.1.212) by mxout2.ttu.edu (129.118.1.79) with Microsoft SMTP Server id 8.3.245.1; Thu, 24 May 2012 14:12:05 -0500 Received: from [129.118.230.27] (129.118.230.27) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 14:12:04 -0500 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: Alan Sill In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Thu, 24 May 2012 14:12:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> To: "Brenner, Michael Ralf (Michael)" X-Mailer: Apple Mail (2.1278) Received-SPF: Pass (eurynome.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurynome.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: "scim@ietf.org" , Barry Leiba , Eliot Lear , Alan Sill , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:12:09 -0000 +1 Alan On May 24, 2012, at 2:07 PM, Brenner, Michael Ralf (Michael) wrote: > Why can't we keep SCIM and have it stand for Schema for Cross-domain = Identity Management? From barryleiba.mailing.lists@gmail.com Thu May 24 12:18:14 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF52111E8081 for ; Thu, 24 May 2012 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvTBBdrRkYZP for ; Thu, 24 May 2012 12:18:14 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 269BF11E8076 for ; Thu, 24 May 2012 12:18:13 -0700 (PDT) Received: by lagv3 with SMTP id v3so106186lag.31 for ; Thu, 24 May 2012 12:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=KXafQr+Sdz6o2mJEtHNANEh/7JB1CWU4qKCCO+hHlSI=; b=IRN/HcNpC0qPr3cOkLE26TwZmd8me+98o5z77Epz/tZyBRo8NIIHMpaSPSoJ82AuV1 vbcffQd7kifeIkN4+uoXQiD3ng/Vu8upzI2MXehTCcZ0uelCxyqUatP0iubKH2Fee2Eq YRDDaTUbAgIzc9uxZnbATOGdQ0A39GORni8vQokSjVU2JEQr1LnS5i1LU5eQjC3fsWbD Bq8Fi4AgM+RjdowvTC/v03RWEw1kOqDH/KuDPzEk62OObq6a0g+Pr5/t9Qkv61xwNvRe zzPcJ5hLiQTz4bT2swRIZoiNn6p4TWGnH6U8W1JqO8k9Hc211DE84G+5OSrDN6I0UIGm E54g== MIME-Version: 1.0 Received: by 10.112.36.130 with SMTP id q2mr256481lbj.44.1337887092945; Thu, 24 May 2012 12:18:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 24 May 2012 12:18:12 -0700 (PDT) In-Reply-To: <4FBE8461.5090706@stpeter.im> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7D72.4050205@gmail.com> <4FBE7E04.6080505@stpeter.im> <4FBE7E8D.5030802@gmail.com> <4F43627F-03A3-4E05-B883-F6995E877D4C@oracle.com> <4FBE8461.5090706@stpeter.im> Date: Thu, 24 May 2012 15:18:12 -0400 X-Google-Sender-Auth: 7rH9SbZRvFKEVwKL7W0wVVFd7dM Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:18:15 -0000 >>> Inter Domain Identity Operation Tools is catchy. >> >> You are joking yes? > > Just trying to inject a little levity. I will point out that in the discussions that eventually led to MARF, the Mail Abuse Reporting Format WG, one suggestion had been "Basic Abuse Reporting Format". b From tonynad@microsoft.com Thu May 24 12:19:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9D11E8081 for ; Thu, 24 May 2012 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3xBrkj1-r2S for ; Thu, 24 May 2012 12:19:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9EED111E8076 for ; Thu, 24 May 2012 12:19:31 -0700 (PDT) Received: from mail16-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 19:19:21 +0000 Received: from mail16-tx2 (localhost [127.0.0.1]) by mail16-tx2-R.bigfish.com (Postfix) with ESMTP id 04883E01D4 for ; Thu, 24 May 2012 19:19:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz9371I542Mzz1202h1082kzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail16-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail16-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2 (MessageSwitch) id 1337887159825571_10836; Thu, 24 May 2012 19:19:19 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.252]) by mail16-tx2.bigfish.com (Postfix) with ESMTP id BCD933E0048 for ; Thu, 24 May 2012 19:19:19 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 19:19:19 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 24 May 2012 19:19:27 +0000 Received: from mail154-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 19:18:23 +0000 Received: from mail154-tx2 (localhost [127.0.0.1]) by mail154-tx2-R.bigfish.com (Postfix) with ESMTP id 87378360080 for ; Thu, 24 May 2012 19:18:23 +0000 (UTC) Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2 (MessageSwitch) id 1337887101342622_4429; Thu, 24 May 2012 19:18:21 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.239]) by mail154-tx2.bigfish.com (Postfix) with ESMTP id 4FE71140047; Thu, 24 May 2012 19:18:21 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 19:18:21 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.68]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0152.000; Thu, 24 May 2012 19:18:25 +0000 From: Anthony Nadalin To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33aF74auKfay0mp132k/m2sUpbI7JkAgABgegCAAJA0AIAAMrkAgAD02gCAAocugIAAjNMAgAB3F4CACsN6gIAADwEg Date: Thu, 24 May 2012 19:18:25 +0000 Message-ID: References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:19:32 -0000 MIROR - Management of Identities and identity-Related Objects across admini= strative Realms -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Thursday, May 24, 2012 11:16 AM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB I have good news and bad news from the IESG telechat today. The good news is that the IESG is happy with the charter. The only change = they asked for was a one-word addition to make it clear that "authorization= " will also be included in the security bit: OLD In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues | around authenticity and privacy. NEW In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues | around authorization, authenticity, and privacy. The bad news is on the name, "SCIM": that dog will not hunt. It's not just= Pete, who fought it on this list: at least three other ADs want the name c= hanged before we can approve the charter for external review. The IESG is working on an alternative name -- one that was suggested was "I= nter-Domain User Identity Management", giving a working group acronym of "i= duim". This group can, of course, propose other names... in the end, the IESG will= pick the name, though it would be nice to have agreement from the communit= y. But here's the thing: - Give up on "simple". There've been too many protocols with that in the n= ame, and none of them are. - Give up on "cloud". This will certainly be used by cloud providers, but = is not specific to that use, and the name "cloud" carries too much baggage = and too many other assumptions. - "Identity management" by itself is a broader topic than what we're talkin= g about here. "User identity management" might work (see the suggestion ab= ove), as might other formulations you may come up with. Barry _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From lear@cisco.com Thu May 24 12:25:12 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311B511E8076; Thu, 24 May 2012 12:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.774 X-Spam-Level: X-Spam-Status: No, score=-110.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRcfksHRq9bl; Thu, 24 May 2012 12:25:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6021F84A6; Thu, 24 May 2012 12:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=260; q=dns/txt; s=iport; t=1337887510; x=1339097110; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BrP3uBpxVq/TV5kKLYLSGpw+5JdtgG+3S9ceKRWCsfM=; b=J1YVtGssbh9OOWgFBqSsdH3SqQsAwLmScX6vQJ+TbKjwSXBJlPPrJfeg VzmoPQoix+u+QmtYip3BZAequICSc38xhqCEqdBDwrCPMUcYtUQlgd4qo Iy7mI2Yrf+NbkPVjX+GZX7rx9CX5lc/+yw6eNiCI7ho1bT0FiizHjjeyh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQHADSKvk+tJV2d/2dsb2JhbAA6CQ6FI4dDp3GBB4IVAQEBBBIBEFUBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQEeh2ubWI0UknGBJIlbEYN9gRIDlRiODIFkgjE7 X-IronPort-AV: E=Sophos;i="4.75,652,1330905600"; d="scan'208";a="86219319" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 24 May 2012 19:25:09 +0000 Received: from rtp-vpn6-1950.cisco.com (rtp-vpn6-1950.cisco.com [10.82.255.165]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q4OJP6o1022524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 19:25:08 GMT Message-ID: <4FBE8B12.3080205@cisco.com> Date: Thu, 24 May 2012 21:25:06 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alan Sill References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> In-Reply-To: <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Brenner, Michael Ralf \(Michael\)" , "scim@ietf.org" , Barry Leiba , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:25:12 -0000 +1 if it moves us along! On 5/24/12 9:12 PM, Alan Sill wrote: > +1 > > Alan > > On May 24, 2012, at 2:07 PM, Brenner, Michael Ralf (Michael) wrote: > >> Why can't we keep SCIM and have it stand for Schema for Cross-domain Identity Management? > > From michael.brenner@alcatel-lucent.com Thu May 24 12:30:25 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776B11E8076; Thu, 24 May 2012 12:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzE6oKrItBRj; Thu, 24 May 2012 12:30:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6D11E8074; Thu, 24 May 2012 12:30:24 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4OJUKu1020259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 14:30:20 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4OJUJdO018844 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 May 2012 14:30:19 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 24 May 2012 14:30:19 -0500 From: "Brenner, Michael Ralf (Michael)" To: Eliot Lear , Alan Sill Date: Thu, 24 May 2012 14:30:19 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac054vANjU4yaTmCRUGfqvcj7ZuGBgAAJX8g Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> In-Reply-To: <4FBE8B12.3080205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "scim@ietf.org" , Barry Leiba , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:30:25 -0000 V2h5IHdvdWxkIGl0IG5vdD8gSSB1bmRlcnN0YW5kIHRoZSBvcHBvc2l0aW9uIGNhbWUgZnJvbSB0 aGUgInNpbXBsZSIgYW5kICJjbG91ZCIsIHdoaWNoIHdpdGggdGhpcyBwcm9wb3NhbCBhcmUgbm8g bG9uZ2VyIHBhcnQgb2YgdGhlIGFjcm9ueW0uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dIA0KU2VudDogVGh1cnNk YXksIE1heSAyNCwgMjAxMiAzOjI1IFBNDQpUbzogQWxhbiBTaWxsDQpDYzogQnJlbm5lciwgTWlj aGFlbCBSYWxmIChNaWNoYWVsKTsgQmFycnkgTGVpYmE7IHNjaW1AaWV0Zi5vcmc7ICdJRVNHJw0K U3ViamVjdDogUmU6IFtzY2ltXSBGZWVkYmFjayBvbiB0aGUgY2hhcnRlciBmcm9tIElFU0cgYW5k IElBQg0KDQorMSBpZiBpdCBtb3ZlcyB1cyBhbG9uZyENCg0KT24gNS8yNC8xMiA5OjEyIFBNLCBB bGFuIFNpbGwgd3JvdGU6DQo+ICsxDQo+DQo+IEFsYW4NCj4NCj4gT24gTWF5IDI0LCAyMDEyLCBh dCAyOjA3IFBNLCBCcmVubmVyLCBNaWNoYWVsIFJhbGYgKE1pY2hhZWwpIHdyb3RlOg0KPg0KPj4g V2h5IGNhbid0IHdlIGtlZXAgU0NJTSBhbmQgaGF2ZSBpdCBzdGFuZCBmb3IgU2NoZW1hIGZvciBD cm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudD8NCj4NCj4NCg== From kelly.grizzle@sailpoint.com Thu May 24 12:33:50 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FA821F84D6; Thu, 24 May 2012 12:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oiTbnfKc-Ud; Thu, 24 May 2012 12:33:50 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3711E8086; Thu, 24 May 2012 12:33:50 -0700 (PDT) Received: from mail99-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 May 2012 19:33:40 +0000 Received: from mail99-tx2 (localhost [127.0.0.1]) by mail99-tx2-R.bigfish.com (Postfix) with ESMTP id 76A4B4C0199; Thu, 24 May 2012 19:33:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0411HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: PS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail99-tx2: domain of sailpoint.com designates 157.56.245.181 as permitted sender) client-ip=157.56.245.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0411HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2 (MessageSwitch) id 1337888018170433_14510; Thu, 24 May 2012 19:33:38 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.237]) by mail99-tx2.bigfish.com (Postfix) with ESMTP id 1D41F180048; Thu, 24 May 2012 19:33:38 +0000 (UTC) Received: from CH1PRD0411HT004.namprd04.prod.outlook.com (157.56.245.181) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 May 2012 19:33:37 +0000 Received: from CH1PRD0411MB407.namprd04.prod.outlook.com ([169.254.8.194]) by CH1PRD0411HT004.namprd04.prod.outlook.com ([10.255.158.39]) with mapi id 14.16.0143.004; Thu, 24 May 2012 19:33:45 +0000 From: Kelly Grizzle To: "Brenner, Michael Ralf (Michael)" , Eliot Lear , Alan Sill Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33HX/k3k5Flb0qGWMZ8dW6jIZbI7JkAgABgegCAAJA0AIAAMrkAgAD02gCAAocvgIAAjNIAgAB3F4CACsN6gIAABYcAgAAJG4CAAAEqgIAAA6UAgAABdYCAAABRoA== Date: Thu, 24 May 2012 19:33:45 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Barry Leiba , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:33:51 -0000 -1 for "Schema". The SCIM spec currently contains a schema and a protocol = (ie - the REST API). Using "schema" in the name seems to imply that the on= ly concern is with the schema. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bre= nner, Michael Ralf (Michael) Sent: Thursday, May 24, 2012 2:30 PM To: Eliot Lear; Alan Sill Cc: scim@ietf.org; Barry Leiba; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB Why would it not? I understand the opposition came from the "simple" and "c= loud", which with this proposal are no longer part of the acronym. -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com]=20 Sent: Thursday, May 24, 2012 3:25 PM To: Alan Sill Cc: Brenner, Michael Ralf (Michael); Barry Leiba; scim@ietf.org; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB +1 if it moves us along! On 5/24/12 9:12 PM, Alan Sill wrote: > +1 > > Alan > > On May 24, 2012, at 2:07 PM, Brenner, Michael Ralf (Michael) wrote: > >> Why can't we keep SCIM and have it stand for Schema for Cross-domain Ide= ntity Management? > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From michael.brenner@alcatel-lucent.com Thu May 24 12:45:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9831811E8086; Thu, 24 May 2012 12:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOy5wUhLHQN9; Thu, 24 May 2012 12:45:38 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 08CB121F84EA; Thu, 24 May 2012 12:45:37 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4OJjXet000508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 14:45:33 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4OJjWq5026045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 May 2012 14:45:32 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 24 May 2012 14:45:32 -0500 From: "Brenner, Michael Ralf (Michael)" To: Kelly Grizzle , Eliot Lear , Alan Sill Date: Thu, 24 May 2012 14:45:31 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33HX/k3k5Flb0qGWMZ8dW6jIZbI7JkAgABgegCAAJA0AIAAMrkAgAD02gCAAocvgIAAjNIAgAB3F4CACsN6gIAABYcAgAAJG4CAAAEqgIAAA6UAgAABdYCAAABRoIAAAr7Q Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "scim@ietf.org" , Barry Leiba , 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:45:38 -0000 Maybe we can convince IESG to get over the "Simple" if we drop the "cloud" = (Simple Cross-domain Identity Management), if we are keen on keeping SCIM. -----Original Message----- From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 Sent: Thursday, May 24, 2012 3:34 PM To: Brenner, Michael Ralf (Michael); Eliot Lear; Alan Sill Cc: scim@ietf.org; Barry Leiba; 'IESG' Subject: RE: [scim] Feedback on the charter from IESG and IAB -1 for "Schema". The SCIM spec currently contains a schema and a protocol = (ie - the REST API). Using "schema" in the name seems to imply that the on= ly concern is with the schema. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bre= nner, Michael Ralf (Michael) Sent: Thursday, May 24, 2012 2:30 PM To: Eliot Lear; Alan Sill Cc: scim@ietf.org; Barry Leiba; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB Why would it not? I understand the opposition came from the "simple" and "c= loud", which with this proposal are no longer part of the acronym. -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com]=20 Sent: Thursday, May 24, 2012 3:25 PM To: Alan Sill Cc: Brenner, Michael Ralf (Michael); Barry Leiba; scim@ietf.org; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB +1 if it moves us along! On 5/24/12 9:12 PM, Alan Sill wrote: > +1 > > Alan > > On May 24, 2012, at 2:07 PM, Brenner, Michael Ralf (Michael) wrote: > >> Why can't we keep SCIM and have it stand for Schema for Cross-domain Ide= ntity Management? > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From alan.sill@ttu.edu Thu May 24 13:18:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234C11E80A3; Thu, 24 May 2012 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz0LqspQ56CE; Thu, 24 May 2012 13:18:02 -0700 (PDT) Received: from eurynome.ttu.edu (eurynome.ttu.edu [129.118.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2D11E8097; Thu, 24 May 2012 13:18:01 -0700 (PDT) Received: from hippolytus.net.ttu.edu (129.118.1.212) by mxout2.ttu.edu (129.118.1.79) with Microsoft SMTP Server id 8.3.245.1; Thu, 24 May 2012 15:18:01 -0500 Received: from alan-sills-mini.ttu.edu (129.118.90.225) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 15:18:00 -0500 Message-ID: <117F088D-8453-4846-A444-4623926C016A@ttu.edu> From: Alan Sill To: "Brenner, Michael Ralf (Michael)" In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 May 2012 15:17:56 -0500 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) Received-SPF: Pass (eurynome.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurynome.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: Eliot Lear , "scim@ietf.org" , 'IESG' , Alan Sill , Kelly Grizzle , Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:18:02 -0000 That would be OK, too. Alan On May 24, 2012, at 2:45 PM, Brenner, Michael Ralf (Michael) wrote: > Maybe we can convince IESG to get over the "Simple" if we drop the > "cloud" (Simple Cross-domain Identity Management), if we are keen on > keeping SCIM. From michael.brenner@alcatel-lucent.com Thu May 24 13:20:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A059111E809D for ; Thu, 24 May 2012 13:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evP+Fp2ps2qU for ; Thu, 24 May 2012 13:20:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAA211E8086 for ; Thu, 24 May 2012 13:20:54 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4OKKpkB023537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 15:20:52 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4OKKp0J016338 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 May 2012 15:20:51 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 24 May 2012 15:20:51 -0500 From: "Brenner, Michael Ralf (Michael)" To: Alan Sill Date: Thu, 24 May 2012 15:20:50 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac056lN3l76AfXCLSSuGNRb5crcPnQAADfmw Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <117F088D-8453-4846-A444-4623926C016A@ttu.edu> In-Reply-To: <117F088D-8453-4846-A444-4623926C016A@ttu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "scim@ietf.org" , Barry Leiba , Eliot Lear , Kelly Grizzle Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:20:57 -0000 Secure Cross-domain Identity Management may get us past this hurdle... -----Original Message----- From: Alan Sill [mailto:alan.sill@ttu.edu]=20 Sent: Thursday, May 24, 2012 4:18 PM To: Brenner, Michael Ralf (Michael) Cc: Alan Sill; Kelly Grizzle; Eliot Lear; scim@ietf.org; Barry Leiba; 'IESG= ' Subject: Re: [scim] Feedback on the charter from IESG and IAB That would be OK, too. Alan On May 24, 2012, at 2:45 PM, Brenner, Michael Ralf (Michael) wrote: > Maybe we can convince IESG to get over the "Simple" if we drop the =20 > "cloud" (Simple Cross-domain Identity Management), if we are keen on =20 > keeping SCIM. From stpeter@stpeter.im Thu May 24 13:25:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAE021F844A for ; Thu, 24 May 2012 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40cxnHVBdpeV for ; Thu, 24 May 2012 13:25:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B421F8475 for ; Thu, 24 May 2012 13:24:58 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 733DD4005A; Thu, 24 May 2012 14:41:01 -0600 (MDT) Message-ID: <4FBE9912.3000805@stpeter.im> Date: Thu, 24 May 2012 14:24:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Brenner, Michael Ralf (Michael)" References: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <117F088D-8453-4846-A444-4623926C016A@ttu.edu> <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Barry Leiba , Eliot Lear , Alan Sill , Kelly Grizzle Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:25:08 -0000 On 5/24/12 2:20 PM, Brenner, Michael Ralf (Michael) wrote: > Secure Cross-domain Identity Management may get us past this hurdle... WFM. [1] /psa [1] But not necessarily for others. No matter what you come up with, someone will complain... "Secure?! You're just asserting that it's secure?!" "Domain?! But this isn't about DNS!" "Identity?! Don't you know that's a hopeless vague term?" "Management?! You're not actually managing this information!" From michael.brenner@alcatel-lucent.com Thu May 24 13:35:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7F811E810C for ; Thu, 24 May 2012 13:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biE6jppX4Y9f for ; Thu, 24 May 2012 13:35:32 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3011E80FE for ; Thu, 24 May 2012 13:35:31 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4OKZTC7028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 May 2012 15:35:29 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4OKZS88030570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 May 2012 15:35:28 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 24 May 2012 15:35:28 -0500 From: "Brenner, Michael Ralf (Michael)" To: Peter Saint-Andre Date: Thu, 24 May 2012 15:35:27 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac0561HGO6mj3mq3TruXOCHxfU/iAwAAOnhA Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6ABBC6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <117F088D-8453-4846-A444-4623926C016A@ttu.edu> <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FBE9912.3000805@stpeter.im> In-Reply-To: <4FBE9912.3000805@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "scim@ietf.org" , Barry Leiba , Alan Sill , Eliot Lear , Kelly Grizzle Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:35:32 -0000 If no name would be irefutable, (levity says) we should call it UPS (Un-nam= ed Protocol and Schema). -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Thursday, May 24, 2012 4:25 PM To: Brenner, Michael Ralf (Michael) Cc: scim@ietf.org; Barry Leiba; Eliot Lear; Alan Sill; Kelly Grizzle Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/24/12 2:20 PM, Brenner, Michael Ralf (Michael) wrote: > Secure Cross-domain Identity Management may get us past this hurdle... WFM. [1] /psa [1] But not necessarily for others. No matter what you come up with, someone will complain... "Secure?! You're just asserting that it's secure?!" "Domain?! But this isn't about DNS!" "Identity?! Don't you know that's a hopeless vague term?" "Management?! You're not actually managing this information!" _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Thu May 24 13:35:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2637811E8102 for ; Thu, 24 May 2012 13:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cka3HOPvwejH for ; Thu, 24 May 2012 13:35:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0BB311E80FE for ; Thu, 24 May 2012 13:35:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so251486dac.31 for ; Thu, 24 May 2012 13:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0IJaxUQ1uOQomETtSrvQqVdIxD6TUVan+6o3TIDN368=; b=aovRdI6Qtsxpxo/wdhacVunIaM7+xVDPWhrDEavR11oXHkd572gs3U/Zk+TH/8MU9W jfoU0t2A8dgwPypkBTcYWIf2blnXVlapvvQqjiTP3yUuSLzBoaOpNJVp5730tWfjv5rm X6IavNvV5DBnDknk8E8x5soZGO570sY2/aUlJnNrbDfhdv8DhRJHDdk5VP7ezeJ0eLNq cW/30q0K9uDMa+yHkn8MwUGX5InD3BSUs8xD5thq/TnXNQLO+VnzT9hpT46wW1RzXgUN gq4IjwiiUb6eS9HZizCaADYv5VFrRD1UxNa7duHif51S4dmSpfDqz9FkFXyGhwQOqa7j I98g== Received: by 10.68.226.228 with SMTP id rv4mr13050205pbc.167.1337891744521; Thu, 24 May 2012 13:35:44 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id wi8sm6527825pbc.11.2012.05.24.13.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 13:35:44 -0700 (PDT) Message-ID: <4FBE9B9E.40401@gmail.com> Date: Thu, 24 May 2012 12:35:42 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <117F088D-8453-4846-A444-4623926C016A@ttu.edu> <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:35:45 -0000 On 5/24/12 12:20 PM, Brenner, Michael Ralf (Michael) wrote: > Secure Cross-domain Identity Management may get us past this hurdle... I think "secure" is going to run into virtually identical objections to the ones raised concerning "simple." And for whatever it's worth, the group really has been pretty hand-wavey about security and I'm pretty sure "secure" would not be particularly descriptive of the group's priorities. I think it's best to find something descriptive, propose that, and move forward. Melinda From alan.sill@ttu.edu Thu May 24 13:48:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4E11E80C0 for ; Thu, 24 May 2012 13:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBhJShA2LbFW for ; Thu, 24 May 2012 13:48:53 -0700 (PDT) Received: from eurynomus.ttu.edu (eurynomus.ttu.edu [129.118.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3559C11E8096 for ; Thu, 24 May 2012 13:48:53 -0700 (PDT) Received: from hippolytus.net.ttu.edu (129.118.1.212) by mxout3.ttu.edu (129.118.1.201) with Microsoft SMTP Server id 8.3.213.0; Thu, 24 May 2012 15:48:52 -0500 Received: from 6520-274734.ttu.edu (129.118.90.77) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 15:48:52 -0500 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: Alan Sill In-Reply-To: <4FBE9B9E.40401@gmail.com> Date: Thu, 24 May 2012 15:48:49 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <873BC641-3704-4AE6-B35E-3790110D9F5E@ttu.edu> References: <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0360065A-724E-49A1-B0E7-6D8C2002BE77@ttu.edu> <4FBE8B12.3080205@cisco.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB50@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C343722AA173B@CH1PRD0411MB407.namprd04.prod.outlook.com> <219947F0B2242843A0A1E62FDB510DC026CE6ABB70@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <117F088D-8453-4846-A444-4623926C016A@ttu.edu> <219947F0B2242843A0A1E62FDB510DC026CE6ABBAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4FBE9B9E.40401@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1278) Received-SPF: Pass (eurynomus.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurynomus.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: "scim@ietf.org" , Alan Sill Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:48:54 -0000 Earlier on, I suggested "SChemas for Identity Management Attributes" = (SCIMA) and that went over like a lead balloon! ;-) Schema and protocol for Cross-domain Identity Management attributes =3D = SCIM if you want to suppress some initials Identity Attributes Interchange Protocol =3D IAIP if you give up the = SCIM name Cross-domain Identity Management Attribute Protocol and Schema =3D CIMAP ... Alan On May 24, 2012, at 3:35 PM, Melinda Shore wrote: > On 5/24/12 12:20 PM, Brenner, Michael Ralf (Michael) wrote: >> Secure Cross-domain Identity Management may get us past this = hurdle... >=20 > I think "secure" is going to run into virtually identical > objections to the ones raised concerning "simple." And for > whatever it's worth, the group really has been pretty > hand-wavey about security and I'm pretty sure "secure" > would not be particularly descriptive of the group's > priorities. >=20 > I think it's best to find something descriptive, propose > that, and move forward. >=20 > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From likepeng@huawei.com Thu May 24 17:39:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8BC11E8081 for ; Thu, 24 May 2012 17:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiU-UmcqSH5j for ; Thu, 24 May 2012 17:39:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE811E80A3 for ; Thu, 24 May 2012 17:39:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF90287; Thu, 24 May 2012 20:39:29 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 17:37:37 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 17:37:42 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.207]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Fri, 25 May 2012 08:37:36 +0800 From: Likepeng To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33GpvhXiCZqykCXOsWD/wrUtJbIZn0AgABgeQCAAJA1AIAAMrgAgAD02wCAAocugIAAjNIAgAB3GICACsN6gIAA79oQ Date: Fri, 25 May 2012 00:37:35 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:39:30 -0000 PlRoZSBJRVNHIGlzIHdvcmtpbmcgb24gYW4gYWx0ZXJuYXRpdmUgbmFtZSAtLSBvbmUgdGhhdCB3 YXMgc3VnZ2VzdGVkDQp3YXMgIkludGVyLURvbWFpbiBVc2VyIElkZW50aXR5IE1hbmFnZW1lbnQi LCBnaXZpbmcgYSB3b3JraW5nIGdyb3VwDQphY3JvbnltIG9mICJpZHVpbSIuDQoNCkkgbGlrZSB0 aGlzIG9uZS4gDQoNClRoZSBlYXNpZXIgd2F5IGZvciB1cyBpcyB0byBhZ3JlZSB3aXRoIHRoZSBJ RVNHIHByb3Bvc2FsLCBhbmQgd2UgY2FuIG1vdmUgb24uDQoNClRoYW5rcywNCktpbmQgUmVnYXJk cw0KS2VwZW5nDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2NpbS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJhcnJ5IExlaWJhDQq3osvN yrG85DogMjAxMsTqNdTCMjXI1SAyOjE2DQrK1bz+yMs6IHNjaW1AaWV0Zi5vcmcNCtb3zOI6IFJl OiBbc2NpbV0gRmVlZGJhY2sgb24gdGhlIGNoYXJ0ZXIgZnJvbSBJRVNHIGFuZCBJQUINCg0KSSBo YXZlIGdvb2QgbmV3cyBhbmQgYmFkIG5ld3MgZnJvbSB0aGUgSUVTRyB0ZWxlY2hhdCB0b2RheS4N Cg0KVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHRoZSBJRVNHIGlzIGhhcHB5IHdpdGggdGhlIGNoYXJ0 ZXIuICBUaGUgb25seQ0KY2hhbmdlIHRoZXkgYXNrZWQgZm9yIHdhcyBhIG9uZS13b3JkIGFkZGl0 aW9uIHRvIG1ha2UgaXQgY2xlYXIgdGhhdA0KImF1dGhvcml6YXRpb24iIHdpbGwgYWxzbyBiZSBp bmNsdWRlZCBpbiB0aGUgc2VjdXJpdHkgYml0Og0KDQpPTEQNCiAgSW4gYWRkaXRpb24sIHRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgZW5zdXJlIHRoYXQgdGhlIFNDSU0gcHJvdG9jb2wNCiAgZW1ib2Rp ZXMgZ29vZCBzZWN1cml0eSBwcmFjdGljZXMuIEdpdmVuIGJvdGggdGhlIHNlbnNpdGl2aXR5IG9m IHRoZQ0KICBpbmZvcm1hdGlvbiBiZWluZyBjb252ZXllZCBpbiBTQ0lNIG1lc3NhZ2VzIGFuZCB0 aGUgcmVndWxhdG9yeQ0KICByZXF1aXJlbWVudHMgcmVnYXJkaW5nIHRoZSBwcml2YWN5IG9mIHBl cnNvbmFsbHkgaWRlbnRpZmlhYmxlDQogIGluZm9ybWF0aW9uLCB0aGUgd29ya2luZyBncm91cCB3 aWxsIHBheSBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0byBpc3N1ZXMNCnwgYXJvdW5kIGF1dGhlbnRp Y2l0eSBhbmQgcHJpdmFjeS4NCg0KTkVXDQogIEluIGFkZGl0aW9uLCB0aGUgd29ya2luZyBncm91 cCB3aWxsIGVuc3VyZSB0aGF0IHRoZSBTQ0lNIHByb3RvY29sDQogIGVtYm9kaWVzIGdvb2Qgc2Vj dXJpdHkgcHJhY3RpY2VzLiBHaXZlbiBib3RoIHRoZSBzZW5zaXRpdml0eSBvZiB0aGUNCiAgaW5m b3JtYXRpb24gYmVpbmcgY29udmV5ZWQgaW4gU0NJTSBtZXNzYWdlcyBhbmQgdGhlIHJlZ3VsYXRv cnkNCiAgcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyB0aGUgcHJpdmFjeSBvZiBwZXJzb25hbGx5IGlk ZW50aWZpYWJsZQ0KICBpbmZvcm1hdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwYXkgcGFy dGljdWxhciBhdHRlbnRpb24gdG8gaXNzdWVzDQp8IGFyb3VuZCBhdXRob3JpemF0aW9uLCBhdXRo ZW50aWNpdHksIGFuZCBwcml2YWN5Lg0KDQoNClRoZSBiYWQgbmV3cyBpcyBvbiB0aGUgbmFtZSwg IlNDSU0iOiB0aGF0IGRvZyB3aWxsIG5vdCBodW50LiAgSXQncyBub3QNCmp1c3QgUGV0ZSwgd2hv IGZvdWdodCBpdCBvbiB0aGlzIGxpc3Q6IGF0IGxlYXN0IHRocmVlIG90aGVyIEFEcyB3YW50DQp0 aGUgbmFtZSBjaGFuZ2VkIGJlZm9yZSB3ZSBjYW4gYXBwcm92ZSB0aGUgY2hhcnRlciBmb3IgZXh0 ZXJuYWwNCnJldmlldy4NCg0KVGhlIElFU0cgaXMgd29ya2luZyBvbiBhbiBhbHRlcm5hdGl2ZSBu YW1lIC0tIG9uZSB0aGF0IHdhcyBzdWdnZXN0ZWQNCndhcyAiSW50ZXItRG9tYWluIFVzZXIgSWRl bnRpdHkgTWFuYWdlbWVudCIsIGdpdmluZyBhIHdvcmtpbmcgZ3JvdXANCmFjcm9ueW0gb2YgImlk dWltIi4NCg0KVGhpcyBncm91cCBjYW4sIG9mIGNvdXJzZSwgcHJvcG9zZSBvdGhlciBuYW1lcy4u LiBpbiB0aGUgZW5kLCB0aGUgSUVTRw0Kd2lsbCBwaWNrIHRoZSBuYW1lLCB0aG91Z2ggaXQgd291 bGQgYmUgbmljZSB0byBoYXZlIGFncmVlbWVudCBmcm9tIHRoZQ0KY29tbXVuaXR5LiAgQnV0IGhl cmUncyB0aGUgdGhpbmc6DQotIEdpdmUgdXAgb24gInNpbXBsZSIuICBUaGVyZSd2ZSBiZWVuIHRv byBtYW55IHByb3RvY29scyB3aXRoIHRoYXQgaW4NCnRoZSBuYW1lLCBhbmQgbm9uZSBvZiB0aGVt IGFyZS4NCi0gR2l2ZSB1cCBvbiAiY2xvdWQiLiAgVGhpcyB3aWxsIGNlcnRhaW5seSBiZSB1c2Vk IGJ5IGNsb3VkIHByb3ZpZGVycywNCmJ1dCBpcyBub3Qgc3BlY2lmaWMgdG8gdGhhdCB1c2UsIGFu ZCB0aGUgbmFtZSAiY2xvdWQiIGNhcnJpZXMgdG9vIG11Y2gNCmJhZ2dhZ2UgYW5kIHRvbyBtYW55 IG90aGVyIGFzc3VtcHRpb25zLg0KLSAiSWRlbnRpdHkgbWFuYWdlbWVudCIgYnkgaXRzZWxmIGlz IGEgYnJvYWRlciB0b3BpYyB0aGFuIHdoYXQgd2UncmUNCnRhbGtpbmcgYWJvdXQgaGVyZS4gICJV c2VyIGlkZW50aXR5IG1hbmFnZW1lbnQiIG1pZ2h0IHdvcmsgKHNlZSB0aGUNCnN1Z2dlc3Rpb24g YWJvdmUpLCBhcyBtaWdodCBvdGhlciBmb3JtdWxhdGlvbnMgeW91IG1heSBjb21lIHVwIHdpdGgu DQoNCkJhcnJ5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2NpbQ0K From phil.hunt@oracle.com Thu May 24 18:09:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED7C11E8081 for ; Thu, 24 May 2012 18:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdKXL3AYPjO3 for ; Thu, 24 May 2012 18:09:35 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3742F11E8080 for ; Thu, 24 May 2012 18:09:35 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4P19Uj1003903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 May 2012 01:09:31 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4P19TpX027958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 01:09:30 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4P19TOS027213; Thu, 24 May 2012 20:09:29 -0500 Received: from [25.69.132.129] (/74.198.150.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 May 2012 18:09:29 -0700 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Thu, 24 May 2012 18:11:39 -0700 To: Likepeng X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:09:36 -0000 Too close to idiot/dum whatever.=20 Synchronous Cross-domain Identity Management Phil On 2012-05-24, at 17:37, Likepeng wrote: >> The IESG is working on an alternative name -- one that was suggested > was "Inter-Domain User Identity Management", giving a working group > acronym of "iduim". >=20 > I like this one.=20 >=20 > The easier way for us is to agree with the IESG proposal, and we can move o= n. >=20 > Thanks, > Kind Regards > Kepeng > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: scim-bounces@ietf.org [mailto:scim-bounces@ie= tf.org] =E4=BB=A3=E8=A1=A8 Barry Leiba > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8825=E6=97=A5 2= :16 > =E6=94=B6=E4=BB=B6=E4=BA=BA: scim@ietf.org > =E4=B8=BB=E9=A2=98: Re: [scim] Feedback on the charter from IESG and IAB >=20 > I have good news and bad news from the IESG telechat today. >=20 > The good news is that the IESG is happy with the charter. The only > change they asked for was a one-word addition to make it clear that > "authorization" will also be included in the security bit: >=20 > OLD > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authenticity and privacy. >=20 > NEW > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > | around authorization, authenticity, and privacy. >=20 >=20 > The bad news is on the name, "SCIM": that dog will not hunt. It's not > just Pete, who fought it on this list: at least three other ADs want > the name changed before we can approve the charter for external > review. >=20 > The IESG is working on an alternative name -- one that was suggested > was "Inter-Domain User Identity Management", giving a working group > acronym of "iduim". >=20 > This group can, of course, propose other names... in the end, the IESG > will pick the name, though it would be nice to have agreement from the > community. But here's the thing: > - Give up on "simple". There've been too many protocols with that in > the name, and none of them are. > - Give up on "cloud". This will certainly be used by cloud providers, > but is not specific to that use, and the name "cloud" carries too much > baggage and too many other assumptions. > - "Identity management" by itself is a broader topic than what we're > talking about here. "User identity management" might work (see the > suggestion above), as might other formulations you may come up with. >=20 > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Thu May 24 18:42:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5F11E8080 for ; Thu, 24 May 2012 18:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfd5EC-fvRmB for ; Thu, 24 May 2012 18:42:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34E21F8491 for ; Thu, 24 May 2012 18:42:54 -0700 (PDT) Received: by dacx6 with SMTP id x6so554450dac.31 for ; Thu, 24 May 2012 18:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ePl0FA8/gsS1VQDibKBOZaVHUAKBvFeOF4X73iwPjpk=; b=ggct8n+1QYMyFKt96HxBsENcJJbPI+MmEzomoybJ7hygghPpyZmWIfNuQ4wwSPmPIH EQReRhlzItXjFOhIrVesxq+PfLRbf+tZ02lNqxq7j3fWU5nKLW4arxxrJY1pJfiOkA2P 91+gRWKOXvVMvQtLzh2JPbd+i6TPJW3vQ8e9V5KC5cWsl7dVXEu7IXPtGJm+hCVSPFzQ eoc1QQcoHon2nrs9FMN8M65eUtNjAmKWNCEyQS7dz/eaqZTJoi63Q6b3rtIg5Le4qjeS i8qIeX4Uz7lC9DTxrq/7G3uwe3o/gomX3HYL+u57iROFJnfrLc8yQzqFJEe1jVojxdGl sVRw== Received: by 10.68.136.69 with SMTP id py5mr26766809pbb.115.1337910174123; Thu, 24 May 2012 18:42:54 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id qp3sm2062377pbc.17.2012.05.24.18.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 18:42:53 -0700 (PDT) Message-ID: <4FBEE39B.1050007@gmail.com> Date: Thu, 24 May 2012 17:42:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:42:55 -0000 On 5/24/12 5:11 PM, Phil Hunt wrote: > Synchronous Cross-domain Identity Management This is going *great*. Can we just drop the 'S'? Melinda From likepeng@huawei.com Thu May 24 18:51:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271A21F84D6 for ; Thu, 24 May 2012 18:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5ka2gV8ajjL for ; Thu, 24 May 2012 18:51:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9410421F84D8 for ; Thu, 24 May 2012 18:51:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF93989; Thu, 24 May 2012 21:51:03 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 18:48:44 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 18:48:42 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.207]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Fri, 25 May 2012 09:48:36 +0800 From: Likepeng To: Melinda Shore , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33GpvhXiCZqykCXOsWD/wrUtJbIZn0AgABgeQCAAJA1AIAAMrgAgAD02wCAAocugIAAjNIAgAB3GICACsN6gIAA79oQ//+EaoCAAAi4gIAAhuWg Date: Fri, 25 May 2012 01:48:35 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F207B87996@szxeml525-mbx.china.huawei.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <4FBEE39B.1050007@gmail.com> In-Reply-To: <4FBEE39B.1050007@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:51:06 -0000 PkNhbiB3ZSBqdXN0IGRyb3AgdGhlICdTJz8NCg0KKzEuIA0KDQpJZiB3ZSBhZGQgInVzZXIiLCBp dCBiZWNvbWVzICJDcm9zcy1kb21haW4gVXNlciBJZGVudGl0eSBNYW5hZ2VtZW50Ii4gSXQgaXMg Y2xvc2UgdG8gSUVTRyBwcm9wb3NhbCBub3cuDQoNCkkgdGhpbmsgd2UgY2FyZSBtb3JlIGFib3V0 IFVzZXIgSWRlbnRpdHksIG5vdCBDb250ZW50IElkZW50aXR5LCBzbyAiVXNlciIgaW4gdGhlIG5h bWUgd2lsbCBoZWxwLg0KDQpLZXBlbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBzY2lt LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTWVs aW5kYSBTaG9yZQ0Kt6LLzcqxvOQ6IDIwMTLE6jXUwjI1yNUgOTo0Mw0KytW8/sjLOiBzY2ltQGll dGYub3JnDQrW98ziOiBSZTogW3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBjaGFydGVyIGZyb20gSUVT RyBhbmQgSUFCDQoNCk9uIDUvMjQvMTIgNToxMSBQTSwgUGhpbCBIdW50IHdyb3RlOg0KPiBTeW5j aHJvbm91cyBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudA0KDQpUaGlzIGlzIGdvaW5n ICpncmVhdCouICBDYW4gd2UganVzdCBkcm9wIHRoZSAnUyc/DQoNCk1lbGluZGENCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBs aXN0DQpzY2ltQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NjaW0NCg== From wmills@yahoo-inc.com Thu May 24 18:59:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6815211E808D for ; Thu, 24 May 2012 18:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.217 X-Spam-Level: X-Spam-Status: No, score=-17.217 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7L3SydbRkjT for ; Thu, 24 May 2012 18:59:43 -0700 (PDT) Received: from nm24-vm3.bullet.mail.ne1.yahoo.com (nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) by ietfa.amsl.com (Postfix) with SMTP id 6854711E8080 for ; Thu, 24 May 2012 18:59:43 -0700 (PDT) Received: from [98.138.90.52] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2012 01:59:42 -0000 Received: from [98.138.88.235] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2012 01:59:42 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 25 May 2012 01:59:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 753038.4698.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 63178 invoked by uid 60001); 25 May 2012 01:59:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337911182; bh=KkDFcKdYOwD4Wbf5pQ2cPnTd0L6YYwJ41CoKzs8Ha5U=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CwK9C2sMsPWRRXruYJrfx+tlEzt/sI0rqHrKqd66pOWJVfWU+9Vmebd8CgKVePULuObGaVh1S4cWhIO2bySvmXZ5nCjTZdv3dNTn3sDkGyXw5biYO1tl2m0u39ze+7uJco5IWzvlLptRD9+cpmSbjciTzbrqC5Ojt7lVPjBANuc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Nd+fkS5fCJe8aeXJ9NADQVMew86ErIWnfHsfM5PDU2i/tjxocCg6p/Rut0xHwwCF6kzTLCrWzd95y/eFTFqwX7/cS1xLPyxaS/Gend/K5Qkdn5D2hfHUHBrFeYfY+18V/L6BfkdHm1gAmb2xhsTWDNtDqQAP8kf5C8Ji4m8OQ7I=; X-YMail-OSG: hohVrSsVM1kYVeyAyKsvags9iqDAY7Hm8Cp2gNh9TQ46sO. x77TII__34hesPMwvtSN2D0TPsdN8Am_cxF9sUhbYL6EiyP4Ns8ywv..THjQ B1HIjWHUw8XCCqiZLDDPeSSLJgHCQLwWIWXQlMGTq7XfCcz0teNWzxyNSBno rYmawFPosCVQl8rwaFTWxwTFBsw2o829II90fak2k9KOvMnl_zx9yQ1Yv3Iw DZtpkyC_.0rVTNaHYLMgIMQvhLaieEONEYBtz6XhDYHg_oH6FOns5xOMU.YF IHElvIWlS9ZuNPuPQ8qw67Y166gk7l1mXttlVN4c9JolAYvluczFe2lmSoMC JkUtV09yOI.sXI1BI6rj3W4z7BthAhoEkirVefB6CS71z57SV28i5T7trCsW X1ZtfEcY9N9fx5715alCrWCoAB0F.gWUR4NZ2LgXBP6nQ.OuUOrWRlAQ. Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Thu, 24 May 2012 18:59:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> Message-ID: <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 24 May 2012 18:59:41 -0700 (PDT) From: William Mills To: Phil Hunt , Likepeng In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-228878310-1337911181=:52591" Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:59:44 -0000 --1502656925-228878310-1337911181=:52591 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cross-domain Identity Management System.=C2=A0 The S is sideways....=0A=0A= =0A=0A=0A>________________________________=0A> From: Phil Hunt =0A>To: Likepeng =0A>Cc: "scim@ietf.org" ; Barry Leiba =0A>Sent: Thursday, Ma= y 24, 2012 6:11 PM=0A>Subject: Re: [scim] Feedback on the charter from IESG= and IAB=0A> =0A>Too close to idiot/dum=C2=A0 whatever. =0A>=0A>Synchronous= Cross-domain Identity Management=0A>=0A>Phil=0A>=0A>On 2012-05-24, at 17:3= 7, Likepeng wrote:=0A>=0A>>> The IESG is working on a= n alternative name -- one that was suggested=0A>> was "Inter-Domain User Id= entity Management", giving a working group=0A>> acronym of "iduim".=0A>> = =0A>> I like this one. =0A>> =0A>> The easier way for us is to agree with t= he IESG proposal, and we can move on.=0A>> =0A>> Thanks,=0A>> Kind Regards= =0A>> Kepeng=0A>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A>> =E5= =8F=91=E4=BB=B6=E4=BA=BA: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Barry Leiba=0A>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2012=E5=B9=B45=E6=9C=8825=E6=97=A5 2:16=0A>> =E6=94=B6=E4=BB=B6=E4=BA= =BA: scim@ietf.org=0A>> =E4=B8=BB=E9=A2=98: Re: [scim] Feedback on the char= ter from IESG and IAB=0A>> =0A>> I have good news and bad news from the IES= G telechat today.=0A>> =0A>> The good news is that the IESG is happy with t= he charter.=C2=A0 The only=0A>> change they asked for was a one-word additi= on to make it clear that=0A>> "authorization" will also be included in the = security bit:=0A>> =0A>> OLD=0A>>=C2=A0 In addition, the working group will= ensure that the SCIM protocol=0A>>=C2=A0 embodies good security practices.= Given both the sensitivity of the=0A>>=C2=A0 information being conveyed in= SCIM messages and the regulatory=0A>>=C2=A0 requirements regarding the pri= vacy of personally identifiable=0A>>=C2=A0 information, the working group w= ill pay particular attention to issues=0A>> | around authenticity and priva= cy.=0A>> =0A>> NEW=0A>>=C2=A0 In addition, the working group will ensure th= at the SCIM protocol=0A>>=C2=A0 embodies good security practices. Given bot= h the sensitivity of the=0A>>=C2=A0 information being conveyed in SCIM mess= ages and the regulatory=0A>>=C2=A0 requirements regarding the privacy of pe= rsonally identifiable=0A>>=C2=A0 information, the working group will pay pa= rticular attention to issues=0A>> | around authorization, authenticity, and= privacy.=0A>> =0A>> =0A>> The bad news is on the name, "SCIM": that dog wi= ll not hunt.=C2=A0 It's not=0A>> just Pete, who fought it on this list: at = least three other ADs want=0A>> the name changed before we can approve the = charter for external=0A>> review.=0A>> =0A>> The IESG is working on an alte= rnative name -- one that was suggested=0A>> was "Inter-Domain User Identity= Management", giving a working group=0A>> acronym of "iduim".=0A>> =0A>> Th= is group can, of course, propose other names... in the end, the IESG=0A>> w= ill pick the name, though it would be nice to have agreement from the=0A>> = community.=C2=A0 But here's the thing:=0A>> - Give up on "simple".=C2=A0 Th= ere've been too many protocols with that in=0A>> the name, and none of them= are.=0A>> - Give up on "cloud".=C2=A0 This will certainly be used by cloud= providers,=0A>> but is not specific to that use, and the name "cloud" carr= ies too much=0A>> baggage and too many other assumptions.=0A>> - "Identity = management" by itself is a broader topic than what we're=0A>> talking about= here.=C2=A0 "User identity management" might work (see the=0A>> suggestion= above), as might other formulations you may come up with.=0A>> =0A>> Barry= =0A>> _______________________________________________=0A>> scim mailing lis= t=0A>> scim@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/scim=0A>> _= ______________________________________________=0A>> scim mailing list=0A>> = scim@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/scim=0A>__________= _____________________________________=0A>scim mailing list=0A>scim@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/scim=0A>=0A>=0A> --1502656925-228878310-1337911181=:52591 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Cros= s-domain Identity Management System.  The S is sideways....
<= div>
=
From: Phil Hunt <p= hil.hunt@oracle.com>
To: Likepeng <likepeng@huawei.com>
Cc: "scim@ietf.org" <scim@ietf.org>; Barry Leiba= <barryleiba@computer.org>
Sent: Thursday, May 24, 2012 6:11 PM
S= ubject: Re: [scim] Feedback on the charter from IESG and IAB
=

=0AToo close to idiot/dum  whatever.

Synch= ronous Cross-domain Identity Management

Phil

On 2012-05-24, a= t 17:37, Likepeng <likepeng@huawei.com> wrote:

>>= The IESG is working on an alternative name -- one that was suggested
&g= t; was "Inter-Domain User Identity Management", giving a working group
&= gt; acronym of "iduim".
>
> I like this one.
>
>= The easier way for us is to agree with the IESG proposal, and we can move = on.
>
> Thanks,
> Kind Regards
> Kepeng
> --= ---=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4= =BA=BA: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Barry Leiba
> =E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2012=E5=B9=B45=E6=9C=8825=E6=97=A5 2:16
> =E6=94=B6=E4=BB=B6=E4=BA=BA: scim@ietf.org
> =E4=B8=BB=E9=A2= =98: Re: [scim] Feedback on the charter from IESG and IAB
>
> = I have good news and bad news from the IESG telechat today.
>
>= ; The good news is that the IESG is happy with the charter.  The only<= br>> change they asked for was a one-word addition to make it clear that=
> "authorization" will also be included in the security bit:
>=
> OLD
>  In addition, the working group will ensure that= the SCIM protocol
>  embodies good security practices. Given bo= th the sensitivity of the
>  information being conveyed in SCIM = messages and the regulatory
>  requirements regarding the privac= y of personally identifiable
>  information, the working group w= ill pay particular attention to issues
> | around authenticity and pr= ivacy.
>
> NEW
>  In addition, the working group will ensure that the SCIM= protocol
>  embodies good security practices. Given both the se= nsitivity of the
>  information being conveyed in SCIM messages = and the regulatory
>  requirements regarding the privacy of pers= onally identifiable
>  information, the working group will pay p= articular attention to issues
> | around authorization, authenticity,= and privacy.
>
>
> The bad news is on the name, "SCIM"= : that dog will not hunt.  It's not
> just Pete, who fought it o= n this list: at least three other ADs want
> the name changed before = we can approve the charter for external
> review.
>
> Th= e IESG is working on an alternative name -- one that was suggested
> = was "Inter-Domain User Identity Management", giving a working group
>= acronym of "iduim".
>
> This group can, of course, propose other names... in the end, the IESG
> will pick the name, th= ough it would be nice to have agreement from the
> community.  B= ut here's the thing:
> - Give up on "simple".  There've been too= many protocols with that in
> the name, and none of them are.
>= ; - Give up on "cloud".  This will certainly be used by cloud provider= s,
> but is not specific to that use, and the name "cloud" carries to= o much
> baggage and too many other assumptions.
> - "Identity = management" by itself is a broader topic than what we're
> talking ab= out here.  "User identity management" might work (see the
> sugg= estion above), as might other formulations you may come up with.
> > Barry
> _______________________________________________
>= ; scim mailing list
> scim@ietf.org
> http= s://www.ietf.org/mailman/listinfo/scim
> ________________________= _______________________
> scim mailing list
> scim@ietf.org
> = ht= tps://www.ietf.org/mailman/listinfo/scim
___________________________= ____________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim


=
--1502656925-228878310-1337911181=:52591-- From edreux@cloudiway.com Thu May 24 23:41:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AE821F8533 for ; Thu, 24 May 2012 23:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1aMYPFM6DiP for ; Thu, 24 May 2012 23:41:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53121F8532 for ; Thu, 24 May 2012 23:41:24 -0700 (PDT) Received: from mail211-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 May 2012 06:41:13 +0000 Received: from mail211-va3 (localhost [127.0.0.1]) by mail211-va3-R.bigfish.com (Postfix) with ESMTP id B5D0ECC0236 for ; Fri, 25 May 2012 06:41:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT003.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: PS-35(zz9371Ic89bh936eK1be0I1432Nc857h98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail211-va3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT003.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail211-va3 (localhost.localdomain [127.0.0.1]) by mail211-va3 (MessageSwitch) id 1337928055745365_7002; Fri, 25 May 2012 06:40:55 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.245]) by mail211-va3.bigfish.com (Postfix) with ESMTP id 56003C0004C for ; Fri, 25 May 2012 06:40:43 +0000 (UTC) Received: from AMXPRD0610HT003.eurprd06.prod.outlook.com (157.56.248.213) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 May 2012 06:40:42 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.15]) by AMXPRD0610HT003.eurprd06.prod.outlook.com ([10.255.58.38]) with mapi id 14.16.0152.000; Fri, 25 May 2012 06:40:39 +0000 From: Emmanuel Dreux To: "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNOhpcQQ3EyTrK706ZHP5zIa//e5baCzWw Date: Fri, 25 May 2012 06:40:38 +0000 Message-ID: References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.204.168.75] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD1231045AAMXPRD0610MB353_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 06:41:27 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD1231045AAMXPRD0610MB353_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U0NJTSBpcyBhIHByb3RvY29sIGZvciBwcm92aXNpb25pbmcgdGhlIENsb3VkLCBhIHByb3RvY29s IGZvciBwcm92aXNpb25pbmcgU0FBUyBhcHBsaWNhdGlvbnMuDQoNCkl0IGhhcyBiZWVuIGRlc2ln bmVkIGJ5IHRoZSBhdXRob3JzIGZvciB0aGlzIHVzYWdlIGFuZCB0aGUgY29tbXVuaXR5IGhhcyBq b2luZWQgdGhpcyB3b3JraW5nIGdyb3VwIGZvciB0aGlzIHJlYXNvbi4NCg0KDQoNCllvdSB3YW50 IHRvIGV4dGVuZCBoaXMgaHlwb3RoZXRpY2FsIHVzZSBhbmQgcmVtb3ZlIHRoZSB0ZXJtIENsb3Vk IHRvIHN1Z2dlc3Qgb24gcHJlbWlzZSBhcHBsaWNhdGlvbnMgYW5kIHVzYWdlPw0KDQpHcmVhdC4N Cg0KDQoNCllvdSB0aGluayB0aGF0IGl0IG1pZ2h0IGJlIHVzZWQgKGZvciBleGFtcGxlKSB0byBz eW5jaHJvbml6ZSBhbiBFUlAgc3lzdGVtIHdpdGggYSBMREFQIHNlcnZlcj8NCg0KQWZ0ZXIgYWxs LCB3aHkgbm90LCBidXQgd2hlcmUgaXMgdGhlIG5vdGlvbiBvZiBkb21haW4/DQoNCkl04oCZcyBu b3QgYSBjcm9zcyBkb21haW4gc2NlbmFyaW8uIEl04oCZcyBqdXN0IGludGVyb3BlcmFiaWxpdHkg YmV0d2VlbiAyIGRpZmZlcmVudCBraW5kcyBvZiBkaXJlY3Rvcmllcy4NCg0KDQoNClBsZWFzZSBk byBub3QgcmVwbGFjZSB0aGUgdGVybSBjbG91ZCBieSB0aGUgdGVybSBkb21haW4gaWYgeW91ciB3 aXNoIGlzIHRvIHN1Z2dlc3Qgb24gcHJlbWlzZSBjYXBhYmlsaXRpZXMuDQoNCk91ciBwcm9kdWN0 IGlzIGEgQ0FNIHNlcnZlciAoQ2xvdWQgQWNjZXNzIE1hbmFnZW1lbnQgc2VydmVyKS4gT25lIG9m IG91ciBjdXN0b21lciB3YW50cyB0byB1c2UgaXQgdG8gcHJvdmlzaW9uIGFuIG9wZW4gc291cmNl IFdJRkkgc3lzdGVtIGNhbGxlZCBwZnNlbnNlIHRoYXQgdXNlcyBSQURJVVMgYXV0aGVudGljYXRp b24uDQoNCkFmdGVyIGFsbCwgd2h5IG5vdCwgd2UgYWNjZXB0ZWQgdGhlIGNoYWxsZW5nZSBvZiB3 cml0aW5nIGFuIGV4dGVuc2lvbiBmb3IgaGlzIG9uIHByZW1pc2Ug4oCcYXBwbGljYXRpb27igJ0s IGFuZCB0aGF0IGRvZXMgbm90IGNoYWxsZW5nZSB0aGUgZmFjdCB0aGF0IHdlIGtlZXAgdGhlIG5h bWUg4oCcQ2xvdWRBbnl3aGVyZeKAnSBmb3Igb3VyIHByb2R1Y3QsIG5laXRoZXIgZG9lcyBpdCBj aGFsbGVuZ2UgdGhlIGZhY3QgdGhhdCB3ZSB3aWxsIHN0aWxsIG1hcmtldCBpdCBhcyBhIHNvbHV0 aW9uIGZvciBwcm92aXNpb25pbmcgU0FBUyBhcHBsaWNhdGlvbnMuDQoNCg0KDQpXaGF0IGRvZXMg SVAgc3RhbmRzIGZvciBpbiBUQ1AvSVA/IFdoZXJlIGlzIGl0IHVzZWQ/DQoNCg0KDQpJZiB5b3Ug d2FudCBhIHRlcm0gZm9yIHJlcGxhY2luZyBTQ0lNLCBMREVQIChMaWdodHdlaWdodCBEaXJlY3Rv cnkgRXhjaGFuZ2UgUHJvdG9jb2wpLCBvciBMRFBQIChMaWdodHdlaWdodCBEaXJlY3RvcnkgUHJv dmlzaW9uaW5nIFByb3RvY29sKSB3b3VsZCBiZXR0ZXIgZml0IHRoZSB1c2FnZS4NCg0KLS0NClJl Z2FyZHMsDQpFbW1hbnVlbCBEcmV1eA0KaHR0cDovL3d3dy5jbG91ZGl3YXkuY29tDQpUZWw6ICsz MyAxIDQ2IDE1IDA3IDIyDQpNb2JpbGU6ICszMyA2IDQ3IDgxIDI2IDcwDQpza3lwZTogRW1tYW51 ZWwuRHJldXgNCg0KRGUgOiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5j b21dDQpFbnZvecOpIDogdmVuZHJlZGkgMjUgbWFpIDIwMTIgMDQ6MDANCsOAIDogUGhpbCBIdW50 OyBMaWtlcGVuZw0KQ2MgOiBzY2ltQGlldGYub3JnOyBCYXJyeSBMZWliYQ0KT2JqZXQgOiBSZTog W3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBjaGFydGVyIGZyb20gSUVTRyBhbmQgSUFCDQoNCkNyb3Nz LWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IFN5c3RlbS4gIFRoZSBTIGlzIHNpZGV3YXlzLi4u Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KVG86IExp a2VwZW5nIDxsaWtlcGVuZ0BodWF3ZWkuY29tPG1haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tPj4N CkNjOiAic2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4iIDxzY2ltQGlldGYub3Jn PG1haWx0bzpzY2ltQGlldGYub3JnPj47IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+Pg0KU2VudDogVGh1cnNkYXksIE1h eSAyNCwgMjAxMiA2OjExIFBNDQpTdWJqZWN0OiBSZTogW3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBj aGFydGVyIGZyb20gSUVTRyBhbmQgSUFCDQoNClRvbyBjbG9zZSB0byBpZGlvdC9kdW0gIHdoYXRl dmVyLg0KDQpTeW5jaHJvbm91cyBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudA0KDQpQ aGlsDQoNCk9uIDIwMTItMDUtMjQsIGF0IDE3OjM3LCBMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2Vp LmNvbTxtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQo+PiBUaGUgSUVTRyBp cyB3b3JraW5nIG9uIGFuIGFsdGVybmF0aXZlIG5hbWUgLS0gb25lIHRoYXQgd2FzIHN1Z2dlc3Rl ZA0KPiB3YXMgIkludGVyLURvbWFpbiBVc2VyIElkZW50aXR5IE1hbmFnZW1lbnQiLCBnaXZpbmcg YSB3b3JraW5nIGdyb3VwDQo+IGFjcm9ueW0gb2YgImlkdWltIi4NCj4NCj4gSSBsaWtlIHRoaXMg b25lLg0KPg0KPiBUaGUgZWFzaWVyIHdheSBmb3IgdXMgaXMgdG8gYWdyZWUgd2l0aCB0aGUgSUVT RyBwcm9wb3NhbCwgYW5kIHdlIGNhbiBtb3ZlIG9uLg0KPg0KPiBUaGFua3MsDQo+IEtpbmQgUmVn YXJkcw0KPiBLZXBlbmcNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHNj aW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OnNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPl0g5Luj 6KGoIEJhcnJ5IExlaWJhDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDXmnIgyNeaXpSAyOjE2DQo+ IOaUtuS7tuS6ujogc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj4g5Li76aKY OiBSZTogW3NjaW1dIEZlZWRiYWNrIG9uIHRoZSBjaGFydGVyIGZyb20gSUVTRyBhbmQgSUFCDQo+ DQo+IEkgaGF2ZSBnb29kIG5ld3MgYW5kIGJhZCBuZXdzIGZyb20gdGhlIElFU0cgdGVsZWNoYXQg dG9kYXkuDQo+DQo+IFRoZSBnb29kIG5ld3MgaXMgdGhhdCB0aGUgSUVTRyBpcyBoYXBweSB3aXRo IHRoZSBjaGFydGVyLiAgVGhlIG9ubHkNCj4gY2hhbmdlIHRoZXkgYXNrZWQgZm9yIHdhcyBhIG9u ZS13b3JkIGFkZGl0aW9uIHRvIG1ha2UgaXQgY2xlYXIgdGhhdA0KPiAiYXV0aG9yaXphdGlvbiIg d2lsbCBhbHNvIGJlIGluY2x1ZGVkIGluIHRoZSBzZWN1cml0eSBiaXQ6DQo+DQo+IE9MRA0KPiAg SW4gYWRkaXRpb24sIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZW5zdXJlIHRoYXQgdGhlIFNDSU0g cHJvdG9jb2wNCj4gIGVtYm9kaWVzIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2VzLiBHaXZlbiBib3Ro IHRoZSBzZW5zaXRpdml0eSBvZiB0aGUNCj4gIGluZm9ybWF0aW9uIGJlaW5nIGNvbnZleWVkIGlu IFNDSU0gbWVzc2FnZXMgYW5kIHRoZSByZWd1bGF0b3J5DQo+ICByZXF1aXJlbWVudHMgcmVnYXJk aW5nIHRoZSBwcml2YWN5IG9mIHBlcnNvbmFsbHkgaWRlbnRpZmlhYmxlDQo+ICBpbmZvcm1hdGlv biwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwYXkgcGFydGljdWxhciBhdHRlbnRpb24gdG8gaXNz dWVzDQo+IHwgYXJvdW5kIGF1dGhlbnRpY2l0eSBhbmQgcHJpdmFjeS4NCj4NCj4gTkVXDQo+ICBJ biBhZGRpdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBlbnN1cmUgdGhhdCB0aGUgU0NJTSBw cm90b2NvbA0KPiAgZW1ib2RpZXMgZ29vZCBzZWN1cml0eSBwcmFjdGljZXMuIEdpdmVuIGJvdGgg dGhlIHNlbnNpdGl2aXR5IG9mIHRoZQ0KPiAgaW5mb3JtYXRpb24gYmVpbmcgY29udmV5ZWQgaW4g U0NJTSBtZXNzYWdlcyBhbmQgdGhlIHJlZ3VsYXRvcnkNCj4gIHJlcXVpcmVtZW50cyByZWdhcmRp bmcgdGhlIHByaXZhY3kgb2YgcGVyc29uYWxseSBpZGVudGlmaWFibGUNCj4gIGluZm9ybWF0aW9u LCB0aGUgd29ya2luZyBncm91cCB3aWxsIHBheSBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0byBpc3N1 ZXMNCj4gfCBhcm91bmQgYXV0aG9yaXphdGlvbiwgYXV0aGVudGljaXR5LCBhbmQgcHJpdmFjeS4N Cj4NCj4NCj4gVGhlIGJhZCBuZXdzIGlzIG9uIHRoZSBuYW1lLCAiU0NJTSI6IHRoYXQgZG9nIHdp bGwgbm90IGh1bnQuICBJdCdzIG5vdA0KPiBqdXN0IFBldGUsIHdobyBmb3VnaHQgaXQgb24gdGhp cyBsaXN0OiBhdCBsZWFzdCB0aHJlZSBvdGhlciBBRHMgd2FudA0KPiB0aGUgbmFtZSBjaGFuZ2Vk IGJlZm9yZSB3ZSBjYW4gYXBwcm92ZSB0aGUgY2hhcnRlciBmb3IgZXh0ZXJuYWwNCj4gcmV2aWV3 Lg0KPg0KPiBUaGUgSUVTRyBpcyB3b3JraW5nIG9uIGFuIGFsdGVybmF0aXZlIG5hbWUgLS0gb25l IHRoYXQgd2FzIHN1Z2dlc3RlZA0KPiB3YXMgIkludGVyLURvbWFpbiBVc2VyIElkZW50aXR5IE1h bmFnZW1lbnQiLCBnaXZpbmcgYSB3b3JraW5nIGdyb3VwDQo+IGFjcm9ueW0gb2YgImlkdWltIi4N Cj4NCj4gVGhpcyBncm91cCBjYW4sIG9mIGNvdXJzZSwgcHJvcG9zZSBvdGhlciBuYW1lcy4uLiBp biB0aGUgZW5kLCB0aGUgSUVTRw0KPiB3aWxsIHBpY2sgdGhlIG5hbWUsIHRob3VnaCBpdCB3b3Vs ZCBiZSBuaWNlIHRvIGhhdmUgYWdyZWVtZW50IGZyb20gdGhlDQo+IGNvbW11bml0eS4gIEJ1dCBo ZXJlJ3MgdGhlIHRoaW5nOg0KPiAtIEdpdmUgdXAgb24gInNpbXBsZSIuICBUaGVyZSd2ZSBiZWVu IHRvbyBtYW55IHByb3RvY29scyB3aXRoIHRoYXQgaW4NCj4gdGhlIG5hbWUsIGFuZCBub25lIG9m IHRoZW0gYXJlLg0KPiAtIEdpdmUgdXAgb24gImNsb3VkIi4gIFRoaXMgd2lsbCBjZXJ0YWlubHkg YmUgdXNlZCBieSBjbG91ZCBwcm92aWRlcnMsDQo+IGJ1dCBpcyBub3Qgc3BlY2lmaWMgdG8gdGhh dCB1c2UsIGFuZCB0aGUgbmFtZSAiY2xvdWQiIGNhcnJpZXMgdG9vIG11Y2gNCj4gYmFnZ2FnZSBh bmQgdG9vIG1hbnkgb3RoZXIgYXNzdW1wdGlvbnMuDQo+IC0gIklkZW50aXR5IG1hbmFnZW1lbnQi IGJ5IGl0c2VsZiBpcyBhIGJyb2FkZXIgdG9waWMgdGhhbiB3aGF0IHdlJ3JlDQo+IHRhbGtpbmcg YWJvdXQgaGVyZS4gICJVc2VyIGlkZW50aXR5IG1hbmFnZW1lbnQiIG1pZ2h0IHdvcmsgKHNlZSB0 aGUNCj4gc3VnZ2VzdGlvbiBhYm92ZSksIGFzIG1pZ2h0IG90aGVyIGZvcm11bGF0aW9ucyB5b3Ug bWF5IGNvbWUgdXAgd2l0aC4NCj4NCj4gQmFycnkNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gc2NpbSBtYWlsaW5nIGxpc3QNCj4gc2NpbUBpZXRm Lm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zY2ltDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHNjaW0gbWFpbGluZyBsaXN0DQo+IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNj aW1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0g bWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_DF63ACC82673DB40A7AAC08FFA71DFBD1231045AAMXPRD0610MB353_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpQTWluZ0xpVTsNCglwYW5vc2UtMToyIDIg NSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFBNaW5nTGlV IjsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgYnJ1dCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2Fy DQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRleHRlYnJ1dENhcg0KCXttc28tc3R5bGUtbmFt ZToiVGV4dGUgYnJ1dCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgYnJ1dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNDSU0gaXMgYSBwcm90b2NvbCBmb3IgcHJvdmlz aW9uaW5nIHRoZSBDbG91ZCwgYSBwcm90b2NvbCBmb3IgcHJvdmlzaW9uaW5nIFNBQVMgYXBwbGlj YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5JdCBoYXMgYmVlbiBkZXNpZ25lZCBieSB0aGUgYXV0aG9ycyBmb3Ig dGhpcyB1c2FnZSBhbmQgdGhlIGNvbW11bml0eSBoYXMgam9pbmVkIHRoaXMgd29ya2luZyBncm91 cCBmb3IgdGhpcyByZWFzb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ugd2FudCB0byBl eHRlbmQgaGlzIGh5cG90aGV0aWNhbCB1c2UgYW5kIHJlbW92ZSB0aGUgdGVybSBDbG91ZCB0byBz dWdnZXN0IG9uIHByZW1pc2UgYXBwbGljYXRpb25zIGFuZCB1c2FnZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+R3JlYXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3UgdGhpbmsgdGhhdCBpdCBtaWdodCBiZSB1c2Vk IChmb3IgZXhhbXBsZSkgdG8gc3luY2hyb25pemUgYW4gRVJQIHN5c3RlbSB3aXRoIGEgTERBUCBz ZXJ2ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFmdGVyIGFsbCwgd2h5IG5vdCwgYnV0IHdoZXJlIGlzIHRoZSBub3Rp b24gb2YgZG9tYWluPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdOKAmXMgbm90IGEgY3Jvc3MgZG9tYWluIHNjZW5hcmlv LiBJdOKAmXMganVzdCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gMiBkaWZmZXJlbnQga2luZHMg b2YgZGlyZWN0b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgZG8gbm90IHJl cGxhY2UgdGhlIHRlcm0gY2xvdWQgYnkgdGhlIHRlcm0gZG9tYWluIGlmIHlvdXIgd2lzaCBpcyB0 byBzdWdnZXN0IG9uIHByZW1pc2UgY2FwYWJpbGl0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PdXIgcHJvZHVjdCBp cyBhIENBTSBzZXJ2ZXIgKENsb3VkIEFjY2VzcyBNYW5hZ2VtZW50IHNlcnZlcikuIE9uZSBvZiBv dXIgY3VzdG9tZXIgd2FudHMgdG8gdXNlIGl0IHRvIHByb3Zpc2lvbiBhbiBvcGVuIHNvdXJjZSBX SUZJIHN5c3RlbSBjYWxsZWQgcGZzZW5zZSB0aGF0IHVzZXMgUkFESVVTIGF1dGhlbnRpY2F0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5BZnRlciBhbGwsIHdoeSBub3QsIHdlIGFjY2VwdGVkIHRoZSBjaGFsbGVuZ2Ug b2Ygd3JpdGluZyBhbiBleHRlbnNpb24gZm9yIGhpcyBvbiBwcmVtaXNlIOKAnGFwcGxpY2F0aW9u 4oCdLCBhbmQgdGhhdCBkb2VzIG5vdCBjaGFsbGVuZ2UgdGhlIGZhY3QgdGhhdCB3ZSBrZWVwIHRo ZSBuYW1lIOKAnENsb3VkQW55d2hlcmXigJ0gZm9yIG91ciBwcm9kdWN0LCBuZWl0aGVyIGRvZXMg aXQgY2hhbGxlbmdlDQogdGhlIGZhY3QgdGhhdCB3ZSB3aWxsIHN0aWxsIG1hcmtldCBpdCBhcyBh IHNvbHV0aW9uIGZvciBwcm92aXNpb25pbmcgU0FBUyBhcHBsaWNhdGlvbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5XaGF0IGRvZXMgSVAgc3RhbmRzIGZvciBpbiBUQ1AvSVA/IFdoZXJlIGlz IGl0IHVzZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3Ugd2FudCBhIHRlcm0gZm9y IHJlcGxhY2luZyBTQ0lNLCBMREVQIChMaWdodHdlaWdodCBEaXJlY3RvcnkgRXhjaGFuZ2UgUHJv dG9jb2wpLCBvciBMRFBQIChMaWdodHdlaWdodCBEaXJlY3RvcnkgUHJvdmlzaW9uaW5nIFByb3Rv Y29sKSB3b3VsZCBiZXR0ZXIgZml0IHRoZSB1c2FnZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RW1tYW51ZWwgRHJldXg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+aHR0cDovL3d3dy5jbG91ZGl3YXkuY29tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRlbDogJiM0MzszMyAxIDQ2IDE1IDA3IDIyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1vYmlsZTogJiM0MzszMyA2IDQ3IDgxIDI2IDcwPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPnNreXBlOiBFbW1hbnVlbC5EcmV1eDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0N Cjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAyNSBtYWkgMjAxMiAwNDowMDxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gUGhpbCBIdW50OyBMaWtlcGVuZzxicj4NCjxiPkNjJm5ic3A7 OjwvYj4gc2NpbUBpZXRmLm9yZzsgQmFycnkgTGVpYmE8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFJlOiBbc2NpbV0gRmVlZGJhY2sgb24gdGhlIGNoYXJ0ZXIgZnJvbSBJRVNHIGFuZCBJQUI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q3Jvc3MtZG9t YWluIElkZW50aXR5IE1hbmFnZW1lbnQgU3lzdGVtLiZuYnNwOyBUaGUgUyBpcyBzaWRld2F5cy4u Li48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjMuNzVwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAw JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwvYj4gTGlrZXBlbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tIj5saWtlcGVuZ0BodWF3ZWku Y29tPC9hPiZndDsNCjxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNjaW1A aWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7OyBCYXJyeSBMZWliYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9y ZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAyNCwgMjAxMiA2OjEx IFBNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gRmVlZGJhY2sgb24gdGhlIGNoYXJ0 ZXIgZnJvbSBJRVNHIGFuZCBJQUI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxicj4NClRvbyBjbG9zZSB0byBpZGlvdC9kdW0mbmJzcDsgd2hhdGV2ZXIuIDxicj4N Cjxicj4NClN5bmNocm9ub3VzIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50PGJyPg0K PGJyPg0KUGhpbDxicj4NCjxicj4NCk9uIDIwMTItMDUtMjQsIGF0IDE3OjM3LCBMaWtlcGVuZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb20iPmxpa2VwZW5nQGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUaGUgSUVTRyBpcyB3b3JraW5n IG9uIGFuIGFsdGVybmF0aXZlIG5hbWUgLS0gb25lIHRoYXQgd2FzIHN1Z2dlc3RlZDxicj4NCiZn dDsgd2FzICZxdW90O0ludGVyLURvbWFpbiBVc2VyIElkZW50aXR5IE1hbmFnZW1lbnQmcXVvdDss IGdpdmluZyBhIHdvcmtpbmcgZ3JvdXA8YnI+DQomZ3Q7IGFjcm9ueW0gb2YgJnF1b3Q7aWR1aW0m cXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgbGlrZSB0aGlzIG9uZS4gPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFRoZSBlYXNpZXIgd2F5IGZvciB1cyBpcyB0byBhZ3JlZSB3aXRoIHRoZSBJRVNH IHByb3Bvc2FsLCBhbmQgd2UgY2FuIG1vdmUgb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r cyw8YnI+DQomZ3Q7IEtpbmQgUmVnYXJkczxicj4NCiZndDsgS2VwZW5nPGJyPg0KJmd0OyAtLS0t LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPi0tLS0tPGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJt YWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5zY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyI+c2NpbS1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7ku6Pooag8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4gQmFycnkgTGVpYmE8YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogMjAxMjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJs YWNrIj7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7Y29sb3I6YmxhY2siPuaciDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjI1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7Y29sb3I6YmxhY2siPuaXpTwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPg0KIDI6MTY8YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7mlLbku7bk uro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrIj7kuLs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7popg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij46IFJlOiBbc2NpbV0gRmVlZGJhY2sgb24gdGhlIGNoYXJ0ZXIgZnJvbSBJRVNHIGFuZCBJQUI8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlIGdvb2QgbmV3cyBhbmQgYmFkIG5ld3MgZnJvbSB0 aGUgSUVTRyB0ZWxlY2hhdCB0b2RheS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGdvb2QgbmV3 cyBpcyB0aGF0IHRoZSBJRVNHIGlzIGhhcHB5IHdpdGggdGhlIGNoYXJ0ZXIuJm5ic3A7IFRoZSBv bmx5PGJyPg0KJmd0OyBjaGFuZ2UgdGhleSBhc2tlZCBmb3Igd2FzIGEgb25lLXdvcmQgYWRkaXRp b24gdG8gbWFrZSBpdCBjbGVhciB0aGF0PGJyPg0KJmd0OyAmcXVvdDthdXRob3JpemF0aW9uJnF1 b3Q7IHdpbGwgYWxzbyBiZSBpbmNsdWRlZCBpbiB0aGUgc2VjdXJpdHkgYml0Ojxicj4NCiZndDsg PGJyPg0KJmd0OyBPTEQ8YnI+DQomZ3Q7Jm5ic3A7IEluIGFkZGl0aW9uLCB0aGUgd29ya2luZyBn cm91cCB3aWxsIGVuc3VyZSB0aGF0IHRoZSBTQ0lNIHByb3RvY29sPGJyPg0KJmd0OyZuYnNwOyBl bWJvZGllcyBnb29kIHNlY3VyaXR5IHByYWN0aWNlcy4gR2l2ZW4gYm90aCB0aGUgc2Vuc2l0aXZp dHkgb2YgdGhlPGJyPg0KJmd0OyZuYnNwOyBpbmZvcm1hdGlvbiBiZWluZyBjb252ZXllZCBpbiBT Q0lNIG1lc3NhZ2VzIGFuZCB0aGUgcmVndWxhdG9yeTxicj4NCiZndDsmbmJzcDsgcmVxdWlyZW1l bnRzIHJlZ2FyZGluZyB0aGUgcHJpdmFjeSBvZiBwZXJzb25hbGx5IGlkZW50aWZpYWJsZTxicj4N CiZndDsmbmJzcDsgaW5mb3JtYXRpb24sIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcGF5IHBhcnRp Y3VsYXIgYXR0ZW50aW9uIHRvIGlzc3Vlczxicj4NCiZndDsgfCBhcm91bmQgYXV0aGVudGljaXR5 IGFuZCBwcml2YWN5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBORVc8YnI+DQomZ3Q7Jm5ic3A7IElu IGFkZGl0aW9uLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGVuc3VyZSB0aGF0IHRoZSBTQ0lNIHBy b3RvY29sPGJyPg0KJmd0OyZuYnNwOyBlbWJvZGllcyBnb29kIHNlY3VyaXR5IHByYWN0aWNlcy4g R2l2ZW4gYm90aCB0aGUgc2Vuc2l0aXZpdHkgb2YgdGhlPGJyPg0KJmd0OyZuYnNwOyBpbmZvcm1h dGlvbiBiZWluZyBjb252ZXllZCBpbiBTQ0lNIG1lc3NhZ2VzIGFuZCB0aGUgcmVndWxhdG9yeTxi cj4NCiZndDsmbmJzcDsgcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyB0aGUgcHJpdmFjeSBvZiBwZXJz b25hbGx5IGlkZW50aWZpYWJsZTxicj4NCiZndDsmbmJzcDsgaW5mb3JtYXRpb24sIHRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgcGF5IHBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIGlzc3Vlczxicj4NCiZn dDsgfCBhcm91bmQgYXV0aG9yaXphdGlvbiwgYXV0aGVudGljaXR5LCBhbmQgcHJpdmFjeS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgYmFkIG5ld3MgaXMgb24gdGhlIG5hbWUs ICZxdW90O1NDSU0mcXVvdDs6IHRoYXQgZG9nIHdpbGwgbm90IGh1bnQuJm5ic3A7IEl0J3Mgbm90 PGJyPg0KJmd0OyBqdXN0IFBldGUsIHdobyBmb3VnaHQgaXQgb24gdGhpcyBsaXN0OiBhdCBsZWFz dCB0aHJlZSBvdGhlciBBRHMgd2FudDxicj4NCiZndDsgdGhlIG5hbWUgY2hhbmdlZCBiZWZvcmUg d2UgY2FuIGFwcHJvdmUgdGhlIGNoYXJ0ZXIgZm9yIGV4dGVybmFsPGJyPg0KJmd0OyByZXZpZXcu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVNHIGlzIHdvcmtpbmcgb24gYW4gYWx0ZXJuYXRp dmUgbmFtZSAtLSBvbmUgdGhhdCB3YXMgc3VnZ2VzdGVkPGJyPg0KJmd0OyB3YXMgJnF1b3Q7SW50 ZXItRG9tYWluIFVzZXIgSWRlbnRpdHkgTWFuYWdlbWVudCZxdW90OywgZ2l2aW5nIGEgd29ya2lu ZyBncm91cDxicj4NCiZndDsgYWNyb255bSBvZiAmcXVvdDtpZHVpbSZxdW90Oy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhpcyBncm91cCBjYW4sIG9mIGNvdXJzZSwgcHJvcG9zZSBvdGhlciBuYW1l cy4uLiBpbiB0aGUgZW5kLCB0aGUgSUVTRzxicj4NCiZndDsgd2lsbCBwaWNrIHRoZSBuYW1lLCB0 aG91Z2ggaXQgd291bGQgYmUgbmljZSB0byBoYXZlIGFncmVlbWVudCBmcm9tIHRoZTxicj4NCiZn dDsgY29tbXVuaXR5LiZuYnNwOyBCdXQgaGVyZSdzIHRoZSB0aGluZzo8YnI+DQomZ3Q7IC0gR2l2 ZSB1cCBvbiAmcXVvdDtzaW1wbGUmcXVvdDsuJm5ic3A7IFRoZXJlJ3ZlIGJlZW4gdG9vIG1hbnkg cHJvdG9jb2xzIHdpdGggdGhhdCBpbjxicj4NCiZndDsgdGhlIG5hbWUsIGFuZCBub25lIG9mIHRo ZW0gYXJlLjxicj4NCiZndDsgLSBHaXZlIHVwIG9uICZxdW90O2Nsb3VkJnF1b3Q7LiZuYnNwOyBU aGlzIHdpbGwgY2VydGFpbmx5IGJlIHVzZWQgYnkgY2xvdWQgcHJvdmlkZXJzLDxicj4NCiZndDsg YnV0IGlzIG5vdCBzcGVjaWZpYyB0byB0aGF0IHVzZSwgYW5kIHRoZSBuYW1lICZxdW90O2Nsb3Vk JnF1b3Q7IGNhcnJpZXMgdG9vIG11Y2g8YnI+DQomZ3Q7IGJhZ2dhZ2UgYW5kIHRvbyBtYW55IG90 aGVyIGFzc3VtcHRpb25zLjxicj4NCiZndDsgLSAmcXVvdDtJZGVudGl0eSBtYW5hZ2VtZW50JnF1 b3Q7IGJ5IGl0c2VsZiBpcyBhIGJyb2FkZXIgdG9waWMgdGhhbiB3aGF0IHdlJ3JlPGJyPg0KJmd0 OyB0YWxraW5nIGFib3V0IGhlcmUuJm5ic3A7ICZxdW90O1VzZXIgaWRlbnRpdHkgbWFuYWdlbWVu dCZxdW90OyBtaWdodCB3b3JrIChzZWUgdGhlPGJyPg0KJmd0OyBzdWdnZXN0aW9uIGFib3ZlKSwg YXMgbWlnaHQgb3RoZXIgZm9ybXVsYXRpb25zIHlvdSBtYXkgY29tZSB1cCB3aXRoLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBCYXJyeTxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNjaW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bTwvYT48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBzY2ltIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2NpbTwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_DF63ACC82673DB40A7AAC08FFA71DFBD1231045AAMXPRD0610MB353_-- From melinda.shore@gmail.com Thu May 24 23:58:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DC211E8088 for ; Thu, 24 May 2012 23:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7ZnVl4SCMei for ; Thu, 24 May 2012 23:58:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A263B11E807F for ; Thu, 24 May 2012 23:58:21 -0700 (PDT) Received: by dacx6 with SMTP id x6so858697dac.31 for ; Thu, 24 May 2012 23:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FU9ugqPCJc2Jy6qYVe+oOUg8TXeC+hyewaTyOGLxDGA=; b=XdPH75/262kTBGZB9whjhM7y4BFQI+fBKZGrXaFjDFs73ntmg8FaosyahQ9OBbaVE4 WgM37MT51wkCiYySdprQkSy8lpbv49Gkqh501HBblRddiJHZqShIVT84wZ/XAqRCOS30 gfuKmIfW+DlUCW1l48YEyQVymg+V6UCqPyKqfHTU2+03qCppkpy6wIC+fMT483V/ARIF epzGanZZ7tWlob8k1TQwyi0K/+pq03+7Ld/Dpya7NVHJoeAYY8F8VJLCfLXtvKBVztFy Vn+s2VY2gtiBnbv5/gUjd3WP8jMGF2SwXogFFwR0YeVn030eO5qGbaGitxWlfcVuVI0U f5PQ== Received: by 10.68.236.129 with SMTP id uu1mr29592963pbc.77.1337929101224; Thu, 24 May 2012 23:58:21 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id tt5sm3939670pbc.12.2012.05.24.23.58.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 23:58:20 -0700 (PDT) Message-ID: <4FBF2D8A.9090003@gmail.com> Date: Thu, 24 May 2012 22:58:18 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 06:58:22 -0000 On 5/24/12 10:40 PM, Emmanuel Dreux wrote: > It has been designed by the authors for this usage and the community has > joined this working group for this reason. Some of the community. I'm here because there's clearly a need for an identity provisioning protocol, and SPML has tanked. My suspicion is that by the time the protocol is published the pendulum will have swung back towards a more distributed computing model, as it tends to do, and while the protocol would continue to be useful its name would be anachronistic. > What does IP stands for in TCP/IP? Where is it used? I'm pretty sure that neither 'I' nor 'P' represents the word "cloud," yet you're using it anyway. > If you want a term for replacing SCIM, LDEP (Lightweight Directory > Exchange Protocol), or LDPP (Lightweight Directory Provisioning > Protocol) would better fit the usage. ?? Where did "Directory" and "Lightweight" come from? Melinda From moransar@cisco.com Fri May 25 01:35:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4321F8619; Fri, 25 May 2012 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH7-7xfNgU7m; Fri, 25 May 2012 01:35:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4A921F8618; Fri, 25 May 2012 01:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=4061; q=dns/txt; s=iport; t=1337934939; x=1339144539; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ACSeRIaU4AUd1zhQJFfxt720SopNwgS7MWKLegQYnUw=; b=OSjhIIYSlth0DXTQu8g2wmPREdub/LFF64kWzLbsxSOZI44S5PSGoJxn VRGnRlzPH4cp0eR+a/Bgl/4OvtvpoQeFeVq849uZIm1MDdVxy2NhMhXND 4zO76Uw3C5hoFUahND+fW2WLhmYyfLZJjWMD/ixNRn9qqQaF1BHcHE/BL M=; X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208";a="86605536" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 25 May 2012 08:35:39 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4P8ZcLq009285; Fri, 25 May 2012 08:35:38 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 03:35:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 03:35:37 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> In-Reply-To: <4FBE7F66.4030500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac052/u1NyoWUzg4TcSmNjLUYxwB/QAc8zeA References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com><4FB1ACFA.1080107@stpeter.im><93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> From: "Morteza Ansari (moransar)" To: "Eliot Lear" , "Barry Leiba" X-OriginalArrivalTime: 25 May 2012 08:35:38.0741 (UTC) FILETIME=[5CCE7A50:01CD3A51] Cc: scim@ietf.org, IESG Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:35:40 -0000 I think we have gone around the block with this discussion a few times. I am going to repeat my last response to the topic: Personally speaking I still think we should stick with SCIM. If the current traction of SCIM v1 is any indication, by the time v2 is standardized, there will be quite a few implementations of SCIM v1 in the wild (we are almost at 10 distinct implementations now). A rename between v1 and v2 will only result in confusion and 10 years from now we will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10 fold by causing confusion. If we *really* must change something, let's stay with SCIM and change "cloud" to any other word that starts with "c" and move forward with the real work ahead. Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eliot Lear Sent: Thursday, May 24, 2012 11:35 AM To: Barry Leiba Cc: scim@ietf.org; 'IESG' Subject: Re: [scim] Feedback on the charter from IESG and IAB Barry, I'm sorry but arguing over a name is not something that should be done by the IESG. It impacts the wire not one little bit, and it's disrespectful to those who brought the work into the IETF. It also wastes the time of many people diverting them from what I'm sure we'd all prefer them to work on- things that DO effect the wire. Honestly, can't we PLEASE move along? Eliot On 5/24/12 8:15 PM, Barry Leiba wrote: > I have good news and bad news from the IESG telechat today. > > The good news is that the IESG is happy with the charter. The only=20 > change they asked for was a one-word addition to make it clear that=20 > "authorization" will also be included in the security bit: > > OLD > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to=20 > issues > | around authenticity and privacy. > > NEW > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to=20 > issues > | around authorization, authenticity, and privacy. > > > The bad news is on the name, "SCIM": that dog will not hunt. It's not > just Pete, who fought it on this list: at least three other ADs want=20 > the name changed before we can approve the charter for external=20 > review. > > The IESG is working on an alternative name -- one that was suggested=20 > was "Inter-Domain User Identity Management", giving a working group=20 > acronym of "iduim". > > This group can, of course, propose other names... in the end, the IESG > will pick the name, though it would be nice to have agreement from the > community. But here's the thing: > - Give up on "simple". There've been too many protocols with that in=20 > the name, and none of them are. > - Give up on "cloud". This will certainly be used by cloud providers, > but is not specific to that use, and the name "cloud" carries too much > baggage and too many other assumptions. > - "Identity management" by itself is a broader topic than what we're=20 > talking about here. "User identity management" might work (see the=20 > suggestion above), as might other formulations you may come up with. > > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From prvs=2492338DD6=erik.wahlstrom@nexussafe.com Fri May 25 01:41:20 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C33921F858F; Fri, 25 May 2012 01:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udy4JUvR454J; Fri, 25 May 2012 01:41:19 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFA921F853C; Fri, 25 May 2012 01:41:18 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 May 2012 10:41:12 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Fri, 25 May 2012 10:41:14 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: "Morteza Ansari (moransar)" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNMdYHn9+p655lBEiTUrsvOGnj4pbJtxAAgAAyuACAAPTbAIAChy6AgACM0gCAAHcYgIAKw3qAgAAFhwCAAOrIgIAAAY8A Date: Fri, 25 May 2012 08:41:13 +0000 Message-ID: <20776997-AE38-4BCB-AB73-F9208D683B2D@nexussafe.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com><4FB1ACFA.1080107@stpeter.im><93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Barry Leiba , IESG , Eliot Lear Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:41:20 -0000 +1 On May 25, 2012, at 10:35 AM, Morteza Ansari (moransar) wrote: > I think we have gone around the block with this discussion a few times. > I am going to repeat my last response to the topic: >=20 > Personally speaking I still think we should stick with SCIM. If the > current traction of SCIM v1 is any indication, by the time v2 is > standardized, there will be quite a few implementations of SCIM v1 in > the wild (we are almost at 10 distinct implementations now). A rename > between v1 and v2 will only result in confusion and 10 years from now we > will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber > vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10 > fold by causing confusion. If we *really* must change something, let's > stay with SCIM and change "cloud" to any other word that starts with "c" > and move forward with the real work ahead. >=20 >=20 > Cheers, > Morteza >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of > Eliot Lear > Sent: Thursday, May 24, 2012 11:35 AM > To: Barry Leiba > Cc: scim@ietf.org; 'IESG' > Subject: Re: [scim] Feedback on the charter from IESG and IAB >=20 > Barry, >=20 > I'm sorry but arguing over a name is not something that should be done > by the IESG. It impacts the wire not one little bit, and it's > disrespectful to those who brought the work into the IETF. It also > wastes the time of many people diverting them from what I'm sure we'd > all prefer them to work on- things that DO effect the wire. Honestly, > can't we PLEASE move along? >=20 > Eliot >=20 > On 5/24/12 8:15 PM, Barry Leiba wrote: >> I have good news and bad news from the IESG telechat today. >>=20 >> The good news is that the IESG is happy with the charter. The only=20 >> change they asked for was a one-word addition to make it clear that=20 >> "authorization" will also be included in the security bit: >>=20 >> OLD >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to=20 >> issues >> | around authenticity and privacy. >>=20 >> NEW >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to=20 >> issues >> | around authorization, authenticity, and privacy. >>=20 >>=20 >> The bad news is on the name, "SCIM": that dog will not hunt. It's not >=20 >> just Pete, who fought it on this list: at least three other ADs want=20 >> the name changed before we can approve the charter for external=20 >> review. >>=20 >> The IESG is working on an alternative name -- one that was suggested=20 >> was "Inter-Domain User Identity Management", giving a working group=20 >> acronym of "iduim". >>=20 >> This group can, of course, propose other names... in the end, the IESG >=20 >> will pick the name, though it would be nice to have agreement from the >=20 >> community. But here's the thing: >> - Give up on "simple". There've been too many protocols with that in=20 >> the name, and none of them are. >> - Give up on "cloud". This will certainly be used by cloud providers, >=20 >> but is not specific to that use, and the name "cloud" carries too much >=20 >> baggage and too many other assumptions. >> - "Identity management" by itself is a broader topic than what we're=20 >> talking about here. "User identity management" might work (see the=20 >> suggestion above), as might other formulations you may come up with. >>=20 >> Barry >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From samuel@erdtman.se Fri May 25 01:42:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D421F861A for ; Fri, 25 May 2012 01:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL5r7kvM1NDR for ; Fri, 25 May 2012 01:42:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4C21F8618 for ; Fri, 25 May 2012 01:42:30 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so535312lbb.31 for ; Fri, 25 May 2012 01:42:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=WSrHZ0+Mm5hTe6vCVs0GfWX+T04O7VZdcV+k415ufVU=; b=lEpmYHd/UHlOITAek6mLcTX0PuJyM7bI4NDRrebDRHdy+QKD4GGaXsxFSo4wRFzxZC oicn4GdePCwKbl76PrlmC3gHV5HS3yttBwt34NksTKmrbtFScbv0Phau+6AHd8Hur5F4 Wd+tC6kDf80SkmYYIrowJDALsjw8Ct8KmGswN1cBcvLzKRkFOt/hbX9wHicrXC/vrFZx UDL9a0scLTjLOjXH7xpo3amC/GdddCaNEnQRNBKTIMsVRRJWf9IRFMgulHbhS7OdeoOc sG8F2qQrM/rQes5RLDQpyBMft1Fnk1f5QfoyLO/ijSlmH5PcPItrypIv5J7QWAjRIpp4 JGYw== MIME-Version: 1.0 Received: by 10.112.48.2 with SMTP id h2mr1156353lbn.61.1337935349924; Fri, 25 May 2012 01:42:29 -0700 (PDT) Received: by 10.112.45.138 with HTTP; Fri, 25 May 2012 01:42:29 -0700 (PDT) In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> Date: Fri, 25 May 2012 10:42:29 +0200 Message-ID: From: Samuel Erdtman To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnkXK7nYso7Gv0gyg5XAjKZUXTIO0bPwLAsijIgWCaNu70mfCosjWi3MVP4p4uGa4S5BIXB Cc: scim@ietf.org, Barry Leiba , IESG , Eliot Lear Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:42:32 -0000 +1 On Fri, May 25, 2012 at 10:35 AM, Morteza Ansari (moransar) wrote: > I think we have gone around the block with this discussion a few times. > I am going to repeat my last response to the topic: > > Personally speaking I still think we should stick with SCIM. If the > current traction of SCIM v1 is any indication, by the time v2 is > standardized, there will be quite a few implementations of SCIM v1 in > the wild (we are almost at 10 distinct implementations now). A rename > between v1 and v2 will only result in confusion and 10 years from now we > will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber > vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10 > fold by causing confusion. If we *really* must change something, let's > stay with SCIM and change "cloud" to any other word that starts with "c" > and move forward with the real work ahead. > > > Cheers, > Morteza > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of > Eliot Lear > Sent: Thursday, May 24, 2012 11:35 AM > To: Barry Leiba > Cc: scim@ietf.org; 'IESG' > Subject: Re: [scim] Feedback on the charter from IESG and IAB > > Barry, > > I'm sorry but arguing over a name is not something that should be done > by the IESG. =A0It impacts the wire not one little bit, and it's > disrespectful to those who brought the work into the IETF. =A0It also > wastes the time of many people diverting them from what I'm sure we'd > all prefer them to work on- things that DO effect the wire. =A0Honestly, > can't we PLEASE move along? > > Eliot > > On 5/24/12 8:15 PM, Barry Leiba wrote: >> I have good news and bad news from the IESG telechat today. >> >> The good news is that the IESG is happy with the charter. =A0The only >> change they asked for was a one-word addition to make it clear that >> "authorization" will also be included in the security bit: >> >> OLD >> =A0 In addition, the working group will ensure that the SCIM protocol >> =A0 embodies good security practices. Given both the sensitivity of the >> =A0 information being conveyed in SCIM messages and the regulatory >> =A0 requirements regarding the privacy of personally identifiable >> =A0 information, the working group will pay particular attention to >> issues >> | around authenticity and privacy. >> >> NEW >> =A0 In addition, the working group will ensure that the SCIM protocol >> =A0 embodies good security practices. Given both the sensitivity of the >> =A0 information being conveyed in SCIM messages and the regulatory >> =A0 requirements regarding the privacy of personally identifiable >> =A0 information, the working group will pay particular attention to >> issues >> | around authorization, authenticity, and privacy. >> >> >> The bad news is on the name, "SCIM": that dog will not hunt. =A0It's not > >> just Pete, who fought it on this list: at least three other ADs want >> the name changed before we can approve the charter for external >> review. >> >> The IESG is working on an alternative name -- one that was suggested >> was "Inter-Domain User Identity Management", giving a working group >> acronym of "iduim". >> >> This group can, of course, propose other names... in the end, the IESG > >> will pick the name, though it would be nice to have agreement from the > >> community. =A0But here's the thing: >> - Give up on "simple". =A0There've been too many protocols with that in >> the name, and none of them are. >> - Give up on "cloud". =A0This will certainly be used by cloud providers, > >> but is not specific to that use, and the name "cloud" carries too much > >> baggage and too many other assumptions. >> - "Identity management" by itself is a broader topic than what we're >> talking about here. =A0"User identity management" might work (see the >> suggestion above), as might other formulations you may come up with. >> >> Barry >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From tspencer@pingidentity.com Fri May 25 02:02:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3E21F862A for ; Fri, 25 May 2012 02:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnABMNIIpW2d for ; Fri, 25 May 2012 02:02:34 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEB21F861F for ; Fri, 25 May 2012 02:02:30 -0700 (PDT) Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKT79KpcBBCuWuXRAwLDR878QesgNnfwX5@postini.com; Fri, 25 May 2012 02:02:30 PDT Received: by lbom4 with SMTP id m4so1166404lbo.16 for ; Fri, 25 May 2012 02:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=wqmjVnczt/zlFXkqnHP1d6PyeQ6ZFnxGxMDNIGX1u5w=; b=Z7nuFi/EZmVmgFEa00mumtFsVFLT1x+WjUgE4r0LjWe3C7suiNjhDWDJECg+JNW8iw ujRyNjGhmQHcqLo1UJyNl8YVYdjVjKdzqSHverB7N7Q1vHDhD3dcHL4aQcQWdpm1CxA+ Tz5Vlf2JcZF9znQ+//JQiHgiy1DbKNoPQ9sWmM4VLRnCfSnCpbmGPnekH5b3/2gTZww6 osSew1ayBn4m5VVYKlbjmxxk3PaWZVtBQseIgly7eS/RqlyQA0sq93ez/LM59+uJoNqt qL2L48nqkaCTUd2yxt2ZHPbG2sk7xWtRa4iog6hXrg4Wkq22aoE4z1AnioQH2DASzUS8 1M0A== Received: by 10.152.145.41 with SMTP id sr9mr2708039lab.25.1337936547709; Fri, 25 May 2012 02:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.36.194 with HTTP; Fri, 25 May 2012 02:01:57 -0700 (PDT) From: Travis Spencer Date: Fri, 25 May 2012 11:01:57 +0200 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=bcaec5396502a8818904c0d8a0ed X-Gm-Message-State: ALoCoQnf4LTaTTRBCab2mVqfa7V095hIOIDdXEwef7NKaIWoFbS5uPf5hRIs6e3zeNPnDsdmftv6 Subject: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:02:37 -0000 --bcaec5396502a8818904c0d8a0ed Content-Type: text/plain; charset=ISO-8859-1 Hi All, Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback. To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft): The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema: entitlementSchemes A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED. name The common Entitlement Scheme name; e.g., XACML. REQUIRED. description A description of the Entitlement Scheme. REQUIRED. specUrl An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL. documentationUrl An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL. When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports. basicEntitlements A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported. To replace entitlements in section 6.2 of the core schema doc: entitlements A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute. type A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request. value The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request. A non-normative examples of using the basic Entitlement Scheme is as follows: { "entitlements" : { "type": "basic", "value" : [ "calendar", "email", "spreadsheet" ] } } Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example: { "entitlements" : { "type" : "xacml", "value" : { /* XACML policy encoded in JavaScript */ } } } -- Regards, * * *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office *Ping* *Identity* | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *M:* +46 72 725 5655 *Email:* tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page *Connect with me* Twitter: @travisspencer LinkedIn: travisspencer --bcaec5396502a8818904c0d8a0ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

Please find below a proposal for changing how en= titlements are handled in SCIM. This proposal is based on various discussio= ns that have been happening in the community, so=A0hopefully=A0there is agr= eement on the general idea. If there are objections or details that need to= be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., sec= tion 9 of the draft):

=A0

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

=A0

entitlementSchemes

=A0

A complex type that specifies supported Entitlement Scheme properties. Instea= d of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

=A0

name

=A0

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

=A0

description

=A0

A description of the Entitlement Scheme. REQUIRED.

=A0

specUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's specification= . OPTIONAL.

=A0

documentationUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's usage documen= tation. OPTIONAL.

=A0

When basic is supported, a service provider MUST also support the following sing= le value attribute which defines the entitlements that it supports.

=A0

basicEntitlements

=A0

A list of string values that represent the entitlements that the service prov= ider supports. REQUIRED if the basic Entitlement Scheme is supported.

=A0

To replace entitlements in section 6.2 of the core schema doc:

=A0

entitlements

=A0

A complex attribute containing the entitlements of a User. Entitlements are t= he rights that a User has at the Service Provider as expressed according to th= e policy language stipulated by the type sub-attribute. A basic syntax is def= ined in this specification that allows the Client to specify a list of entitleme= nts as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

=A0

type

=A0

A string indicating the type of policy language. The only acceptable canonica= l value is basic. REQUIRED. If the type of policy is not understood, the Serv= ice Provider MUST return an HTTP 400, bad request.

=A0

value

=A0

The entitlements of the user. If the type is basic, this MUST be a list of stri= ngs where the elements are from the list of supported entitlements defined in t= he Service Provider's basicEntitlements schema attribute. If the type is N= OT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attrib= ute, the Service Provider MUST return an HTTP 400, bad request.

=A0

A non-normative examples of using the basic Entitlement Scheme is as follows:=

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0 "type": "basic",

=A0=A0=A0=A0=A0 "value" : [ "calendar", "email", "spreadsheet" ]

=A0 }

}

=A0

Service Providers MAY support additional policy languages instead of or in addition= to the basic one define herein. For example, a Service Provider may support XA= CML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0=A0=A0=A0=A0 "type" : "xacml",

=A0=A0=A0=A0=A0=A0=A0=A0 "value" : { /* XACML policy encoded in JavaScript */ }

=A0=A0 }

}


--

Regards,

Travis Spencer, BSCS, MBA= =A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0=A0=A0www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M:=A0+46 72 725 5655
Email:=A0tspencer@pingidentity.co= m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
Connect with Ping
Twitter:=A0= @pingidentity=
LinkedIn:=A0Ping's Identity Cloud= =A0=A0 =A0
Facebook:=A0Ping Identity Pag= e
Connect with me
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer


--bcaec5396502a8818904c0d8a0ed-- From paul.madsen@gmail.com Fri May 25 02:08:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6021F8647 for ; Fri, 25 May 2012 02:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spj-Tb3G8iZk for ; Fri, 25 May 2012 02:08:51 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3821F863E for ; Fri, 25 May 2012 02:08:51 -0700 (PDT) Received: by ggnc4 with SMTP id c4so726186ggn.31 for ; Fri, 25 May 2012 02:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=qSeC0H6GYOQjR4TUdcAOSZXDUchPOfPx4J3T8BiC0Ls=; b=fLGmFuYlzaJ2y251iZCDsC7EE4qfE3X7Pc7MGigX/gkgwMgakmr8r+U+1eszz8gs9l rET/hSJMWaWk8bGgpnd9+R6ZrZmUd0NuaJWmvNmJWKB9f7rNIKbX3K1Tz03EJwiBUwhH vnD0j32c0Xh1WW08iY1eLTqzgP8FnL7wGTi+uwejosH8mMiTksnSl+8sB6KWccjOvZ6w XpElF9Qoh7MnQSOds3YuEwHyMrmnGJDxGTSr1XOUGYC+qB8VqYT+mUr/381GwwlLJbn6 8eAO+MIsn9Ls4jvO/aVaab4VoV+xFFJoQE1K4wM2Ma+Jr6wsPld/enoFrbrbbu1UPpEF e+4g== Received: by 10.50.10.225 with SMTP id l1mr1903297igb.1.1337936930675; Fri, 25 May 2012 02:08:50 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id gw4sm6469023igb.6.2012.05.25.02.08.48 (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 02:08:49 -0700 (PDT) Message-ID: <4FBF4C20.7070406@gmail.com> Date: Fri, 25 May 2012 05:08:48 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 CC: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> In-Reply-To: <4FBF2D8A.9090003@gmail.com> Content-Type: multipart/alternative; boundary="------------050602040701080906040706" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:08:52 -0000 This is a multi-part message in MIME format. --------------050602040701080906040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Surprisingly Contentious IETF Metadata I will note that OAuth was neither particularly 'open' nor exclusively for 'authorization' but that name was able to persist into IETF .... I vote to keep 'SCIM' and change acronym Smart CRUD Identity Management paul On 5/25/12 2:58 AM, Melinda Shore wrote: > On 5/24/12 10:40 PM, Emmanuel Dreux wrote: >> It has been designed by the authors for this usage and the community has >> joined this working group for this reason. > > Some of the community. I'm here because there's clearly a need > for an identity provisioning protocol, and SPML has tanked. My > suspicion is that by the time the protocol is published the > pendulum will have swung back towards a more distributed > computing model, as it tends to do, and while the protocol > would continue to be useful its name would be anachronistic. > >> What does IP stands for in TCP/IP? Where is it used? > > I'm pretty sure that neither 'I' nor 'P' represents the > word "cloud," yet you're using it anyway. > >> If you want a term for replacing SCIM, LDEP (Lightweight Directory >> Exchange Protocol), or LDPP (Lightweight Directory Provisioning >> Protocol) would better fit the usage. > > ?? Where did "Directory" and "Lightweight" come from? > > Melinda > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------050602040701080906040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Surprisingly Contentious IETF Metadata

I will note that OAuth was neither particularly 'open' nor exclusively for 'authorization' but that name was able to persist into IETF ....

I vote to keep 'SCIM' and change acronym

Smart CRUD Identity Management

paul

On 5/25/12 2:58 AM, Melinda Shore wrote:
On 5/24/12 10:40 PM, Emmanuel Dreux wrote:
It has been designed by the authors for this usage and the community has
joined this working group for this reason.

Some of the community.  I'm here because there's clearly a need
for an identity provisioning protocol, and SPML has tanked.  My
suspicion is that by the time the protocol is published the
pendulum will have swung back towards a more distributed
computing model, as it tends to do, and while the protocol
would continue to be useful its name would be anachronistic.

What does IP stands for in TCP/IP? Where is it used?

I'm pretty sure that neither 'I' nor 'P' represents the
word "cloud," yet you're using it anyway.

If you want a term for replacing SCIM, LDEP (Lightweight Directory
Exchange Protocol), or LDPP (Lightweight Directory Provisioning
Protocol) would better fit the usage.

??  Where did "Directory" and "Lightweight" come from?

Melinda

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------050602040701080906040706-- From trey.drake@unboundid.com Fri May 25 07:05:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB021F8672 for ; Fri, 25 May 2012 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQNNdDnC6Gva for ; Fri, 25 May 2012 07:05:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB421F867A for ; Fri, 25 May 2012 07:05:16 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id eh20so1578727obb.31 for ; Fri, 25 May 2012 07:05:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KoTUfFPUjMQ0aafSxv5m3FcnjoaPDk/LGU36GVrMqYI=; b=P2QrNXifAcFJ9jfP8PU3vJmJchUDaiP3chyfk+dRI9x7K+LUCxjcJzwcNtJ2Wmx6zX jVP2wzBlWpnxsejB9Ft8kiPesXWmcGQFOiK26cArUAgiYr3Is1aLQ2lSFDCrskaaUSNc cXiLz5mK4Am69rF77c8mD+mIrz3kYF8xE3TeSqklSoTwX9kP2wI+PoblEgVlFP8PLgSr tkskpM0kVFC1Rtyg9pyfuwnq1NlTyCXifD88RNsZIqieViIGZCjbW/P+4pN1YvnytW1/ TixTWmi6LdDxEzeTwiYI1N1YQaaBhn0yCrNWj/xT0LjN2dtxB3TwkAsNqc5+ncixePIm x4Cg== Received: by 10.182.48.100 with SMTP id k4mr3274786obn.21.1337954715845; Fri, 25 May 2012 07:05:15 -0700 (PDT) Received: from [192.168.241.66] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id aa4sm1644595oec.0.2012.05.25.07.05.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 07:05:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Trey Drake In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> Date: Fri, 25 May 2012 09:05:15 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com><4FB1ACFA.1080107@stpeter.im><93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com><93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <4FBE7F66.4030500@cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE015BB856@XMB-RCD-313.cisco.com> To: "Morteza Ansari (moransar)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkahBnpyLamscSzUZD61JVU/IWX+/aJN9/PFhIfu4WrOMsRj0G1jHVNT8Z8ynvIHTTaEb0B Cc: scim@ietf.org, Barry Leiba , IESG , Eliot Lear Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:05:18 -0000 +1 On May 25, 2012, at 3:35 AM, Morteza Ansari (moransar) wrote: > I think we have gone around the block with this discussion a few times. > I am going to repeat my last response to the topic: > > Personally speaking I still think we should stick with SCIM. If the > current traction of SCIM v1 is any indication, by the time v2 is > standardized, there will be quite a few implementations of SCIM v1 in > the wild (we are almost at 10 distinct implementations now). A rename > between v1 and v2 will only result in confusion and 10 years from now we > will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber > vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10 > fold by causing confusion. If we *really* must change something, let's > stay with SCIM and change "cloud" to any other word that starts with "c" > and move forward with the real work ahead. > > > Cheers, > Morteza > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of > Eliot Lear > Sent: Thursday, May 24, 2012 11:35 AM > To: Barry Leiba > Cc: scim@ietf.org; 'IESG' > Subject: Re: [scim] Feedback on the charter from IESG and IAB > > Barry, > > I'm sorry but arguing over a name is not something that should be done > by the IESG. It impacts the wire not one little bit, and it's > disrespectful to those who brought the work into the IETF. It also > wastes the time of many people diverting them from what I'm sure we'd > all prefer them to work on- things that DO effect the wire. Honestly, > can't we PLEASE move along? > > Eliot > > On 5/24/12 8:15 PM, Barry Leiba wrote: >> I have good news and bad news from the IESG telechat today. >> >> The good news is that the IESG is happy with the charter. The only >> change they asked for was a one-word addition to make it clear that >> "authorization" will also be included in the security bit: >> >> OLD >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to >> issues >> | around authenticity and privacy. >> >> NEW >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to >> issues >> | around authorization, authenticity, and privacy. >> >> >> The bad news is on the name, "SCIM": that dog will not hunt. It's not > >> just Pete, who fought it on this list: at least three other ADs want >> the name changed before we can approve the charter for external >> review. >> >> The IESG is working on an alternative name -- one that was suggested >> was "Inter-Domain User Identity Management", giving a working group >> acronym of "iduim". >> >> This group can, of course, propose other names... in the end, the IESG > >> will pick the name, though it would be nice to have agreement from the > >> community. But here's the thing: >> - Give up on "simple". There've been too many protocols with that in >> the name, and none of them are. >> - Give up on "cloud". This will certainly be used by cloud providers, > >> but is not specific to that use, and the name "cloud" carries too much > >> baggage and too many other assumptions. >> - "Identity management" by itself is a broader topic than what we're >> talking about here. "User identity management" might work (see the >> suggestion above), as might other formulations you may come up with. >> >> Barry >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Fri May 25 08:03:23 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0A21F8597 for ; Fri, 25 May 2012 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thCQ0chtmvaH for ; Fri, 25 May 2012 08:03:22 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0A421F8548 for ; Fri, 25 May 2012 08:03:16 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 25 May 2012 08:03:16 -0700 From: Michael Hammer To: "paul.madsen@gmail.com" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNOdk3Pn/BgJSLa0K+Ur5Yp2U3L5baHs6AgAAJhICAAA1sgIAATn8AgAAE8ACAACR2AP//7ZDA Date: Fri, 25 May 2012 15:03:15 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38AF97C@EX2K10MB1.corp.yaanatech.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> In-Reply-To: <4FBF4C20.7070406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0078_01CD3A65.FB0F8A60" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:03:23 -0000 ------=_NextPart_000_0078_01CD3A65.FB0F8A60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0079_01CD3A65.FB0F8A60" ------=_NextPart_001_0079_01CD3A65.FB0F8A60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Solving Contentious Identity Management J From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Paul Madsen Sent: Friday, May 25, 2012 5:09 AM Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB Surprisingly Contentious IETF Metadata I will note that OAuth was neither particularly 'open' nor exclusively for 'authorization' but that name was able to persist into IETF .... I vote to keep 'SCIM' and change acronym Smart CRUD Identity Management paul On 5/25/12 2:58 AM, Melinda Shore wrote: On 5/24/12 10:40 PM, Emmanuel Dreux wrote: It has been designed by the authors for this usage and the community has joined this working group for this reason. Some of the community. I'm here because there's clearly a need for an identity provisioning protocol, and SPML has tanked. My suspicion is that by the time the protocol is published the pendulum will have swung back towards a more distributed computing model, as it tends to do, and while the protocol would continue to be useful its name would be anachronistic. What does IP stands for in TCP/IP? Where is it used? I'm pretty sure that neither 'I' nor 'P' represents the word "cloud," yet you're using it anyway. If you want a term for replacing SCIM, LDEP (Lightweight Directory Exchange Protocol), or LDPP (Lightweight Directory Provisioning Protocol) would better fit the usage. ?? Where did "Directory" and "Lightweight" come from? Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_001_0079_01CD3A65.FB0F8A60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Solving Contentious Identity Management

 

J

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Paul Madsen
Sent: Friday, May 25, 2012 5:09 = AM
Cc: scim@ietf.org
Subject: Re: [scim] Feedback on = the charter from IESG and IAB

 

Surprisingly Contentious IETF = Metadata

I will note that OAuth was neither particularly = 'open' nor exclusively for 'authorization' but that name was able to = persist into IETF ....

I vote to keep 'SCIM' and change = acronym

Smart CRUD Identity Management

paul

On = 5/25/12 2:58 AM, Melinda Shore wrote:

On 5/24/12 10:40 PM, Emmanuel Dreux wrote: =

It has been designed by the = authors for this usage and the community has
joined this working = group for this reason.


Some of = the community.  I'm here because there's clearly a need
for an = identity provisioning protocol, and SPML has tanked.  My =
suspicion is that by the time the protocol is published the =
pendulum will have swung back towards a more distributed =
computing model, as it tends to do, and while the protocol
would = continue to be useful its name would be anachronistic. =


What does IP stands for = in TCP/IP? Where is it used?


I'm = pretty sure that neither 'I' nor 'P' represents the
word = "cloud," yet you're using it anyway. =


If you want a term for = replacing SCIM, LDEP (Lightweight Directory
Exchange Protocol), or = LDPP (Lightweight Directory Provisioning
Protocol) would better fit = the usage.


??  Where did = "Directory" and "Lightweight" come from? =

Melinda

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

------=_NextPart_001_0079_01CD3A65.FB0F8A60-- ------=_NextPart_000_0078_01CD3A65.FB0F8A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUy NTE1MDMxNFowIwYJKoZIhvcNAQkEMRYEFMEEp03WsYK+hhy5/gXizcF7mKIgMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAsk38p2iCIXBSpfohj/eQK6fu3v3VV/oZvMprhSCpRYae bjEhTaWES55H2R3cS4gmZU4BAULsay4WodzoH/JQC/M6DcS3qwXgKOybMPDpLW024VMouO9rWwcH RUCuEadxuKI2u2QbMOxX60pHNeCkWacHQ9nmOSmQzjxm4I1CmQUAAAAAAAA= ------=_NextPart_000_0078_01CD3A65.FB0F8A60-- From melinda.shore@gmail.com Fri May 25 09:56:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AF921F8710 for ; Fri, 25 May 2012 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ias0t-EXhHXA for ; Fri, 25 May 2012 09:56:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2085B21F870F for ; Fri, 25 May 2012 09:56:29 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2032901pbc.31 for ; Fri, 25 May 2012 09:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tOMAzpAMHPRUVEceifdLmOLCOcV/cbHjBeQ67+4uv7w=; b=G1pwr/Mg2LJuuXXSj30yMOurLAhrHZNQ3o2t3j5kd6DIX4VJuwe6VZZ65cea3ABqIM DzbYdB9i/s1qfK/cjLuY4CfX1q6AMeWIk+MFQsDSApYlGxtP513m2CtRcR+7m7SlzVxA y440X3rM6suHM93EqRuQJkFvyfHgARBLHzjKbRIhOE280xpcZ4W8kbY+/AC7Vga2QBcN J+zVEMCnJPda6dPRHJ0iDUUMUgjvx1uOBhAElHsaQVcmDeTlCudkUS4RIIHjyG2AS0tj U1SR4dYxAYV6eTpFBbVq/jlErNql4kXLgz9hyXsUwBP355lAVJth+ufBvw4t+L+kubkB 36sw== Received: by 10.68.227.227 with SMTP id sd3mr33867398pbc.53.1337964988960; Fri, 25 May 2012 09:56:28 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id qp3sm4371484pbc.17.2012.05.25.09.56.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 09:56:28 -0700 (PDT) Message-ID: <4FBFB9B9.7000601@gmail.com> Date: Fri, 25 May 2012 08:56:25 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> In-Reply-To: <4FBF4C20.7070406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:56:29 -0000 On 5/25/12 1:08 AM, Paul Madsen wrote: > I will note that OAuth was neither particularly 'open' nor exclusively > for 'authorization' but that name was able to persist into IETF .... oauth was plagued with neither "simple" nor "cloud." Melinda From kelly.grizzle@sailpoint.com Fri May 25 10:11:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF821F872D for ; Fri, 25 May 2012 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImHCToRLMgQf for ; Fri, 25 May 2012 10:11:31 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1340021F8776 for ; Fri, 25 May 2012 10:11:30 -0700 (PDT) Received: from mail56-db3-R.bigfish.com (10.3.81.235) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 May 2012 17:11:18 +0000 Received: from mail56-db3 (localhost [127.0.0.1]) by mail56-db3-R.bigfish.com (Postfix) with ESMTP id 3B2CE4E00FF; Fri, 25 May 2012 17:11:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0411HT003.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz1418Izz1202hzzz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail56-db3: domain of sailpoint.com designates 157.56.241.133 as permitted sender) client-ip=157.56.241.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BL2PRD0411HT003.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3 (MessageSwitch) id 1337965878320405_11535; Fri, 25 May 2012 17:11:18 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.229]) by mail56-db3.bigfish.com (Postfix) with ESMTP id 4C362160048; Fri, 25 May 2012 17:11:18 +0000 (UTC) Received: from BL2PRD0411HT003.namprd04.prod.outlook.com (157.56.241.133) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 May 2012 17:11:16 +0000 Received: from BL2PRD0411MB397.namprd04.prod.outlook.com ([169.254.10.100]) by BL2PRD0411HT003.namprd04.prod.outlook.com ([10.255.130.38]) with mapi id 14.16.0152.000; Fri, 25 May 2012 17:11:26 +0000 From: Kelly Grizzle To: Melinda Shore , "scim@ietf.org" Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: AQHNL33HX/k3k5Flb0qGWMZ8dW6jIZbI7JkAgABgegCAAJA0AIAAMrkAgAD02gCAAocvgIAAjNIAgAB3F4CACsN6gIAAasCAgAAJhYCAAA1rgIAATn8AgAAE8ACAACR2AIAAgqaAgAAAbJA= Date: Fri, 25 May 2012 17:11:25 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C343722AA36F9@BL2PRD0411MB397.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.ciscoC86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> In-Reply-To: <4FBFB9B9.7000601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:11:32 -0000 > oauth was plagued with neither "simple" nor "cloud." Simplicity has been an overarching goal of SCIM since day one. Losing the = simplicity aspect would prevent adoption (see SPML). Will everything about= SCIM remain simple forever? No. Should we strive to keep the 80% case si= mple? Absolutely. I think that having this in the name helps to keep the = goals clear and guide design decisions. Sure ... this could just be highli= ghted in the charter, but I don't see the problem with keeping it in the na= me. In my mind simplicity is one of the most important aspects of this eff= ort. I understand that cloud is a loaded word and am fine with coming up with so= mething else here (cross-domain works for me). I 100% agree with Morteza that losing the SCIM acronym would cause much mor= e grief in the long run than the couple of plagued words. --Kelly From paul.madsen@gmail.com Fri May 25 10:20:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBD21F86F8 for ; Fri, 25 May 2012 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5aq2OJyWI6P for ; Fri, 25 May 2012 10:20:49 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4493121F86EF for ; Fri, 25 May 2012 10:20:49 -0700 (PDT) Received: by ghbg16 with SMTP id g16so684849ghb.31 for ; Fri, 25 May 2012 10:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=X6ro6fAc70LAffSxIBBTEvVSOhAi8yYANolxU17rNQE=; b=tE+rpBnH05vAIbPdNgb9aufw2UuCkhpLxtDbXMHnBlyJAZuaWU1XDvNJeJEboFWUKm bSMHMQEtT5CHE3TmfA+0Y/YsEvZoJpiqqupPPvlab0t5OKJcz1IrvCkRRWxuzdozpb9n 1sbGA9KQU68kWC6CwZ8p3p61MkGyj/19Gxzoyfu8591GHtueXWnwo0smBtFVAEyqeGVg cf3ydt/4eWH48MxxY27RuAhgMBrL8GzWEtrNxID2v7beJtqHFisYcJgNa2zuj2tDAqOK lVNlMgPjZZ5SMgm3kexvqXm7UTzxM/GIDvNJzZOIE7KegQnRCg8Y188t7ISJo0JccVFO TxOQ== Received: by 10.60.32.113 with SMTP id h17mr3917772oei.40.1337966448718; Fri, 25 May 2012 10:20:48 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id k7sm2465639obn.19.2012.05.25.10.20.47 (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 10:20:47 -0700 (PDT) Message-ID: <4FBFBF6E.9030202@gmail.com> Date: Fri, 25 May 2012 13:20:46 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> In-Reply-To: <4FBFB9B9.7000601@gmail.com> Content-Type: multipart/alternative; boundary="------------080401090202000208080604" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:20:52 -0000 This is a multi-part message in MIME format. --------------080401090202000208080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit is not 'open' just as amorphous? was there a similar naming debate 3 years ago? On 5/25/12 12:56 PM, Melinda Shore wrote: > On 5/25/12 1:08 AM, Paul Madsen wrote: >> I will note that OAuth was neither particularly 'open' nor exclusively >> for 'authorization' but that name was able to persist into IETF .... > > oauth was plagued with neither "simple" nor "cloud." > > Melinda > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------080401090202000208080604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit is not 'open' just as amorphous? was there a similar naming debate 3 years ago?



On 5/25/12 12:56 PM, Melinda Shore wrote:
On 5/25/12 1:08 AM, Paul Madsen wrote:
I will note that OAuth was neither particularly 'open' nor exclusively
for 'authorization' but that name was able to persist into IETF ....

oauth was plagued with neither "simple" nor "cloud."

Melinda

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------080401090202000208080604-- From stpeter@stpeter.im Fri May 25 10:24:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92621F875C for ; Fri, 25 May 2012 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN7E3Q4mEqZJ for ; Fri, 25 May 2012 10:24:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8921F8707 for ; Fri, 25 May 2012 10:24:17 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C02B84005A; Fri, 25 May 2012 11:40:29 -0600 (MDT) Message-ID: <4FBFC040.1020607@stpeter.im> Date: Fri, 25 May 2012 11:24:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Madsen References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <4FBFBF6E.9030202@gmail.com> In-Reply-To: <4FBFBF6E.9030202@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:24:18 -0000 On 5/25/12 11:20 AM, Paul Madsen wrote: > is not 'open' just as amorphous? Sure. As I said, people can complain about anything. "Simple", "Secure", "Open", "Robust", "Scalable", and the like are typically derided as marketing fluff. > was there a similar naming debate 3 > years ago? No. Peter -- Peter Saint-Andre https://stpeter.im/ From melinda.shore@gmail.com Fri May 25 10:29:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0651321F8631 for ; Fri, 25 May 2012 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIavcnt3mXhx for ; Fri, 25 May 2012 10:29:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93C7D21F861B for ; Fri, 25 May 2012 10:29:13 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2067116pbc.31 for ; Fri, 25 May 2012 10:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f+unTFb0DnWmB3GwV0eDIUm0oJtCbePRnxl58MJ3ZyY=; b=SBngm505bg1JfUcEoK6XUMm6Nr0BYUpbc96yQic+Q9pwzLRbzxx7wtUEkw2abGB2+6 lVDGIHxwApccW+VFR9B+EV0z8ZzPKvyiqUtup5xmv4jY/NWgYtFeDnRkI59rVKaoR4mg RthWJKn441QqI5TwbLKGTkC/EoTJlzJqJ47qWVyA/YdqptPEkW9klII++kHNv0KB8WA8 guGlasX/1cNrX9J0wXvvGXKDdOitQzNA2b+ri5uZ/yWi3fDdZWak/C8Z/BGphSgJHEtV jQnJQ5EAKuzccopS3Nr/NGHigTz32TLunlKfXIkBKG+F3oyDSYoKl+MrV8oSqa5OkkrY aegw== Received: by 10.68.236.129 with SMTP id uu1mr34405715pbc.77.1337966953241; Fri, 25 May 2012 10:29:13 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id ka5sm9663109pbb.37.2012.05.25.10.29.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 10:29:12 -0700 (PDT) Message-ID: <4FBFC166.6090307@gmail.com> Date: Fri, 25 May 2012 09:29:10 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kelly Grizzle References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.ciscoC86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <56C3C758F9D6534CA3778EAA1E0C343722AA36F9@BL2PRD0411MB397.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343722AA36F9@BL2PRD0411MB397.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:29:15 -0000 On 5/25/12 9:11 AM, Kelly Grizzle wrote: > Simplicity has been an overarching goal of SCIM since day one. Losing > the simplicity aspect I'm not saying "Using the word 'simple' in a protocol name is problematic, so let's develop a hairball protocol." Making a protocol as simple as possible (but no simpler) should always be a goal of any protocol. *Any* protocol. There are certain words that are problematic in protocol names. They include "secure," "scalable," and, yes, "simple." They provide no discriminatory value and typically do not really describe the protocol they're being used to describe. Off the top of my head I can't think of a security protocol that uses "secure" as an adjective in its name (not saying there isn't one, just that typically security protocol names are descriptive of the protocol and don't include the word "secure"). Also, consider SIP. When it came along everybody said "Isn't it outstanding to have a much simpler alternative to H.323?" And look at it now. Melinda From stpeter@stpeter.im Fri May 25 10:38:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6CE21F875C for ; Fri, 25 May 2012 10:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UrA4WRO1PJF for ; Fri, 25 May 2012 10:38:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2415B21F8752 for ; Fri, 25 May 2012 10:38:21 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 229054005A; Fri, 25 May 2012 11:54:33 -0600 (MDT) Message-ID: <4FBFC38B.4020509@stpeter.im> Date: Fri, 25 May 2012 11:38:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melinda Shore References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B2D41@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.ciscoC86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <56C3C758F9D6534CA3778EAA1E0C343722AA36F9@BL2PRD0411MB397.namprd04.prod.outlook.com> <4FBFC166.6090307@gmail.com> In-Reply-To: <4FBFC166.6090307@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:38:21 -0000 On 5/25/12 11:29 AM, Melinda Shore wrote: > I can't think of a security protocol that uses "secure" as an > adjective in its name The SIDR WG is building "Secure Inter-Domain Routing". It's in the Routing Area, but it's a security protocol. Searching http://tools.ietf.org/wg/concluded for "secure" or "security" leads to other interesting results (e.g., "Secure Shell"). Peter -- Peter Saint-Andre https://stpeter.im/ From phil.hunt@oracle.com Fri May 25 10:41:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF4E21F875C for ; Fri, 25 May 2012 10:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcAoXX-WGa8T for ; Fri, 25 May 2012 10:41:17 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC821F8759 for ; Fri, 25 May 2012 10:41:17 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4PHfFQ0011251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 May 2012 17:41:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4PHfF6q013345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 17:41:15 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4PHfEZp023101; Fri, 25 May 2012 12:41:14 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 May 2012 10:41:14 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4FBFC040.1020607@stpeter.im> Date: Fri, 25 May 2012 10:41:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F54C7E4-C2FF-4D2C-977E-8750725C2A8E@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <4FBFBF6E.9030202@gmail.com> <4FBFC040.1020607@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim@ietf.org, Paul Madsen Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:41:18 -0000 It's time for the IESG to decide to ignore the group consensus or not. We've debated this about 4 times there has never been consensus for a = new name - let alone new words for the same acronym. I'd say the = opposite has now happened with the send backs -- there is now a very = hardened consensus around the name SCIM.=20 Form the WG or not. Choose the name the IESG deems appropriate. Please, let's move on. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-25, at 10:24 AM, Peter Saint-Andre wrote: > On 5/25/12 11:20 AM, Paul Madsen wrote: >> is not 'open' just as amorphous?=20 >=20 > Sure. As I said, people can complain about anything. "Simple", = "Secure", > "Open", "Robust", "Scalable", and the like are typically derided as > marketing fluff. >=20 >> was there a similar naming debate 3 >> years ago? >=20 > No. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Fri May 25 10:49:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4137821F8776 for ; Fri, 25 May 2012 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMzQdY5Wxovf for ; Fri, 25 May 2012 10:49:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 852C621F8773 for ; Fri, 25 May 2012 10:49:01 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2DB64005A; Fri, 25 May 2012 12:05:13 -0600 (MDT) Message-ID: <4FBFC60C.2030107@stpeter.im> Date: Fri, 25 May 2012 11:49:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:49:02 -0000 On 5/11/12 7:55 AM, Barry Leiba wrote: Do we have revised text that addresses the first three points? > 4. The name did come up (I told you...). It's not getting in the way, > at least not yet, but folks are balking at both the "simple" and the > "cloud" parts. They wonder if there isn't a way to keep "scim", but > to make up something new that it can stand for. Keep in mind that > this is a minor point, though -- the other three above need to be > fixed. It seems that several folks have posted proposed names that would overcome the concerns about "simple" and "cloud". Can we perhaps move on from this naming kerfuffle? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri May 25 10:53:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C08521F871A for ; Fri, 25 May 2012 10:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJB0vFZAY+v5 for ; Fri, 25 May 2012 10:53:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F18C921F8712 for ; Fri, 25 May 2012 10:53:57 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E7CD4005A; Fri, 25 May 2012 12:10:10 -0600 (MDT) Message-ID: <4FBFC734.1080204@stpeter.im> Date: Fri, 25 May 2012 11:53:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phil Hunt References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <4FBFBF6E.9030202@gmail.com> <4FBFC040.1020607@stpeter.im> <4F54C7E4-C2FF-4D2C-977E-8750725C2A8E@oracle.com> In-Reply-To: <4F54C7E4-C2FF-4D2C-977E-8750725C2A8E@oracle.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:53:58 -0000 On 5/25/12 11:41 AM, Phil Hunt wrote: > It's time for the IESG to decide to ignore the group consensus or > not. > > We've debated this about 4 times there has never been consensus for a > new name - let alone new words for the same acronym. I'd say the > opposite has now happened with the send backs -- there is now a very > hardened consensus around the name SCIM. > > Form the WG or not. Choose the name the IESG deems appropriate. > > Please, let's move on. Well, the minutes from the relevant IESG meeting have not yet been posted, so we don't really know the rationale for concerns about the words "simple" and "cloud" in the name: http://www.ietf.org/iesg/minutes/2012/index.html IMHO this naming kerfuffle is distracting from the real work to be done here, but I'll wait for the IESG minutes before saying more. Peter -- Peter Saint-Andre https://stpeter.im/ From melinda.shore@gmail.com Fri May 25 11:02:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ED721F8724 for ; Fri, 25 May 2012 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHeqZLM19KGU for ; Fri, 25 May 2012 11:02:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1521F8720 for ; Fri, 25 May 2012 11:02:43 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2099321pbc.31 for ; Fri, 25 May 2012 11:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fCKkDYGmdPxIiJO7H9s+sHi356nr8x9bcCv4ioG9kPU=; b=ZJ+rhFs4wZ5ySJf8Cfqnv9LPKti/VyEIVf/RUoyYQoeJoDJ21GstuHg7DZvUXbz+L8 ZZbWtx/Govrah9UOrNc8/sa1L+ZQAtwwRgu0f223eUw4OqK12kzol/XFeGGP6GEn2Uxc rge87o8yXu9J0Meb1WHGgqcCooCiT2QRyXNwzeA049848EKMX3km8lNqLvPrf5SyHG13 R+cuLdExO5X0hK/0uz9cClzm2SFnLZgvy60SHtes8ym4Rf6SQ5rBu6gUciTkCw6VAchu WrMlOYZaIq2xhRozC3+43VMJVoQuaflO8vSA/U7YFopwy+rEUrtA3VBYlIw5j/2OyIKO 9txw== Received: by 10.68.225.69 with SMTP id ri5mr34401383pbc.147.1337968962935; Fri, 25 May 2012 11:02:42 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id qt8sm9744938pbb.32.2012.05.25.11.02.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 11:02:42 -0700 (PDT) Message-ID: <4FBFC93F.1060705@gmail.com> Date: Fri, 25 May 2012 10:02:39 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE014B30D8@XMB-RCD-313.cisco.com> <4FB1ACFA.1080107@stpeter.im> <93C6FB63F046384C86EC8F7F3FFEC7BE015397EA@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE01539B75@XMB-RCD-313.cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F207B87889@szxeml525-mbx.china.huawei.com> <1337911181.52591.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FBF2D8A.9090003@gmail.com> <4FBF4C20.7070406@gmail.com> <4FBFB9B9.7000601@gmail.com> <4FBFBF6E.9030202@gmail.com> <4FBFC040.1020607@stpeter.im> <4F54C7E4-C2FF-4D2C-977E-8750725C2A8E@oracle.com> In-Reply-To: <4F54C7E4-C2FF-4D2C-977E-8750725C2A8E@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:02:43 -0000 On 5/25/12 9:41 AM, Phil Hunt wrote: > [T]here is now a very hardened consensus around the name SCIM. Not in any meaningful sense of the word "consensus." Welcome to the IETF. The good news is that it's much easier to get agreement on technical questions than it is on working group names. Melinda From barryleiba@gmail.com Fri May 25 11:13:50 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E11F21F876D for ; Fri, 25 May 2012 11:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbxPjU4duC4w for ; Fri, 25 May 2012 11:13:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A531721F8768 for ; Fri, 25 May 2012 11:13:48 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1871104obb.31 for ; Fri, 25 May 2012 11:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wafff0VwCB/EU7EOCdnYjwK0sWuoUX95mFO0L4Dz1LU=; b=hS6wTurUOdawDkN06ZDHb1b/1GlYd8yk624FE7TKfq8qlAxt5+F5g0LrnymEBvkNcJ d81KL2lSdWbko1XWsFCZ6LRg0hsk1ncnaL0+KEZxVaPbcYL6Js4uaeevVwVbUzWGIgYG j6i6e+GnhXoSgqLSxPTnGrmbdNlkx8ruuQImjhy2PSM5JK5gzzhUGAinqC0vDtdZ6xu2 OCdcleKpjUW9EXghhtfLFTYd2XUkXbRBqdnoVaHvrYeZpVyO8QadQGq1NHCbLd9IQIhu lG4BrbtBGn70MruU2QDFvViH1afewrslVLcWMg4a/7Ins+fD3OFmMyMLCofPPQWXL8Pb v7Aw== MIME-Version: 1.0 Received: by 10.60.29.41 with SMTP id g9mr4042162oeh.18.1337969623942; Fri, 25 May 2012 11:13:43 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.21.35 with HTTP; Fri, 25 May 2012 11:13:43 -0700 (PDT) In-Reply-To: <4FBFC60C.2030107@stpeter.im> References: <4FBFC60C.2030107@stpeter.im> Date: Fri, 25 May 2012 14:13:43 -0400 X-Google-Sender-Auth: NR2__62wF8-hSVlDUTwRRG05CJ8 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:13:50 -0000 > Do we have revised text that addresses the first three points? We're fine with that, and the IESG seems satisfied with the content of the charter. > It seems that several folks have posted proposed names that would > overcome the concerns about "simple" and "cloud". Can we perhaps move on > from this naming kerfuffle? I posted to the IESG list this morning, and am waiting for responses. I think we can use one of the names that keeps the "SCIM" acronym, yes. I'll post back when I know something for sure. Barry From stpeter@stpeter.im Fri May 25 11:14:48 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAD421F85DD for ; Fri, 25 May 2012 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLLZ40ut17BV for ; Fri, 25 May 2012 11:14:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0D21621F859F for ; Fri, 25 May 2012 11:14:48 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1E4A14005A; Fri, 25 May 2012 12:31:00 -0600 (MDT) Message-ID: <4FBFCC16.5030500@stpeter.im> Date: Fri, 25 May 2012 12:14:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FBFC60C.2030107@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:14:48 -0000 On 5/25/12 12:13 PM, Barry Leiba wrote: >> Do we have revised text that addresses the first three points? > > We're fine with that, and the IESG seems satisfied with the content of > the charter. Excellent. >> It seems that several folks have posted proposed names that would >> overcome the concerns about "simple" and "cloud". Can we perhaps move on >> from this naming kerfuffle? > > I posted to the IESG list this morning, and am waiting for responses. > I think we can use one of the names that keeps the "SCIM" acronym, > yes. I'll post back when I know something for sure. Thanks for following up and for letting us know. Peter -- Peter Saint-Andre https://stpeter.im/ From igor.faynberg@alcatel-lucent.com Fri May 25 14:07:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65B21F880F for ; Fri, 25 May 2012 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.19 X-Spam-Level: X-Spam-Status: No, score=-10.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaJOPfL+D8Jt for ; Fri, 25 May 2012 14:07:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DB67F21F8813 for ; Fri, 25 May 2012 14:07:56 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4PL7txL017250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 May 2012 16:07:55 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4PL7taj029772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 May 2012 16:07:55 -0500 Received: from [135.244.3.41] (faynberg.lra.lucent.com [135.244.3.41]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4PL7sXi003526; Fri, 25 May 2012 16:07:54 -0500 (CDT) Message-ID: <4FBFF4AA.9020508@alcatel-lucent.com> Date: Fri, 25 May 2012 17:07:54 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020102030805070305070605" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:07:58 -0000 This is a multi-part message in MIME format. --------------020102030805070305070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Trevis, A question (out of curiosity, since you have mentioned that all examples are non-normative): Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment a JSON structure here? With thanks, Igor On 5/25/2012 5:01 AM, Travis Spencer wrote: > Hi All, > > Please find below a proposal for changing how entitlements are handled > in SCIM. This proposal is based on various discussions that have been > happening in the community, so hopefully there is agreement on the > general idea. If there are objections or details that need to be > worked out, I welcome the feedback. > > To be added to .well-known, SP Config, or whatever we end up w/ in the > long-run (i.e., section 9 of the draft): > > The following multi-valued attribute is defined in addition to the > common attributes defined in Core Schema: > > entitlementSchemes > > A complex type that specifies supported Entitlement Scheme properties. > Instead of the standard Canonical Value for type, this attribute > defines the following Canonical Values to represent common schemes: > none and basic. REQUIRED. > > name > > The common Entitlement Scheme name; e.g., XACML. REQUIRED. > > description > > A description of the Entitlement Scheme. REQUIRED. > > specUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's > specification. OPTIONAL. > > documentationUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's usage > documentation. OPTIONAL. > > When basic is supported, a service provider MUST also support the > following single value attribute which defines the entitlements that > it supports. > > basicEntitlements > > A list of string values that represent the entitlements that the > service provider supports. REQUIRED if the basic Entitlement Scheme is > supported. > > To replace entitlements in section 6.2 of the core schema doc: > > entitlements > > A complex attribute containing the entitlements of a User. > Entitlements are the rights that a User has at the Service Provider as > expressed according to the policy language stipulated by the type > sub-attribute. A basic syntax is defined in this specification that > allows the Client to specify a list of entitlements as strings. There > are NO canonical values specified, but a Client can learn what values > are supported by requesting the Service Provider Configuration > Resource and examining the list found in the basicEntitlements attribute. > > type > > A string indicating the type of policy language. The only acceptable > canonical value is basic. REQUIRED. If the type of policy is not > understood, the Service Provider MUST return an HTTP 400, bad request. > > value > > The entitlements of the user. If the type is basic, this MUST be a > list of strings where the elements are from the list of supported > entitlements defined in the Service Provider's basicEntitlements > schema attribute. If the type is NOT basic, then the value MUST be a > complex object that the Service Provider is expected to know how to > process. If the complex object cannot be processed according to the > syntax of the policy language specified in the type attribute, the > Service Provider MUST return an HTTP 400, bad request. > > A non-normative examples of using the basic Entitlement Scheme is as > follows: > > { > > "entitlements" : { > > "type": "basic", > > "value" : [ "calendar", "email", "spreadsheet" ] > > } > > } > > Service Providers MAY support additional policy languages instead of > or in addition to the basic one define herein. For example, a Service > Provider may support XACML and the Client may send the entitlements of > a User in accordance to that specification as in the following > non-normative example: > > { > > "entitlements" : { > > "type" : "xacml", > > "value" : { /* XACML policy encoded in JavaScript */ } > > } > > } > > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | www.pingidentity.com > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------020102030805070305070605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Trevis,

 A question (out of curiosity, since you have mentioned that all examples are non-normative):  Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment  a JSON structure here?

With thanks,

Igor


On 5/25/2012 5:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

 

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

 

To replace entitlements in section 6.2 of the core schema doc:

 

entitlements

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{

  "entitlements" : {

     "type": "basic",

      "value" : [ "calendar", "email", "spreadsheet" ]

  }

}

 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

 

{

  "entitlements" : {

         "type" : "xacml",

         "value" : { /* XACML policy encoded in JavaScript */ }

   }

}


--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer
 



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------020102030805070305070605-- From Chris.Phillips@canarie.ca Fri May 25 21:02:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC86711E807F; Fri, 25 May 2012 21:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jDFBTtBLK+k; Fri, 25 May 2012 21:02:47 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id B16FC11E8072; Fri, 25 May 2012 21:02:46 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Sat, 26 May 2012 00:02:36 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Sat, 26 May 2012 00:02:34 -0400 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac069GIIGPW1Ezu8Q5yxq1h1NVT+jQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , Trey Drake , IESG , Eliot Lear , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 04:02:48 -0000 +1 to Morteza's proposal. (apologies as my reply is a few hours behind) There is an opportunity here for the IETF to capitalize on the momentum of the existing adopters over the past year and those in progress as well. A (drastic) name change now just dilutes and fragments the environment and will be a burden on all to explain it in perpetuity. Attending and presenting(on SCIM actually[1]) at TERENA in Iceland this past week, the theme I heard from some of the IETF related tracks was the concern and sounding the alarm for lack of adoption or not staying current on protocols. (IPv6 & what is (not)happening, simply enabling all the features of BGP spec to increase security of the routing fabric to name a few topics...). In the world of provisioning, the lack of adoption problem is there in spades and hurts us all. This is why the SCIM pragmatic simplicity approach has traction where others don't. Changing the name at this stage in the game will result in dissipating any momentum gained over the past year. I'm hopeful that as we move on from the naming topic that we can apply the same energy and debate to the technical topics in SCIM... Chris. [1] https://tnc2012.terena.org/core/presentation/125 On 12-05-25 10:05 AM, "Trey Drake" wrote: >+1 >On May 25, 2012, at 3:35 AM, Morteza Ansari (moransar) wrote: > >> I think we have gone around the block with this discussion a few times. >> I am going to repeat my last response to the topic: >>=20 >> Personally speaking I still think we should stick with SCIM. If the >> current traction of SCIM v1 is any indication, by the time v2 is >> standardized, there will be quite a few implementations of SCIM v1 in >> the wild (we are almost at 10 distinct implementations now). A rename >> between v1 and v2 will only result in confusion and 10 years from now we >> will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber >> vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10 >> fold by causing confusion. If we *really* must change something, let's >> stay with SCIM and change "cloud" to any other word that starts with "c" >> and move forward with the real work ahead. >>=20 >>=20 >> Cheers, >> Morteza >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >> Eliot Lear >> Sent: Thursday, May 24, 2012 11:35 AM >> To: Barry Leiba >> Cc: scim@ietf.org; 'IESG' >> Subject: Re: [scim] Feedback on the charter from IESG and IAB >>=20 >> Barry, >>=20 >> I'm sorry but arguing over a name is not something that should be done >> by the IESG. It impacts the wire not one little bit, and it's >> disrespectful to those who brought the work into the IETF. It also >> wastes the time of many people diverting them from what I'm sure we'd >> all prefer them to work on- things that DO effect the wire. Honestly, >> can't we PLEASE move along? >>=20 >> Eliot >>=20 >> On 5/24/12 8:15 PM, Barry Leiba wrote: >>> I have good news and bad news from the IESG telechat today. >>>=20 >>> The good news is that the IESG is happy with the charter. The only >>> change they asked for was a one-word addition to make it clear that >>> "authorization" will also be included in the security bit: >>>=20 >>> OLD >>> In addition, the working group will ensure that the SCIM protocol >>> embodies good security practices. Given both the sensitivity of the >>> information being conveyed in SCIM messages and the regulatory >>> requirements regarding the privacy of personally identifiable >>> information, the working group will pay particular attention to >>> issues >>> | around authenticity and privacy. >>>=20 >>> NEW >>> In addition, the working group will ensure that the SCIM protocol >>> embodies good security practices. Given both the sensitivity of the >>> information being conveyed in SCIM messages and the regulatory >>> requirements regarding the privacy of personally identifiable >>> information, the working group will pay particular attention to >>> issues >>> | around authorization, authenticity, and privacy. >>>=20 >>>=20 >>> The bad news is on the name, "SCIM": that dog will not hunt. It's not >>=20 >>> just Pete, who fought it on this list: at least three other ADs want >>> the name changed before we can approve the charter for external >>> review. >>>=20 >>> The IESG is working on an alternative name -- one that was suggested >>> was "Inter-Domain User Identity Management", giving a working group >>> acronym of "iduim". >>>=20 >>> This group can, of course, propose other names... in the end, the IESG >>=20 >>> will pick the name, though it would be nice to have agreement from the >>=20 >>> community. But here's the thing: >>> - Give up on "simple". There've been too many protocols with that in >>> the name, and none of them are. >>> - Give up on "cloud". This will certainly be used by cloud providers, >>=20 >>> but is not specific to that use, and the name "cloud" carries too much >>=20 >>> baggage and too many other assumptions. >>> - "Identity management" by itself is a broader topic than what we're >>> talking about here. "User identity management" might work (see the >>> suggestion above), as might other formulations you may come up with. >>>=20 >>> Barry >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri May 25 21:39:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2911E809B for ; Fri, 25 May 2012 21:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pSE2sFgkMYj for ; Fri, 25 May 2012 21:39:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75D6811E8098 for ; Fri, 25 May 2012 21:39:44 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2539201pbc.31 for ; Fri, 25 May 2012 21:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Wpyy+FIKrl5bq3MKjpcMPSivct5jzsB2DYJ0nbgOoX8=; b=hmxti7kpJwlvR48MY0Ld0zfs89u61sRx+WtxiBIsqfApJ7sEF9kaVU2VEIRIX+NDq8 VaitOc3lfbT2FRYVUQbhWnp2uIlQfL8yH7u/2/vWgBH5OP59lvUE2Q0Rc+0b1nXx8ElZ Iem1cd4oR2y4aVvXMYcdja4Xby4ADYqFmU7Y0UH2cvwdg/uoRUHSn3ZsRgKshWSeJc+a FYSTB5ByMklfxwCyHUgn/soK9WEl1MUd7r7WcYUnFo1c6vy6XmT3YxvUvMMRwWRDNafE +Z7WpH2YNx2RiumggtPXoZ827bcqQom+FPDSJWrpkI8hrLYsEXHCGKrYPaH0KdLxTSjY DIiQ== Received: by 10.68.232.232 with SMTP id tr8mr4226230pbc.73.1338007184212; Fri, 25 May 2012 21:39:44 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id pq1sm11280544pbb.5.2012.05.25.21.39.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 21:39:43 -0700 (PDT) Message-ID: <4FC05E8D.10206@gmail.com> Date: Fri, 25 May 2012 20:39:41 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 04:39:46 -0000 On 5/25/12 8:02 PM, Chris Phillips wrote: > In the world of provisioning, the lack of adoption problem is there in > spades and hurts us all. This is why the SCIM pragmatic simplicity > approach has traction where others don't. Changing the name at this stage > in the game will result in dissipating any momentum gained over the past > year. I'm not sure I find this kind of hyperbole particularly helpful. While there continues to be some confusion about whether it's "TLS" or "SSL," TLS seems to be doing just fine in the marketplace. The important thing is identifying a problem well and solving it well. I'm just fine with kicking this whole thing to the IESG and telling them that if they've got a problem with "scim" (and I agree that there are problems with both "simple" and "cloud"), it's up to them to come up with something that's descriptive and at least acceptable, and accepting it as a mediated solution. Sometimes coming to "consensus" means saying "I don't agree, but I can live with it." I feel pretty strongly that both "simple" and "cloud" need to go, and while I really dislike tortured acronyms I can live with the IESG or someone else coming up with something ghastly that acronymifies as "scim" in the interest of getting this resolved. Melinda From michael.brenner@alcatel-lucent.com Sat May 26 08:52:50 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8690D21F856F for ; Sat, 26 May 2012 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ChX4nqDj6Cs for ; Sat, 26 May 2012 08:52:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E552621F84E6 for ; Sat, 26 May 2012 08:52:49 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4QFqj11025390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 May 2012 10:52:45 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4QFqjds027143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 26 May 2012 10:52:45 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Sat, 26 May 2012 10:52:45 -0500 From: "Brenner, Michael Ralf (Michael)" To: Melinda Shore , "scim@ietf.org" Date: Sat, 26 May 2012 10:52:44 -0500 Thread-Topic: [scim] Feedback on the charter from IESG and IAB Thread-Index: Ac06+ZbZI+FDYGwmSwK0Z5FAi+kvKAAXKIVw Message-ID: <219947F0B2242843A0A1E62FDB510DC026CE6AC00C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4FC05E8D.10206@gmail.com> In-Reply-To: <4FC05E8D.10206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 15:52:50 -0000 Considering SCIM's origin/history, I am also in favor of AT LEAST NOT chang= ing the acronym. Seems so far that if that is pre-condition for many in thi= s list, it is still us that should find a matching name, and not the IESG (= I am not sure why they would know better what this WG intends to do). I had the feeling that Cross-domain may not have significant opposition wit= hin this group (although it still may in IESG, and then we need to come up = with something else for the "C", for example somebody suggested CRUD). Howe= ver, so far we failed to get even average support for anything for the "S" = (scalable, secure, simple, synchronous, etc... did not seem to gain support= ). But how about Stateless? This would be indicative of the intent of the grou= p to use REST architectural style. Stateless Cross-domain Identity Management? OR Stateless CRUD Identity Management? Going into IESG with 2 options, both having removed the contentious Simple = and Cloud may entice them to accept one of them. Michael -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mel= inda Shore Sent: Saturday, May 26, 2012 12:40 AM To: scim@ietf.org Subject: Re: [scim] Feedback on the charter from IESG and IAB On 5/25/12 8:02 PM, Chris Phillips wrote: > In the world of provisioning, the lack of adoption problem is there in > spades and hurts us all. This is why the SCIM pragmatic simplicity > approach has traction where others don't. Changing the name at this stag= e > in the game will result in dissipating any momentum gained over the past > year. I'm not sure I find this kind of hyperbole particularly helpful. While there continues to be some confusion about whether it's "TLS" or "SSL," TLS seems to be doing just fine in the marketplace. The important thing is identifying a problem well and solving it well. I'm just fine with kicking this whole thing to the IESG and telling them that if they've got a problem with "scim" (and I agree that there are problems with both "simple" and "cloud"), it's up to them to come up with something that's descriptive and at least acceptable, and accepting it as a mediated solution. Sometimes coming to "consensus" means saying "I don't agree, but I can live with it." I feel pretty strongly that both "simple" and "cloud" need to go, and while I really dislike tortured acronyms I can live with the IESG or someone else coming up with something ghastly that acronymifies as "scim" in the interest of getting this resolved. Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From paul.madsen@gmail.com Sun May 27 15:23:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37221F854E for ; Sun, 27 May 2012 15:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DloKFKPPTGeO for ; Sun, 27 May 2012 15:23:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4125121F8548 for ; Sun, 27 May 2012 15:23:00 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5507228obb.31 for ; Sun, 27 May 2012 15:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ZWg1sEMmeG+W/dBWtRgYgJDqTpULtppswa7GR+4g0Cs=; b=0gvtWtawp9Q38O1l/EiVHAf7V+N5qs13MQeXMluJ9PORzWPudBy5dDu5odl6qz/ecW /EWstb54WDnYB+DEM4DZ0Cnp7Ufl7TVb09tKDr48qxSLOF87CBifESfHe/PeT3YakERb /BaPTMHPagXLoq3W/8biZ3ZFbnuxBavJ5V3SfXa7Yi3uqpYKDGLONiZHmmhsMoL8mfLK 7Ud0rEWMRpj9EjfVQrMtzSMTae9VTVtL6BNtqX0UYzpn3iCUxiqkIdZPgQeovZJqqNBn s4UdiuiZ8r0+i6mqS7Hvxs7FSzdPEV6HsV0iHBZ5mNTTjQXqCzuflo0oI2gqhl7zkpqx eCEw== Received: by 10.50.173.40 with SMTP id bh8mr3175422igc.65.1338157379816; Sun, 27 May 2012 15:22:59 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id wh8sm8309964igb.11.2012.05.27.15.22.56 (version=SSLv3 cipher=OTHER); Sun, 27 May 2012 15:22:57 -0700 (PDT) Message-ID: <4FC2A93F.1090300@gmail.com> Date: Sun, 27 May 2012 18:22:55 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <4FC05E8D.10206@gmail.com> <219947F0B2242843A0A1E62FDB510DC026CE6AC00C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC026CE6AC00C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------090303090800090406070805" Subject: Re: [scim] Feedback on the charter from IESG and IAB X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 22:23:01 -0000 This is a multi-part message in MIME format. --------------090303090800090406070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit + 1 to Stateless CRUD Identity Management next issue? On 5/26/12 11:52 AM, Brenner, Michael Ralf (Michael) wrote: > Considering SCIM's origin/history, I am also in favor of AT LEAST NOT changing the acronym. Seems so far that if that is pre-condition for many in this list, it is still us that should find a matching name, and not the IESG (I am not sure why they would know better what this WG intends to do). > > I had the feeling that Cross-domain may not have significant opposition within this group (although it still may in IESG, and then we need to come up with something else for the "C", for example somebody suggested CRUD). However, so far we failed to get even average support for anything for the "S" (scalable, secure, simple, synchronous, etc... did not seem to gain support). > > But how about Stateless? This would be indicative of the intent of the group to use REST architectural style. > > Stateless Cross-domain Identity Management? > OR > Stateless CRUD Identity Management? > > Going into IESG with 2 options, both having removed the contentious Simple and Cloud may entice them to accept one of them. > > Michael > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Saturday, May 26, 2012 12:40 AM > To: scim@ietf.org > Subject: Re: [scim] Feedback on the charter from IESG and IAB > > On 5/25/12 8:02 PM, Chris Phillips wrote: >> In the world of provisioning, the lack of adoption problem is there in >> spades and hurts us all. This is why the SCIM pragmatic simplicity >> approach has traction where others don't. Changing the name at this stage >> in the game will result in dissipating any momentum gained over the past >> year. > I'm not sure I find this kind of hyperbole particularly > helpful. While there continues to be some confusion > about whether it's "TLS" or "SSL," TLS seems to be doing > just fine in the marketplace. The important thing is > identifying a problem well and solving it well. > > I'm just fine with kicking this whole thing to the IESG and > telling them that if they've got a problem with "scim" (and > I agree that there are problems with both "simple" and > "cloud"), it's up to them to come up with something that's > descriptive and at least acceptable, and accepting it as > a mediated solution. Sometimes coming to "consensus" means > saying "I don't agree, but I can live with it." I feel > pretty strongly that both "simple" and "cloud" need to go, > and while I really dislike tortured acronyms I can live > with the IESG or someone else coming up with something ghastly > that acronymifies as "scim" in the interest of getting this > resolved. > > Melinda > _______________________________________________ > 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 --------------090303090800090406070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit + 1 to Stateless CRUD Identity Management

next issue?

On 5/26/12 11:52 AM, Brenner, Michael Ralf (Michael) wrote: 
Considering SCIM's origin/history, I am also in favor of AT LEAST NOT changing the acronym. Seems so far that if that is pre-condition for many in this list, it is still us that should find a matching name, and not the IESG (I am not sure why they would know better what this WG intends to do).

I had the feeling that Cross-domain may not have significant opposition within this group (although it still may in IESG, and then we need to come up with something else for the "C", for example somebody suggested CRUD). However, so far we failed to get even average support for anything for the "S" (scalable, secure, simple, synchronous, etc... did not seem to gain support).

But how about Stateless? This would be indicative of the intent of the group to use REST architectural style.

Stateless Cross-domain Identity Management?
OR
Stateless CRUD Identity Management?

Going into IESG with 2 options, both having removed the contentious Simple and Cloud may entice them to accept one of them.

Michael

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore
Sent: Saturday, May 26, 2012 12:40 AM
To: scim@ietf.org
Subject: Re: [scim] Feedback on the charter from IESG and IAB

On 5/25/12 8:02 PM, Chris Phillips wrote:

In the world of provisioning, the lack of adoption problem is there in
spades and hurts us all. This is why the SCIM pragmatic simplicity
approach has traction where others don't.  Changing the name at this stage
in the game will result in dissipating any momentum gained over the past
year.

I'm not sure I find this kind of hyperbole particularly
helpful.  While there continues to be some confusion
about whether it's "TLS" or "SSL," TLS seems to be doing
just fine in the marketplace.  The important thing is
identifying a problem well and solving it well.

I'm just fine with kicking this whole thing to the IESG and
telling them that if they've got a problem with "scim" (and
I agree that there are problems with both "simple" and
"cloud"), it's up to them to come up with something that's
descriptive and at least acceptable, and accepting it as
a mediated solution.  Sometimes coming to "consensus" means
saying "I don't agree, but I can live with it."  I feel
pretty strongly that both "simple" and "cloud" need to go,
and while I really dislike tortured acronyms I can live
with the IESG or someone else coming up with something ghastly
that acronymifies as "scim" in the interest of getting this
resolved.

Melinda
_______________________________________________
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
--------------090303090800090406070805-- From samuel@erdtman.se Sun May 27 23:52:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7811E8072 for ; Sun, 27 May 2012 23:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aJorhv6y4ti for ; Sun, 27 May 2012 23:52:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7756221F852E for ; Sun, 27 May 2012 23:52:25 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1985335lbb.31 for ; Sun, 27 May 2012 23:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DWEdB1jLVR278b3fyvMDPK8cqYb3ZU6WoDjyKiWXP5A=; b=NIyqwyzhsAhYyg9zUpzFvR4BLUscxA7lg/9C6OL6fKPDo5Nb/8c9qqeMiHRxeyUXAS bKcgzYUtt8ZfuQnLcT37r/7I65byfn5OATZqCwc69OdjjuJJ2iPjmhKwEBhUOKyuFJIB vGpKurlB090PMwPCfw2aN/QapctW4PVW5MPcXITrU9PsESWsNOuYpObVowC7pvCu7ceZ jvLun+qdfukqAqYWl/7v7uoBQLfigMe7Smlr3Uejll10Z9NYMot/FkCJ3w+igwyn+9/u v/gJsFiunCDliYUPYarF/jFfS9LGDEbGDyRAu0/1NmQUSC6xmIm4KB1mXpOgRs4AiHzO 4IYQ== MIME-Version: 1.0 Received: by 10.112.100.234 with SMTP id fb10mr3224313lbb.12.1338187944041; Sun, 27 May 2012 23:52:24 -0700 (PDT) Received: by 10.112.36.194 with HTTP; Sun, 27 May 2012 23:52:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 May 2012 08:52:24 +0200 Message-ID: From: Samuel Erdtman To: Travis Spencer Content-Type: multipart/alternative; boundary=f46d04016c290c1f5504c11329fa X-Gm-Message-State: ALoCoQkOJVq1ldJV3dBqyqJFxQielG1fmzXmdz5zRh0vEVnmHG+g3oqJPbFERkEknvp3M6zsvybM Cc: scim@ietf.org Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 06:52:29 -0000 --f46d04016c290c1f5504c11329fa Content-Type: text/plain; charset=ISO-8859-1 Great write-up, I have some thoughts regarding the examples and how the entitlements are encoded in the user object. As I understand it the packaging in your example would make entitlements to a new complex type. For simplicity reasons I would like to propose to use a multivalued string as follows: { "entitlements": [ { "type": "basic", "value": "calendar" }, { "type": "basic", "value": "email" }, { "type": "basic", "value": "spreadsheet" } ] } This representation would be a bit more verbode but no new type would be needed. However it would be possible to mix entitlements types since the type is placed individually on each entitlement. { "entitlements": [ { "type": "xacml", "value": "/*XACML policy*/" }, { "type": "basic", "value": "email" } ] } Further, if we add language saying that basic is the default type we could represent the entitlements list as follows: { "entitlements": [ "calendar", "email", "spreadsheet" ] } Thoughts? Cheers //Samuel On Fri, May 25, 2012 at 11:01 AM, Travis Spencer wrote: > Hi All, > > Please find below a proposal for changing how entitlements are handled in > SCIM. This proposal is based on various discussions that have been > happening in the community, so hopefully there is agreement on the general > idea. If there are objections or details that need to be worked out, I > welcome the feedback. > > To be added to .well-known, SP Config, or whatever we end up w/ in the > long-run (i.e., section 9 of the draft): > > > > The following multi-valued attribute is defined in addition to the common > attributes defined in Core Schema: > > > > entitlementSchemes > > > > A complex type that specifies supported Entitlement Scheme properties. > Instead of the standard Canonical Value for type, this attribute defines > the following Canonical Values to represent common schemes: none and basic. > REQUIRED. > > > > name > > > > The common Entitlement Scheme name; e.g., XACML. REQUIRED. > > > > description > > > > A description of the Entitlement Scheme. REQUIRED. > > > > specUrl > > > > An HTTP addressable URL pointing to the Entitlement Scheme's > specification. OPTIONAL. > > > > documentationUrl > > > > An HTTP addressable URL pointing to the Entitlement Scheme's usage > documentation. OPTIONAL. > > > > When basic is supported, a service provider MUST also support the > following single value attribute which defines the entitlements that it > supports. > > > > basicEntitlements > > > > A list of string values that represent the entitlements that the service > provider supports. REQUIRED if the basic Entitlement Scheme is supported. > > > > To replace entitlements in section 6.2 of the core schema doc: > > > > entitlements > > > > A complex attribute containing the entitlements of a User. Entitlements > are the rights that a User has at the Service Provider as expressed > according to the policy language stipulated by the type sub-attribute. A > basic syntax is defined in this specification that allows the Client to > specify a list of entitlements as strings. There are NO canonical values > specified, but a Client can learn what values are supported by requesting > the Service Provider Configuration Resource and examining the list found in > the basicEntitlements attribute. > > > > type > > > > A string indicating the type of policy language. The only acceptable > canonical value is basic. REQUIRED. If the type of policy is not > understood, the Service Provider MUST return an HTTP 400, bad request. > > > > value > > > > The entitlements of the user. If the type is basic, this MUST be a list of > strings where the elements are from the list of supported entitlements > defined in the Service Provider's basicEntitlements schema attribute. If > the type is NOT basic, then the value MUST be a complex object that the > Service Provider is expected to know how to process. If the complex object > cannot be processed according to the syntax of the policy language > specified in the type attribute, the Service Provider MUST return an HTTP > 400, bad request. > > > > A non-normative examples of using the basic Entitlement Scheme is as > follows: > > > > { > > "entitlements" : { > > "type": "basic", > > "value" : [ "calendar", "email", "spreadsheet" ] > > } > > } > > > > Service Providers MAY support additional policy languages instead of or in > addition to the basic one define herein. For example, a Service Provider > may support XACML and the Client may send the entitlements of a User in > accordance to that specification as in the following non-normative example: > > > > { > > "entitlements" : { > > "type" : "xacml", > > "value" : { /* XACML policy encoded in JavaScript */ } > > } > > } > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | www.pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --f46d04016c290c1f5504c11329fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great write-up, I have some thoughts regarding the examples and how the=A0e= ntitlements=A0are encoded in the user object.

As I under= stand it the packaging in your example would make=A0entitlements=A0to a new= complex type. For simplicity reasons I would like to propose to use a mult= ivalued string as follows:
{
=A0 "entitlements": [
=A0 =A0 {
=A0 =A0 =A0 &= quot;type": "basic",
=A0 =A0 =A0 "value"= : "calendar&= quot;=A0
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type&q= uot;: "basic",
=A0 =A0 =A0 "value": "email"=A0
=
=A0 =A0 },
=A0 =A0=A0{
=A0 =A0 =A0 "type": "basic",=
=A0 =A0 =A0 "value": "spreadsheet"=A0
=A0 =A0 }
=A0 ]
}
This=A0representation=A0would be a bit more verbode but no new type wo= uld be needed.=A0
However it would be possible to mix=A0entitleme= nts types since the type is placed=A0individually=A0on each=A0entitlement.<= /div>
{
=A0 "entitlements": [
=A0 =A0 {
=A0 =A0 =A0 &= quot;type": "xacml",
=A0 =A0 =A0 "value"= : "/*XACML policy= */"=A0
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type&q= uot;: "basic",
=A0 =A0 =A0 "value": "email"=A0
=
=A0 =A0 }
=A0 ]
}

Further, if we add la= nguage saying that basic is the default type we could represent the=A0entit= lements=A0list as follows:
{
=A0 "entitlements": [=A0&quo= t;calendar",= =A0"email&qu= ot;,=A0"spreadsheet= "=A0]
}

Thoughts?

Ch= eers
//Samuel



On Fri, May 25, 2012 at 11:01 AM, Travis Spencer <tspence= r@pingidentity.com> wrote:
Hi All,

Please find below= a proposal for changing how entitlements are handled in SCIM. This proposa= l is based on various discussions that have been happening in the community= , so=A0hopefully=A0there is agreement on the general idea. If there are obj= ections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., sec= tion 9 of the draft):

=A0

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

=A0

entitlementSchemes

=A0

A complex type that specifies supported Entitlement Scheme properties. Instea= d of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

=A0

name

=A0

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

=A0

description

=A0

A description of the Entitlement Scheme. REQUIRED.

=A0

specUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's specification= . OPTIONAL.

=A0

documentationUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's usage documen= tation. OPTIONAL.

=A0

When basic is supported, a service provider MUST also support the following sing= le value attribute which defines the entitlements that it supports.

=A0

basicEntitlements

=A0

A list of string values that represent the entitlements that the service prov= ider supports. REQUIRED if the basic Entitlement Scheme is supported.

=A0

To replace entitlements in section 6.2 of the core schema doc:

=A0

entitlements

=A0

A complex attribute containing the entitlements of a User. Entitlements are t= he rights that a User has at the Service Provider as expressed according to th= e policy language stipulated by the type sub-attribute. A basic syntax is def= ined in this specification that allows the Client to specify a list of entitleme= nts as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

=A0

type

=A0

A string indicating the type of policy language. The only acceptable canonica= l value is basic. REQUIRED. If the type of policy is not understood, the Serv= ice Provider MUST return an HTTP 400, bad request.

=A0

value

=A0

The entitlements of the user. If the type is basic, this MUST be a list of stri= ngs where the elements are from the list of supported entitlements defined in t= he Service Provider's basicEntitlements schema attribute. If the type is N= OT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attrib= ute, the Service Provider MUST return an HTTP 400, bad request.

=A0

A non-normative examples of using the basic Entitlement Scheme is as follows:=

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0 "type": "basic",

=A0=A0=A0=A0=A0 "value" : [ "calendar", "email", "spreadsheet" ]

=A0 }

}

=A0

Service Providers MAY support additional policy languages instead of or in addition= to the basic one define herein. For example, a Service Provider may support XA= CML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0=A0=A0=A0=A0 "type" : "xacml",

=A0=A0=A0=A0=A0=A0=A0=A0 "value" : { /* XACML policy encoded in JavaScript */ }

=A0=A0 }

}


--

Regards,

Travis Spencer, BSCS, MBA= =A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0=A0=A0www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M:=A0+46 72 725 5655
Email:=A0tspencer@pingidentity.co= m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
Connect with Ping
Twitter:=A0= @pingidentity=
LinkedIn:=A0Ping's Identity Cloud= =A0=A0 =A0
Facebook:=A0Ping Identity Pag= e
Connect with me
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer



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


--f46d04016c290c1f5504c11329fa-- From radovan.semancik@evolveum.com Mon May 28 07:55:16 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8021F844C for ; Mon, 28 May 2012 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgU4IxKRvO-0 for ; Mon, 28 May 2012 07:55:15 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEAF21F8444 for ; Mon, 28 May 2012 07:55:13 -0700 (PDT) Received: from [10.1.1.197] (perun.nlight.eu [81.89.58.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by charon.evolveum.com (Postfix) with ESMTPSA id 39E64A44B4E for ; Mon, 28 May 2012 16:55:11 +0200 (CEST) Message-ID: <4FC391CE.1070706@evolveum.com> Date: Mon, 28 May 2012 16:55:10 +0200 From: Radovan Semancik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060702030703010804050207" Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 14:55:16 -0000 This is a multi-part message in MIME format. --------------060702030703010804050207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I would like to point out that it is not yet resolved whether roles and groups are considered to be entitlements, whether they should also appear in the "entitlements" definition or just in the "groups" and "roles" part or also in the "entitlements" part, how are the entitlements assigned to user and whether it needs or needs not to be consistent with group and roles assignment, etc. These are severe problems of existing specification that were not yet resolved. I see very little sense in extending the entitlements part of the specification and not resolving existing problems. I guess that such problems originate in the lack of (theoretical) model that could be used to describe entitlements and entitlement-like concepts. A model that was tested in real deployment and that should be used to guide the protocol design. I believe that proceeding without such model will most likely introduce even more inconsistencies and ambiguities into the specification. -- Radovan Semancik Software Architect evolveum.com On 05/25/2012 11:01 AM, Travis Spencer wrote: > Hi All, > > Please find below a proposal for changing how entitlements are handled > in SCIM. This proposal is based on various discussions that have been > happening in the community, so hopefully there is agreement on the > general idea. If there are objections or details that need to be > worked out, I welcome the feedback. > > To be added to .well-known, SP Config, or whatever we end up w/ in the > long-run (i.e., section 9 of the draft): > > The following multi-valued attribute is defined in addition to the > common attributes defined in Core Schema: > > entitlementSchemes > > A complex type that specifies supported Entitlement Scheme properties. > Instead of the standard Canonical Value for type, this attribute > defines the following Canonical Values to represent common schemes: > none and basic. REQUIRED. > > name > > The common Entitlement Scheme name; e.g., XACML. REQUIRED. > > description > > A description of the Entitlement Scheme. REQUIRED. > > specUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's > specification. OPTIONAL. > > documentationUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's usage > documentation. OPTIONAL. > > When basic is supported, a service provider MUST also support the > following single value attribute which defines the entitlements that > it supports. > > basicEntitlements > > A list of string values that represent the entitlements that the > service provider supports. REQUIRED if the basic Entitlement Scheme is > supported. > > To replace entitlements in section 6.2 of the core schema doc: > > entitlements > > A complex attribute containing the entitlements of a User. > Entitlements are the rights that a User has at the Service Provider as > expressed according to the policy language stipulated by the type > sub-attribute. A basic syntax is defined in this specification that > allows the Client to specify a list of entitlements as strings. There > are NO canonical values specified, but a Client can learn what values > are supported by requesting the Service Provider Configuration > Resource and examining the list found in the basicEntitlements attribute. > > type > > A string indicating the type of policy language. The only acceptable > canonical value is basic. REQUIRED. If the type of policy is not > understood, the Service Provider MUST return an HTTP 400, bad request. > > value > > The entitlements of the user. If the type is basic, this MUST be a > list of strings where the elements are from the list of supported > entitlements defined in the Service Provider's basicEntitlements > schema attribute. If the type is NOT basic, then the value MUST be a > complex object that the Service Provider is expected to know how to > process. If the complex object cannot be processed according to the > syntax of the policy language specified in the type attribute, the > Service Provider MUST return an HTTP 400, bad request. > > A non-normative examples of using the basic Entitlement Scheme is as > follows: > > { > > "entitlements" : { > > "type": "basic", > > "value" : [ "calendar", "email", "spreadsheet" ] > > } > > } > > Service Providers MAY support additional policy languages instead of > or in addition to the basic one define herein. For example, a Service > Provider may support XACML and the Client may send the entitlements of > a User in accordance to that specification as in the following > non-normative example: > > { > > "entitlements" : { > > "type" : "xacml", > > "value" : { /* XACML policy encoded in JavaScript */ } > > } > > } > > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | www.pingidentity.com > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------060702030703010804050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I would like to point out that it is not yet resolved whether roles and groups are considered to be entitlements, whether they should also appear in the "entitlements" definition or just in the "groups" and "roles" part or also in the "entitlements" part, how are the entitlements assigned to user and whether it needs or needs not to be consistent with group and roles assignment, etc. These are severe problems of existing specification that were not yet resolved. I see very little sense in extending the entitlements part of the specification and not resolving existing problems.

I guess that such problems originate in the lack of (theoretical) model that could be used to describe entitlements and entitlement-like concepts. A model that was tested in real deployment and that should be used to guide the protocol design. I believe that proceeding without such model will most likely introduce even more inconsistencies and ambiguities into the specification.

-- 

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com


On 05/25/2012 11:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

 

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

 

To replace entitlements in section 6.2 of the core schema doc:

 

entitlements

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{

  "entitlements" : {

     "type": "basic",

      "value" : [ "calendar", "email", "spreadsheet" ]

  }

}

 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

 

{

  "entitlements" : {

         "type" : "xacml",

         "value" : { /* XACML policy encoded in JavaScript */ }

   }

}


--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer
 



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


--------------060702030703010804050207-- From Chris.Phillips@canarie.ca Mon May 28 08:35:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2F121F854B for ; Mon, 28 May 2012 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRiMlxpec1eg for ; Mon, 28 May 2012 08:35:45 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id AB44721F846C for ; Mon, 28 May 2012 08:35:44 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 28 May 2012 11:35:43 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Mon, 28 May 2012 11:35:40 -0400 Thread-Topic: [scim] AuthZ proposal for SCIM Thread-Index: Ac0854r04LNbkg97RXSiZGM3u8T+Vg== Message-ID: In-Reply-To: <4FC391CE.1070706@evolveum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBE90D6CA9190chrisphillipscanarieca_" MIME-Version: 1.0 Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 15:35:46 -0000 --_000_CBE90D6CA9190chrisphillipscanarieca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Radovan, Actually, I think it was never a problem to begin with. I see it is a persp= ective and scope question, not something done right or wrong. SCIM is a transport for identity information. It shouldn't care (and curre= ntly doesn't, or at least very little) what rules are overlaid on top of it= (e.g. consistency between groups and roles like you talk about). Everyone= is going to want to have their own criteria beyond the default. If someone wants to enforce referential integrity between attributes or app= ly a certain information management philosophy on top of the data, that's g= reat. Go right ahead, SCIM can carry the data to and from the endpoints to = allow that to happen. SCIM is the lego building block for the transport so= interesting things can be done in whatever flavour you want above and beyo= nd SCIM and not have to worry about the mechanics at the lower levels. >From my perspective, the challenges you describe exist regardless of the tr= ansport layer. In this effort around SCIM, we are talking about how it ca= n encapsulate data, but the challenges you highlight exist if things were i= n SQL tables or text files SCP'd around. Maybe this boils down to: What is considered a Practice and what is the Pro= tocol? Chris. From: Radovan Semancik > Date: Mon, 28 May 2012 10:55:10 -0400 To: "scim@ietf.org" > Subject: Re: [scim] AuthZ proposal for SCIM Hi, I would like to point out that it is not yet resolved whether roles and gro= ups are considered to be entitlements, whether they should also appear in t= he "entitlements" definition or just in the "groups" and "roles" part or al= so in the "entitlements" part, how are the entitlements assigned to user an= d whether it needs or needs not to be consistent with group and roles assig= nment, etc. These are severe problems of existing specification that were n= ot yet resolved. I see very little sense in extending the entitlements part= of the specification and not resolving existing problems. I guess that such problems originate in the lack of (theoretical) model tha= t could be used to describe entitlements and entitlement-like concepts. A m= odel that was tested in real deployment and that should be used to guide th= e protocol design. I believe that proceeding without such model will most l= ikely introduce even more inconsistencies and ambiguities into the specific= ation. -- Radovan Semancik Software Architect evolveum.com On 05/25/2012 11:01 AM, Travis Spencer wrote: Hi All, Please find below a proposal for changing how entitlements are handled in S= CIM. This proposal is based on various discussions that have been happening= in the community, so hopefully there is agreement on the general idea. If = there are objections or details that need to be worked out, I welcome the f= eedback. To be added to .well-known, SP Config, or whatever we end up w/ in the long= -run (i.e., section 9 of the draft): The following multi-valued attribute is defined in addition to the common a= ttributes defined in Core Schema: entitlementSchemes A complex type that specifies supported Entitlement Scheme properties. Inst= ead of the standard Canonical Value for type, this attribute defines the fo= llowing Canonical Values to represent common schemes: none and basic. REQUI= RED. name The common Entitlement Scheme name; e.g., XACML. REQUIRED. description A description of the Entitlement Scheme. REQUIRED. specUrl An HTTP addressable URL pointing to the Entitlement Scheme's specification.= OPTIONAL. documentationUrl An HTTP addressable URL pointing to the Entitlement Scheme's usage document= ation. OPTIONAL. When basic is supported, a service provider MUST also support the following= single value attribute which defines the entitlements that it supports. basicEntitlements A list of string values that represent the entitlements that the service pr= ovider supports. REQUIRED if the basic Entitlement Scheme is supported. To replace entitlements in section 6.2 of the core schema doc: entitlements A complex attribute containing the entitlements of a User. Entitlements are= the rights that a User has at the Service Provider as expressed according = to the policy language stipulated by the type sub-attribute. A basic syntax= is defined in this specification that allows the Client to specify a list = of entitlements as strings. There are NO canonical values specified, but a = Client can learn what values are supported by requesting the Service Provid= er Configuration Resource and examining the list found in the basicEntitlem= ents attribute. type A string indicating the type of policy language. The only acceptable canoni= cal value is basic. REQUIRED. If the type of policy is not understood, the = Service Provider MUST return an HTTP 400, bad request. value The entitlements of the user. If the type is basic, this MUST be a list of = strings where the elements are from the list of supported entitlements defi= ned in the Service Provider's basicEntitlements schema attribute. If the ty= pe is NOT basic, then the value MUST be a complex object that the Service P= rovider is expected to know how to process. If the complex object cannot be= processed according to the syntax of the policy language specified in the = type attribute, the Service Provider MUST return an HTTP 400, bad request. A non-normative examples of using the basic Entitlement Scheme is as follow= s: { "entitlements" : { "type": "basic", "value" : [ "calendar", "email", "spreadsheet" ] } } Service Providers MAY support additional policy languages instead of or in = addition to the basic one define herein. For example, a Service Provider ma= y support XACML and the Client may send the entitlements of a User in accor= dance to that specification as in the following non-normative example: { "entitlements" : { "type" : "xacml", "value" : { /* XACML policy encoded in JavaScript */ } } } -- Regards, Travis Spencer, BSCS, MBA | Sr. Technical Architect, CTO Office Ping Identity | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - M: +46 72 725 5655 Email: tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - Connect with Ping Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page Connect with me Twitter: @travisspencer LinkedIn: travisspencer _______________________________________________ scim mailing list scim@ietf.orghttps://www.ietf.org/mailman/listinfo/sc= im --_000_CBE90D6CA9190chrisphillipscanarieca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Radovan,  
=

Actually, I think it was never a problem to begin with.= I see it is a perspective and scope question, not something done right or = wrong.

SCIM is a transport for identity informatio= n.  It shouldn't care (and currently doesn't, or at least very little)= what rules are overlaid on top of it (e.g. consistency between groups and = roles like you talk about).  Everyone is going to want to have their o= wn criteria beyond the default.  

If someone = wants to enforce referential integrity between attributes or apply a certai= n information management philosophy on top of the data, that's great. Go ri= ght ahead, SCIM can carry the data to and from the endpoints to allow that = to happen.  SCIM is the lego building block for the transport so inter= esting things can be done in whatever flavour you want above and beyond SCI= M and not have to worry about the mechanics at the lower levels.
=
From my perspective, the challenges you describe exist regar= dless of the transport layer.  In this  effort around SCIM, we ar= e talking about how it can encapsulate data, but the challenges you highlig= ht exist if things were in  SQL tables or text files SCP'd around.&nbs= p;

Maybe this boils down to: What is considered a = Practice and what is the Protocol?


= Chris.


From: Radovan Semancik <radovan.semancik@evolveum.com>
Date: Mon, 28 May 2012 10:55:10 -0400
To: "scim@ie= tf.org" <scim@ietf.org>
<= span style=3D"font-weight:bold">Subject: Re: [scim] AuthZ proposal = for SCIM

=20 =20
Hi,

I would like to point out that it is not yet resolved whether roles and groups are considered to be entitlements, whether they should also appear in the "entitlements" definition or just in the "groups" and "roles" part or also in the "entitlements" part, how are the entitlements assigned to user and whether it needs or needs not to be consistent with group and roles assignment, etc. These are severe problems of existing specification that were not yet resolved. I see very little sense in extending the entitlements part of the specification and not resolving existing problems.

I guess that such problems originate in the lack of (theoretical) model that could be used to describe entitlements and entitlement-like concepts. A model that was tested in real deployment and that should be used to guide the protocol design. I believe that proceeding without such model will most likely introduce even more inconsistencies and ambiguities into the specification.

--=20

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com


On 05/25/2012 11:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If t= here are objections or details that need to be worked out, I welcome the feedback.

= To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

=  

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

=  

= To replace entitlements in section 6.2 of the core schema doc:

=  

entitlements

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{

  "entitlements" : {

     "type": "basic",

=

      "value" : [ "calendar", "email", "spreadsheet" ]

  }

}

 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

 

{

  "entitlements" : {

       &nb= sp; "type" : "xacml",

       &nb= sp; "value" : { /* XACML policy encoded in JavaScript */ }

   }

}


--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                    =           |   www.pingiden= tity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @= pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect wi= th me
Twitter: @travisspencer
LinkedIn: travisspencer
 



_______________________________________________
scim mailing list
scim@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/scim


 --_000_CBE90D6CA9190chrisphillipscanarieca_-- From tspencer@pingidentity.com Tue May 29 01:22:14 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EA721F8754 for ; Tue, 29 May 2012 01:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMZUtOPcrSL2 for ; Tue, 29 May 2012 01:22:12 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8FC21F8627 for ; Tue, 29 May 2012 01:22:11 -0700 (PDT) Received: from mail-lpp01m010-f53.google.com ([209.85.215.53]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKT8SHMmc93xKwm+n19LBTk0D7r4aY8VDv@postini.com; Tue, 29 May 2012 01:22:11 PDT Received: by lagu2 with SMTP id u2so2714582lag.40 for ; Tue, 29 May 2012 01:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=TSK7GJXjOc3iFVChCcidOah6Q5T2Q2MoeeKwXJ6Queo=; b=X6uDsNIqHpVn2qg11+buQlqQN+DAxky+kwhcF7FCKnfT4J+ip3iUKoYBnLFg5C0uiM eaOeds2rtkzZRV+2j58b1jlvOwR+T/2LXXqqY7Ne/oMgomZHEP1fLfpywcgPttEsF7eo 8/fDuas//CoFK7U7aTfgYKqsHzu87koDdUzFMXdxkaO5d+TDr6Ioil5z9utJpBZu0MUy 77yuHaU6rpJEJVhdw0cdnCeBO7UBgjt7M2vAVNoySanynjYIwrK4Hs94tzDU/9cODToS iiBWKPFglWSEQxI+rdgK1G7KnsETtMtcEqZb1Cc0yylV13z6fAOcdcttlW7TYxujBZHU 6HIw== Received: by 10.152.46.232 with SMTP id y8mr11318698lam.18.1338279728937; Tue, 29 May 2012 01:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.36.194 with HTTP; Tue, 29 May 2012 01:21:38 -0700 (PDT) In-Reply-To: <4FBFF4AA.9020508@alcatel-lucent.com> References: <4FBFF4AA.9020508@alcatel-lucent.com> From: Travis Spencer Date: Tue, 29 May 2012 10:21:38 +0200 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=bcaec5524206da7b4704c1288761 X-Gm-Message-State: ALoCoQlsabZDx/iZ/jced+GwLdBnzx/qsb16aZppk8O1zJHeXhqiIyWmQZOBOzFdGMM6EE9FXDks Cc: scim@ietf.org Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:22:15 -0000 --bcaec5524206da7b4704c1288761 Content-Type: text/plain; charset=ISO-8859-1 Whatever policy language is used, it needs to be relayed in a JSON message because that data model is MTI. So, you could take a XACML message, for example, and escape it or encode it in JSON as it's passed along. Whatever policy language is used and however its packaged up, it needs to be able to slip in via JSON; otherwise, it won't be compatible w/ SCIM. On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > ** > Trevis, > > A question (out of curiosity, since you have mentioned that all examples > are non-normative): Is it essential that XACML policy be encoded in > JavaScript? Or maybe you ment a JSON structure here? > > With thanks, > > Igor > > > > On 5/25/2012 5:01 AM, Travis Spencer wrote: > > Hi All, > > Please find below a proposal for changing how entitlements are handled > in SCIM. This proposal is based on various discussions that have been > happening in the community, so hopefully there is agreement on the general > idea. If there are objections or details that need to be worked out, I > welcome the feedback. > > To be added to .well-known, SP Config, or whatever we end up w/ in the > long-run (i.e., section 9 of the draft): > > > > The following multi-valued attribute is defined in addition to the common > attributes defined in Core Schema: > > > > entitlementSchemes > > > > A complex type that specifies supported Entitlement Scheme properties. > Instead of the standard Canonical Value for type, this attribute defines > the following Canonical Values to represent common schemes: none and basic. > REQUIRED. > > > > name > > > > The common Entitlement Scheme name; e.g., XACML. REQUIRED. > > > > description > > > > A description of the Entitlement Scheme. REQUIRED. > > > > specUrl > > > > An HTTP addressable URL pointing to the Entitlement Scheme's > specification. OPTIONAL. > > > > documentationUrl > > > > An HTTP addressable URL pointing to the Entitlement Scheme's usage > documentation. OPTIONAL. > > > > When basic is supported, a service provider MUST also support the > following single value attribute which defines the entitlements that it > supports. > > > > basicEntitlements > > > > A list of string values that represent the entitlements that the service > provider supports. REQUIRED if the basic Entitlement Scheme is supported. > > > > To replace entitlements in section 6.2 of the core schema doc: > > > > entitlements > > > > A complex attribute containing the entitlements of a User. Entitlements > are the rights that a User has at the Service Provider as expressed > according to the policy language stipulated by the type sub-attribute. A > basic syntax is defined in this specification that allows the Client to > specify a list of entitlements as strings. There are NO canonical values > specified, but a Client can learn what values are supported by requesting > the Service Provider Configuration Resource and examining the list found in > the basicEntitlements attribute. > > > > type > > > > A string indicating the type of policy language. The only acceptable > canonical value is basic. REQUIRED. If the type of policy is not > understood, the Service Provider MUST return an HTTP 400, bad request. > > > > value > > > > The entitlements of the user. If the type is basic, this MUST be a list of > strings where the elements are from the list of supported entitlements > defined in the Service Provider's basicEntitlements schema attribute. If > the type is NOT basic, then the value MUST be a complex object that the > Service Provider is expected to know how to process. If the complex object > cannot be processed according to the syntax of the policy language > specified in the type attribute, the Service Provider MUST return an HTTP > 400, bad request. > > > > A non-normative examples of using the basic Entitlement Scheme is as > follows: > > > > { > > "entitlements" : { > > "type": "basic", > > "value" : [ "calendar", "email", "spreadsheet" ] > > } > > } > > > > Service Providers MAY support additional policy languages instead of or in > addition to the basic one define herein. For example, a Service Provider > may support XACML and the Client may send the entitlements of a User in > accordance to that specification as in the following non-normative example: > > > > { > > "entitlements" : { > > "type" : "xacml", > > "value" : { /* XACML policy encoded in JavaScript */ } > > } > > } > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | www.pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > _______________________________________________ > scim mailing listscim@ietf.orghttps://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Regards, * * *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office *Ping* *Identity* | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *M:* +46 72 725 5655 *Email:* tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page *Connect with me* Twitter: @travisspencer LinkedIn: travisspencer --bcaec5524206da7b4704c1288761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Whatever policy language is used, it needs to be relayed in a JSON message = because that data model is MTI. So, you could take a XACML message, for exa= mple, and escape it or encode it in JSON as it's passed along. Whatever= policy language is used and however its packaged up, it needs to be able t= o slip in via JSON; otherwise, it won't be compatible w/ SCIM.

On Fri, May 25, 2012 at 11:07 PM, Igor Faynb= erg <igor.faynberg@alcatel-lucent.com> wrote:=
=20 =20 =20 =20
Trevis,

=A0A question (out of curiosity, since you have mentioned that all examples are non-normative):=A0 Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment=A0 a JSON structure here?
With thanks,

Igor



On 5/25/2012 5:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so=A0hopefully=A0there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

=A0

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

=A0

entitlementSchemes

=A0

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

=A0

name

=A0

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

=A0

description

=A0

A description of the Entitlement Scheme. REQUIRED.

=A0

specUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

=A0

documentationUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

=A0

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

=A0

basicEntitlements

=A0

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

=A0

To replace entitlements in section 6.2 of the core schema doc:

=A0

entitlements

=A0

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

=A0

type

=A0

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

=A0

value

=A0

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

=A0

A non-normative examples of using the basic Entitlement Scheme is as follows:

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0 "type": "basic",

=A0=A0=A0=A0=A0 "value" : [ "calendar", "email", "spreadsheet"= ; ]

=A0 }

}

=A0

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0=A0=A0=A0=A0 "type" : "xacml",

=A0=A0=A0=A0=A0=A0=A0=A0 "value" : { /* XACML policy encoded in JavaScript */ }

=A0=A0 }

}


--

Regards,

Travis Spencer, BSCS, MBA=A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0= =A0www.pingident= ity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M:=A0+46 72 725 5655
Email:=A0= tspencer@pin= gidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter:=A0@pingidentity
LinkedIn:=A0P= ing's Identity Cloud=A0=A0 =A0
Facebook:=A0Ping Identity Page=
Connect with m= e
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer
 



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

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




--

Rega= rds,

Travis Spencer, BSCS, MBA= =A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0=A0=A0www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M:=A0+46 72 725 5655
Email:=A0tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
Connect with Ping
Twitter:=A0= @pingidentity=
LinkedIn:=A0Ping's Identity Cloud= =A0=A0 =A0
Facebook:=A0Ping Identity Pag= e
Connect with me
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer


--bcaec5524206da7b4704c1288761-- From tspencer@pingidentity.com Tue May 29 01:27:23 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870F321F8554 for ; Tue, 29 May 2012 01:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D72Dj0hh9me for ; Tue, 29 May 2012 01:27:22 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC221F8678 for ; Tue, 29 May 2012 01:27:20 -0700 (PDT) Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKT8SIaBQB25Ty9B0p6SOdA2QGbLJ/yAMJ@postini.com; Tue, 29 May 2012 01:27:21 PDT Received: by lbbgg6 with SMTP id gg6so2831350lbb.8 for ; Tue, 29 May 2012 01:27:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VvdItvCrzP69zrR7XUELDlUNMdV7v3UGjktKWmXKcgg=; b=MppXYJxGzHyaaX5tJO6Iym1SyD6jn91ypjOKCTqwKT6XWZW53yc/Cn9Pqwgtf4t7/s DpnYmM/G7mxvhNaJyUtdzAlDYEVMJkjNvHyYTxe31Fi7r6haMeRcsdWvz+6xpR3D93q5 ARrOncu9ligYe+nYPi0KKAgkZqaiWguvbu/uaKsexr6/Xh24IoTa8b66L3LFZmCRQo3p qKMP8TfbTOt2AfantsHflwofMmWIELdyDVRl/M6vXuzvd2y2dDs3BIhBfQuVVODnIKh5 b1ZllYgV0AixTqBB8ZQ3ylLELrOBBHFZWja/QOjlHRHk540jhdswz02S0RZBjp5bCh9w /nCQ== Received: by 10.152.144.234 with SMTP id sp10mr11171680lab.51.1338280038779; Tue, 29 May 2012 01:27:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.36.194 with HTTP; Tue, 29 May 2012 01:26:48 -0700 (PDT) In-Reply-To: References: From: Travis Spencer Date: Tue, 29 May 2012 10:26:48 +0200 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=e89a8f22bfb1524b5c04c1289a17 X-Gm-Message-State: ALoCoQnNFNU8U7MuBOyP6Dx4/nB6b7MwoDY8VOYV1rzi7pa4UIozGsvzygq6gHR5sS0fWrBwu79P Cc: scim@ietf.org Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:27:23 -0000 --e89a8f22bfb1524b5c04c1289a17 Content-Type: text/plain; charset=ISO-8859-1 I thought of that, Samuel, but imagined that you'd never have policies of multiple types. It's gonna be basic, XACML, SecPal, or whatever but its highly unlikely to be a mix. Because of that, I thought the simplification was good. If it creates a new complex type which actually makes implementations more complex, not simpler, we can go w/ your suggestion. Feedback and thoughts from others? On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman wrote: > Great write-up, I have some thoughts regarding the examples and how > the entitlements are encoded in the user object. > > As I understand it the packaging in your example would > make entitlements to a new complex type. For simplicity reasons I would > like to propose to use a multivalued string as follows: > { > "entitlements": [ > { > "type": "basic", > "value": "calendar" > }, > { > "type": "basic", > "value": "email" > }, > { > "type": "basic", > "value": "spreadsheet" > } > ] > } > This representation would be a bit more verbode but no new type would be > needed. > However it would be possible to mix entitlements types since the type is > placed individually on each entitlement. > { > "entitlements": [ > { > "type": "xacml", > "value": "/*XACML policy*/" > }, > { > "type": "basic", > "value": "email" > } > ] > } > > Further, if we add language saying that basic is the default type we could > represent the entitlements list as follows: > { > "entitlements": [ "calendar", "email", "spreadsheet" ] > } > > Thoughts? > > Cheers > //Samuel > > > > On Fri, May 25, 2012 at 11:01 AM, Travis Spencer < > tspencer@pingidentity.com> wrote: > >> Hi All, >> >> Please find below a proposal for changing how entitlements are handled in >> SCIM. This proposal is based on various discussions that have been >> happening in the community, so hopefully there is agreement on the general >> idea. If there are objections or details that need to be worked out, I >> welcome the feedback. >> >> To be added to .well-known, SP Config, or whatever we end up w/ in the >> long-run (i.e., section 9 of the draft): >> >> >> >> The following multi-valued attribute is defined in addition to the common >> attributes defined in Core Schema: >> >> >> >> entitlementSchemes >> >> >> >> A complex type that specifies supported Entitlement Scheme properties. >> Instead of the standard Canonical Value for type, this attribute defines >> the following Canonical Values to represent common schemes: none and basic. >> REQUIRED. >> >> >> >> name >> >> >> >> The common Entitlement Scheme name; e.g., XACML. REQUIRED. >> >> >> >> description >> >> >> >> A description of the Entitlement Scheme. REQUIRED. >> >> >> >> specUrl >> >> >> >> An HTTP addressable URL pointing to the Entitlement Scheme's >> specification. OPTIONAL. >> >> >> >> documentationUrl >> >> >> >> An HTTP addressable URL pointing to the Entitlement Scheme's usage >> documentation. OPTIONAL. >> >> >> >> When basic is supported, a service provider MUST also support the >> following single value attribute which defines the entitlements that it >> supports. >> >> >> >> basicEntitlements >> >> >> >> A list of string values that represent the entitlements that the service >> provider supports. REQUIRED if the basic Entitlement Scheme is supported. >> >> >> >> To replace entitlements in section 6.2 of the core schema doc: >> >> >> >> entitlements >> >> >> >> A complex attribute containing the entitlements of a User. Entitlements >> are the rights that a User has at the Service Provider as expressed >> according to the policy language stipulated by the type sub-attribute. A >> basic syntax is defined in this specification that allows the Client to >> specify a list of entitlements as strings. There are NO canonical values >> specified, but a Client can learn what values are supported by requesting >> the Service Provider Configuration Resource and examining the list found in >> the basicEntitlements attribute. >> >> >> >> type >> >> >> >> A string indicating the type of policy language. The only acceptable >> canonical value is basic. REQUIRED. If the type of policy is not >> understood, the Service Provider MUST return an HTTP 400, bad request. >> >> >> >> value >> >> >> >> The entitlements of the user. If the type is basic, this MUST be a list >> of strings where the elements are from the list of supported entitlements >> defined in the Service Provider's basicEntitlements schema attribute. If >> the type is NOT basic, then the value MUST be a complex object that the >> Service Provider is expected to know how to process. If the complex object >> cannot be processed according to the syntax of the policy language >> specified in the type attribute, the Service Provider MUST return an HTTP >> 400, bad request. >> >> >> >> A non-normative examples of using the basic Entitlement Scheme is as >> follows: >> >> >> >> { >> >> "entitlements" : { >> >> "type": "basic", >> >> "value" : [ "calendar", "email", "spreadsheet" ] >> >> } >> >> } >> >> >> >> Service Providers MAY support additional policy languages instead of or >> in addition to the basic one define herein. For example, a Service Provider >> may support XACML and the Client may send the entitlements of a User in >> accordance to that specification as in the following non-normative example: >> >> >> >> { >> >> "entitlements" : { >> >> "type" : "xacml", >> >> "value" : { /* XACML policy encoded in JavaScript */ } >> >> } >> >> } >> >> -- >> >> Regards, >> * >> * >> *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office >> *Ping* *Identity* | www.pingidentity.com >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> - - - >> *M:* +46 72 725 5655 >> *Email:* tspencer@pingidentity.com >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> - - - >> *Connect with Ping* >> Twitter: @pingidentity >> LinkedIn: Ping's Identity Cloud >> >> Facebook: Ping Identity Page >> *Connect with me* >> Twitter: @travisspencer >> LinkedIn: travisspencer >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > -- Regards, * * *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office *Ping* *Identity* | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *M:* +46 72 725 5655 *Email:* tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page *Connect with me* Twitter: @travisspencer LinkedIn: travisspencer --e89a8f22bfb1524b5c04c1289a17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought of that, Samuel, but imagined that you'd never have policies = of multiple types. It's gonna be basic, XACML, SecPal, or whatever but = its highly unlikely to be a mix. Because of that, I thought the=A0simplific= ation=A0was good. If it creates a new complex type which actually makes imp= lementations more complex, not simpler, we can go w/ your suggestion.

Feedback and thoughts from others?

On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman = <samuel@erdtman.s= e> wrote:
Great write-up, I have some thoughts regardi= ng the examples and how the=A0entitlements=A0are encoded in the user object= .

As I understand it the packaging in your example would make= =A0entitlements=A0to a new complex type. For simplicity reasons I would lik= e to propose to use a multivalued string as follows:
{
=A0 "entitlements": [
=A0 =A0 {
=A0 =A0 =A0 &= quot;type": "basic",
=A0 =A0 =A0 "value"= : "calendar&= quot;=A0
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "= type": "basic",
=A0 =A0 =A0 "value": &qu= ot;email"=A0=
=A0 =A0 },
=A0 =A0=A0{
=A0 =A0 =A0 "type": "basic",=
=A0 =A0 =A0 "value": "spreadsheet"=A0
=A0 =A0 }
=A0 ]
}
This=A0representation=A0would be a bit more verbode but no new type wo= uld be needed.=A0
However it would be possible to mix=A0entitleme= nts types since the type is placed=A0individually=A0on each=A0entitlement.<= /div>
{
=A0 "entitlements": [
=A0 =A0 {
=A0 =A0 =A0 &= quot;type": "xacml",
=A0 =A0 =A0 "value"= : "/*X= ACML policy*/"=A0
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type&q= uot;: "basic",
=A0 =A0 =A0 "value": "email"=A0
=
=A0 =A0 }
=A0 ]
}

Further, if we add la= nguage saying that basic is the default type we could represent the=A0entit= lements=A0list as follows:
{
=A0 "entitlements": [=A0&quo= t;calendar",= =A0"email&qu= ot;,=A0"spreadsheet= "=A0]
}

Thoughts?

Ch= eers
//Samuel



=
On Fri, May 25, 2012 at 11:01 AM, Travis Spencer <tspencer@pingide= ntity.com> wrote:
Hi All,
Please find below a proposal for changing how entitlement= s are handled in SCIM. This proposal is based on various discussions that h= ave been happening in the community, so=A0hopefully=A0there is agreement on= the general idea. If there are objections or details that need to be worke= d out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., sec= tion 9 of the draft):

=A0

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

=A0

entitlementSchemes

=A0

A complex type that specifies supported Entitlement Scheme properties. Instea= d of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

=A0

name

=A0

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

=A0

description

=A0

A description of the Entitlement Scheme. REQUIRED.

=A0

specUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's specification= . OPTIONAL.

=A0

documentationUrl

=A0

An HTTP addressable URL pointing to the Entitlement Scheme's usage documen= tation. OPTIONAL.

=A0

When basic is supported, a service provider MUST also support the following sing= le value attribute which defines the entitlements that it supports.

=A0

basicEntitlements

=A0

A list of string values that represent the entitlements that the service prov= ider supports. REQUIRED if the basic Entitlement Scheme is supported.

=A0

To replace entitlements in section 6.2 of the core schema doc:

=A0

entitlements

=A0

A complex attribute containing the entitlements of a User. Entitlements are t= he rights that a User has at the Service Provider as expressed according to th= e policy language stipulated by the type sub-attribute. A basic syntax is def= ined in this specification that allows the Client to specify a list of entitleme= nts as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

=A0

type

=A0

A string indicating the type of policy language. The only acceptable canonica= l value is basic. REQUIRED. If the type of policy is not understood, the Serv= ice Provider MUST return an HTTP 400, bad request.

=A0

value

=A0

The entitlements of the user. If the type is basic, this MUST be a list of stri= ngs where the elements are from the list of supported entitlements defined in t= he Service Provider's basicEntitlements schema attribute. If the type is N= OT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attrib= ute, the Service Provider MUST return an HTTP 400, bad request.

=A0

A non-normative examples of using the basic Entitlement Scheme is as follows:=

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0 "type": "basic",

=A0=A0=A0=A0=A0 "value" : [ "calendar", "email", "spreadsheet" ]

=A0 }

}

=A0

Service Providers MAY support additional policy languages instead of or in addition= to the basic one define herein. For example, a Service Provider may support XA= CML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

=A0

{

=A0 "entitlements" : {

=A0=A0=A0=A0=A0=A0=A0=A0 "type" : "xacml",

=A0=A0=A0=A0=A0=A0=A0=A0 "value" : { /* XACML policy encoded in JavaScript */ }

=A0=A0 }

}


--

Regards,

Travis Spencer, BSCS, MBA= =A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0=A0=A0www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M:=A0+46 72 725 5655
Email:=A0tspencer@pingidentity.co= m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
Connect with Ping
Twitter:=A0= @pingidentity=
LinkedIn:=A0Ping's Identity Cloud= =A0=A0 =A0
Facebook:=A0Ping Identity Pag= e
Connect with me
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer



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





--

Regards,=

Travis Spencer, BSCS, MBA= =A0 |=A0Sr. Technical Architect, CTO Office
Ping=A0Identity=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0=A0=A0www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M:=A0+46 72 725 5655
Email:=A0tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
Connect with Ping
Twitter:=A0= @pingidentity=
LinkedIn:=A0Ping's Identity Cloud= =A0=A0 =A0
Facebook:=A0Ping Identity Pag= e
Connect with me
Twitter:=A0@travisspencer
LinkedIn:=A0travisspencer


--e89a8f22bfb1524b5c04c1289a17-- From phil.hunt@oracle.com Tue May 29 09:03:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2111E8073 for ; Tue, 29 May 2012 09:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcLNoHd6vTTv for ; Tue, 29 May 2012 09:03:30 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3A60E21F85BD for ; Tue, 29 May 2012 09:03:30 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TG3QVD010031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 16:03:27 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TG3QVW000662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 16:03:26 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TG3QWN007216; Tue, 29 May 2012 11:03:26 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 09:03:25 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9C742585-2E2E-4103-B823-F5D6423F72BD" From: Phil Hunt In-Reply-To: Date: Tue, 29 May 2012 09:03:24 -0700 Message-Id: <1348C5A8-8889-4709-AEB2-32F31BB66943@oracle.com> References: <4FBFF4AA.9020508@alcatel-lucent.com> To: Travis Spencer X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: igor.faynberg@alcatel-lucent.com, scim@ietf.org Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:03:32 -0000 --Apple-Mail=_9C742585-2E2E-4103-B823-F5D6423F72BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Why not simply encode it since the endpoint likely wants it back in XML = form anyway? =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-05-29, at 1:21 AM, Travis Spencer wrote: > Whatever policy language is used, it needs to be relayed in a JSON = message because that data model is MTI. So, you could take a XACML = message, for example, and escape it or encode it in JSON as it's passed = along. Whatever policy language is used and however its packaged up, it = needs to be able to slip in via JSON; otherwise, it won't be compatible = w/ SCIM. >=20 > On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg = wrote: > Trevis, >=20 > A question (out of curiosity, since you have mentioned that all = examples are non-normative): Is it essential that XACML policy be = encoded in JavaScript? Or maybe you ment a JSON structure here? >=20 > With thanks, >=20 > Igor >=20 >=20 >=20 > On 5/25/2012 5:01 AM, Travis Spencer wrote: >> Hi All, >>=20 >> Please find below a proposal for changing how entitlements are = handled in SCIM. This proposal is based on various discussions that have = been happening in the community, so hopefully there is agreement on the = general idea. If there are objections or details that need to be worked = out, I welcome the feedback. >>=20 >> To be added to .well-known, SP Config, or whatever we end up w/ in = the long-run (i.e., section 9 of the draft): >> =20 >> The following multi-valued attribute is defined in addition to the = common attributes defined in Core Schema: >> =20 >> entitlementSchemes >> =20 >> A complex type that specifies supported Entitlement Scheme = properties. Instead of the standard Canonical Value for type, this = attribute defines the following Canonical Values to represent common = schemes: none and basic. REQUIRED. >> =20 >> name >> =20 >> The common Entitlement Scheme name; e.g., XACML. REQUIRED. >> =20 >> description >> =20 >> A description of the Entitlement Scheme. REQUIRED. >> =20 >> specUrl >> =20 >> An HTTP addressable URL pointing to the Entitlement Scheme's = specification. OPTIONAL. >> =20 >> documentationUrl >> =20 >> An HTTP addressable URL pointing to the Entitlement Scheme's usage = documentation. OPTIONAL. >> =20 >> When basic is supported, a service provider MUST also support the = following single value attribute which defines the entitlements that it = supports. >> =20 >> basicEntitlements >> =20 >> A list of string values that represent the entitlements that the = service provider supports. REQUIRED if the basic Entitlement Scheme is = supported. >> =20 >> To replace entitlements in section 6.2 of the core schema doc: >> =20 >> entitlements >> =20 >> A complex attribute containing the entitlements of a User. = Entitlements are the rights that a User has at the Service Provider as = expressed according to the policy language stipulated by the type = sub-attribute. A basic syntax is defined in this specification that = allows the Client to specify a list of entitlements as strings. There = are NO canonical values specified, but a Client can learn what values = are supported by requesting the Service Provider Configuration Resource = and examining the list found in the basicEntitlements attribute. >> =20 >> type >> =20 >> A string indicating the type of policy language. The only acceptable = canonical value is basic. REQUIRED. If the type of policy is not = understood, the Service Provider MUST return an HTTP 400, bad request. >> =20 >> value >> =20 >> The entitlements of the user. If the type is basic, this MUST be a = list of strings where the elements are from the list of supported = entitlements defined in the Service Provider's basicEntitlements schema = attribute. If the type is NOT basic, then the value MUST be a complex = object that the Service Provider is expected to know how to process. If = the complex object cannot be processed according to the syntax of the = policy language specified in the type attribute, the Service Provider = MUST return an HTTP 400, bad request. >> =20 >> A non-normative examples of using the basic Entitlement Scheme is as = follows: >> =20 >> { >> "entitlements" : { >> "type": "basic", >> "value" : [ "calendar", "email", "spreadsheet" ] >> } >> } >> =20 >> Service Providers MAY support additional policy languages instead of = or in addition to the basic one define herein. For example, a Service = Provider may support XACML and the Client may send the entitlements of a = User in accordance to that specification as in the following = non-normative example: >> =20 >> { >> "entitlements" : { >> "type" : "xacml", >> "value" : { /* XACML policy encoded in JavaScript */ } >> } >> } >>=20 >> --=20 >>=20 >> Regards, >>=20 >> Travis Spencer, BSCS, MBA | Sr. Technical Architect, CTO Office >> Ping Identity | www.pingidentity.com >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - >> M: +46 72 725 5655 >> Email: tspencer@pingidentity.com >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - >> Connect with Ping >> Twitter: @pingidentity >> LinkedIn: Ping's Identity Cloud =20 >> Facebook: Ping Identity Page=09 >> Connect with me >> Twitter: @travisspencer >> LinkedIn: travisspencer >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > --=20 >=20 > Regards, >=20 > Travis Spencer, BSCS, MBA | Sr. Technical Architect, CTO Office > Ping Identity | www.pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - > M: +46 72 725 5655 > Email: tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - > Connect with Ping > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud =20 > Facebook: Ping Identity Page=09 > Connect with me > Twitter: @travisspencer > LinkedIn: travisspencer >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_9C742585-2E2E-4103-B823-F5D6423F72BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Why = not simply encode it since the endpoint likely wants it back in XML form = anyway?  

Phil

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





On 2012-05-29, at 1:21 AM, Travis Spencer wrote:

Whatever = policy language is used, it needs to be relayed in a JSON message = because that data model is MTI. So, you could take a XACML message, for = example, and escape it or encode it in JSON as it's passed along. = Whatever policy language is used and however its packaged up, it needs = to be able to slip in via JSON; otherwise, it won't be compatible w/ = SCIM.

On Fri, May 25, 2012 at 11:07 PM, Igor = Faynberg <igor.faynberg@alcatel-lucent.com> = wrote:
=20 =20 =20 =20
Trevis,

 A question (out of curiosity, since you have mentioned that = all examples are non-normative):  Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment  a JSON structure = here?

With thanks,

Igor



On 5/25/2012 5:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. = If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

 

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

 

The common Entitlement Scheme name; e.g., XACML. = REQUIRED.

 

 

A description of the Entitlement Scheme. REQUIRED.

 

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

 

To replace entitlements in section 6.2 of the core schema doc:

 

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad = request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{ =
     "type": = "basic",
      "value" : [ "calendar", "email", "spreadsheet" ]
  } =
 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative = example:

 

  "entitlements" : {
         = "value" : { /* XACML policy encoded in JavaScript */ }
   }
}

--

Regards,

Travis Spencer, BSCS, MBA  = | Sr. Technical Architect, CTO Office
Ping Identity                  =             |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 = 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping = Identity Page
Connect with = me
Twitter: @travisspencer
LinkedIn: travisspencer
 



_______________________________________________
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




-- =

Regards,

Travis Spencer, BSCS, = MBA  | Sr. Technical Architect, CTO = Office
Ping Identity      =                     =     |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud   =  
Facebook: Ping = Identity Page
Connect = with me
Twitter: @travisspencer
LinkedIn: travisspencer


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

= --Apple-Mail=_9C742585-2E2E-4103-B823-F5D6423F72BD-- From igor.faynberg@alcatel-lucent.com Tue May 29 09:33:48 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A621F86D1 for ; Tue, 29 May 2012 09:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55yvD3wOiQZv for ; Tue, 29 May 2012 09:33:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 396A721F86CE for ; Tue, 29 May 2012 09:33:47 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4TGXknx009807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 May 2012 11:33:46 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4TGXjjl012894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 May 2012 11:33:46 -0500 Received: from [135.222.232.150] (USMUYN0L055118.mh.lucent.com [135.222.232.150]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4TGXjD4005629; Tue, 29 May 2012 11:33:45 -0500 (CDT) Message-ID: <4FC4FA69.7040506@alcatel-lucent.com> Date: Tue, 29 May 2012 12:33:45 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060803070202060001010904" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:33:49 -0000 This is a multi-part message in MIME format. --------------060803070202060001010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Which makes me think that it is important to decide early whether support of multiple types is a requirement. But in either case, once the individual types for entitlemes are defined, I don't see a problem with having a super type, too. Igor > I thought of that, Samuel, but imagined that you'd never have policies > of multiple types. It's gonna be basic, XACML, SecPal, or whatever but > its highly unlikely to be a mix. Because of that, I thought > the simplification was good. If it creates a new complex type which > actually makes implementations more complex, not simpler, we can go w/ > your suggestion. > > Feedback and thoughts from others? > > On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman > wrote: > > Great write-up, I have some thoughts regarding the examples and > how the entitlements are encoded in the user object. > > As I understand it the packaging in your example would > make entitlements to a new complex type. For simplicity reasons I > would like to propose to use a multivalued string as follows: > { > "entitlements": [ > { > "type": "basic", > "value": "calendar" > }, > { > "type": "basic", > "value": "email" > }, > { > "type": "basic", > "value": "spreadsheet" > } > ] > } > This representation would be a bit more verbode but no new type > would be needed. > However it would be possible to mix entitlements types since the > type is placed individually on each entitlement. > { > "entitlements": [ > { > "type": "xacml", > "value": "/*XACML policy*/" > }, > { > "type": "basic", > "value": "email" > } > ] > } > > Further, if we add language saying that basic is the default type > we could represent the entitlements list as follows: > { > "entitlements": [ "calendar", "email", "spreadsheet" ] > } > > Thoughts? > > Cheers > //Samuel > > > > On Fri, May 25, 2012 at 11:01 AM, Travis Spencer > > wrote: > > Hi All, > > Please find below a proposal for changing how entitlements are > handled in SCIM. This proposal is based on various discussions > that have been happening in the community, so hopefully there > is agreement on the general idea. If there are objections or > details that need to be worked out, I welcome the feedback. > > To be added to .well-known, SP Config, or whatever we end up > w/ in the long-run (i.e., section 9 of the draft): > > The following multi-valued attribute is defined in addition to > the common attributes defined in Core Schema: > > entitlementSchemes > > A complex type that specifies supported Entitlement Scheme > properties. Instead of the standard Canonical Value for type, > this attribute defines the following Canonical Values to > represent common schemes: none and basic. REQUIRED. > > name > > The common Entitlement Scheme name; e.g., XACML. REQUIRED. > > description > > A description of the Entitlement Scheme. REQUIRED. > > specUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's > specification. OPTIONAL. > > documentationUrl > > An HTTP addressable URL pointing to the Entitlement Scheme's > usage documentation. OPTIONAL. > > When basic is supported, a service provider MUST also support > the following single value attribute which defines the > entitlements that it supports. > > basicEntitlements > > A list of string values that represent the entitlements that > the service provider supports. REQUIRED if the basic > Entitlement Scheme is supported. > > To replace entitlements in section 6.2 of the core schema doc: > > entitlements > > A complex attribute containing the entitlements of a User. > Entitlements are the rights that a User has at the Service > Provider as expressed according to the policy language > stipulated by the type sub-attribute. A basic syntax is > defined in this specification that allows the Client to > specify a list of entitlements as strings. There are NO > canonical values specified, but a Client can learn what values > are supported by requesting the Service Provider Configuration > Resource and examining the list found in the basicEntitlements > attribute. > > type > > A string indicating the type of policy language. The only > acceptable canonical value is basic. REQUIRED. If the type of > policy is not understood, the Service Provider MUST return an > HTTP 400, bad request. > > value > > The entitlements of the user. If the type is basic, this MUST > be a list of strings where the elements are from the list of > supported entitlements defined in the Service Provider's > basicEntitlements schema attribute. If the type is NOT basic, > then the value MUST be a complex object that the Service > Provider is expected to know how to process. If the complex > object cannot be processed according to the syntax of the > policy language specified in the type attribute, the Service > Provider MUST return an HTTP 400, bad request. > > A non-normative examples of using the basic Entitlement Scheme > is as follows: > > { > > "entitlements" : { > > "type": "basic", > > "value" : [ "calendar", "email", "spreadsheet" ] > > } > > } > > Service Providers MAY support additional policy languages > instead of or in addition to the basic one define herein. For > example, a Service Provider may support XACML and the Client > may send the entitlements of a User in accordance to that > specification as in the following non-normative example: > > { > > "entitlements" : { > > "type" : "xacml", > > "value" : { /* XACML policy encoded in JavaScript */ } > > } > > } > > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | > www.pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > > > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > > -- > > Regards, > * > * > *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office > *Ping* *Identity* | www.pingidentity.com > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *M:* +46 72 725 5655 > *Email:* tspencer@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *Connect with Ping* > Twitter: @pingidentity > LinkedIn: Ping's Identity Cloud > > Facebook: Ping Identity Page > > *Connect with me* > Twitter: @travisspencer > LinkedIn: travisspencer > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------060803070202060001010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Which makes me think that it is important to decide early whether support of multiple types is a requirement.

But in either case, once the individual types for entitlemes are defined, I don't see a problem with having a super type, too.

Igor
I thought of that, Samuel, but imagined that you'd never have policies of multiple types. It's gonna be basic, XACML, SecPal, or whatever but its highly unlikely to be a mix. Because of that, I thought the simplification was good. If it creates a new complex type which actually makes implementations more complex, not simpler, we can go w/ your suggestion.

Feedback and thoughts from others?

On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
Great write-up, I have some thoughts regarding the examples and how the entitlements are encoded in the user object.

As I understand it the packaging in your example would make entitlements to a new complex type. For simplicity reasons I would like to propose to use a multivalued string as follows:
{
  "entitlements": [
    {
      "type": "basic",
      "value": "calendar" 
    },
    {
      "type": "basic",
      "value": "email" 
    },
    {
      "type": "basic",
      "value": "spreadsheet" 
    }
  ]
}
This representation would be a bit more verbode but no new type would be needed. 
However it would be possible to mix entitlements types since the type is placed individually on each entitlement.
{
  "entitlements": [
    {
      "type": "xacml",
      "value": "/*XACML policy*/" 
    },
    {
      "type": "basic",
      "value": "email" 
    }
  ]
}

Further, if we add language saying that basic is the default type we could represent the entitlements list as follows:
{
  "entitlements": [ "calendar", "email", "spreadsheet" ]
}

Thoughts?

Cheers
//Samuel


On Fri, May 25, 2012 at 11:01 AM, Travis Spencer <tspencer@pingidentity.com> wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

 

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

 

To replace entitlements in section 6.2 of the core schema doc:

 

entitlements

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{

  "entitlements" : {

     "type": "basic",

      "value" : [ "calendar", "email", "spreadsheet" ]

  }

}

 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

 

{

  "entitlements" : {

         "type" : "xacml",

         "value" : { /* XACML policy encoded in JavaScript */ }

   }

}


--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer



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





--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer
 



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------060803070202060001010904-- From tonynad@microsoft.com Tue May 29 09:42:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4AD11E80B4 for ; Tue, 29 May 2012 09:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJPrDKKjednK for ; Tue, 29 May 2012 09:42:20 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 73AA611E80B2 for ; Tue, 29 May 2012 09:42:20 -0700 (PDT) Received: from mail105-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 May 2012 16:41:57 +0000 Received: from mail105-tx2 (localhost [127.0.0.1]) by mail105-tx2-R.bigfish.com (Postfix) with ESMTP id 465EF1C032F for ; Tue, 29 May 2012 16:41:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz9371Ic85fh14ffI98dK62a3Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail105-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail105-tx2 (localhost.localdomain [127.0.0.1]) by mail105-tx2 (MessageSwitch) id 1338309715125594_20846; Tue, 29 May 2012 16:41:55 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.254]) by mail105-tx2.bigfish.com (Postfix) with ESMTP id 1160640044 for ; Tue, 29 May 2012 16:41:55 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 May 2012 16:41:54 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 29 May 2012 16:41:56 +0000 Received: from mail216-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 May 2012 16:40:42 +0000 Received: from mail216-va3 (localhost [127.0.0.1]) by mail216-va3-R.bigfish.com (Postfix) with ESMTP id EAD577C02CB for ; Tue, 29 May 2012 16:40:41 +0000 (UTC) Received: from mail216-va3 (localhost.localdomain [127.0.0.1]) by mail216-va3 (MessageSwitch) id 1338309640190463_15533; Tue, 29 May 2012 16:40:40 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.239]) by mail216-va3.bigfish.com (Postfix) with ESMTP id 2A53A740046; Tue, 29 May 2012 16:40:40 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 May 2012 16:40:38 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.236]) by BL2PRD0310HT003.namprd03.prod.outlook.com ([10.255.97.38]) with mapi id 14.16.0152.000; Tue, 29 May 2012 16:41:01 +0000 From: Anthony Nadalin To: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Thread-Topic: [scim] AuthZ proposal for SCIM Thread-Index: AQHNOlUq8tkgd2zkJ0aozf79JpYjgpbeyDUAgAGstACAAIgOgIAAAQtw Date: Tue, 29 May 2012 16:41:00 +0000 Message-ID: References: <4FC4FA69.7040506@alcatel-lucent.com> In-Reply-To: <4FC4FA69.7040506@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.27] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E745F9D502BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:42:22 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E745F9D502BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have many cases where the policy is defined in multiple forms and is inp= ut to same resource as some parts of a company use XACML, the other part wi= ll use SECPAL and this is mixed input on a single resource that we have to = deal with From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Igo= r Faynberg Sent: Tuesday, May 29, 2012 9:34 AM To: scim@ietf.org Subject: Re: [scim] AuthZ proposal for SCIM Which makes me think that it is important to decide early whether support o= f multiple types is a requirement. But in either case, once the individual types for entitlemes are defined, I= don't see a problem with having a super type, too. Igor I thought of that, Samuel, but imagined that you'd never have policies of m= ultiple types. It's gonna be basic, XACML, SecPal, or whatever but its high= ly unlikely to be a mix. Because of that, I thought the simplification was = good. If it creates a new complex type which actually makes implementations= more complex, not simpler, we can go w/ your suggestion. Feedback and thoughts from others? On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman > wrote: Great write-up, I have some thoughts regarding the examples and how the ent= itlements are encoded in the user object. As I understand it the packaging in your example would make entitlements to= a new complex type. For simplicity reasons I would like to propose to use = a multivalued string as follows: { "entitlements": [ { "type": "basic", "value": "calendar" }, { "type": "basic", "value": "email" }, { "type": "basic", "value": "spreadsheet" } ] } This representation would be a bit more verbode but no new type would be ne= eded. However it would be possible to mix entitlements types since the type is pl= aced individually on each entitlement. { "entitlements": [ { "type": "xacml", "value": "/*XACML policy*/" }, { "type": "basic", "value": "email" } ] } Further, if we add language saying that basic is the default type we could = represent the entitlements list as follows: { "entitlements": [ "calendar", "email", "spreadsheet" ] } Thoughts? Cheers //Samuel On Fri, May 25, 2012 at 11:01 AM, Travis Spencer > wrote: Hi All, Please find below a proposal for changing how entitlements are handled in S= CIM. This proposal is based on various discussions that have been happening= in the community, so hopefully there is agreement on the general idea. If = there are objections or details that need to be worked out, I welcome the f= eedback. To be added to .well-known, SP Config, or whatever we end up w/ in the long= -run (i.e., section 9 of the draft): The following multi-valued attribute is defined in addition to the common a= ttributes defined in Core Schema: entitlementSchemes A complex type that specifies supported Entitlement Scheme properties. Inst= ead of the standard Canonical Value for type, this attribute defines the fo= llowing Canonical Values to represent common schemes: none and basic. REQUI= RED. name The common Entitlement Scheme name; e.g., XACML. REQUIRED. description A description of the Entitlement Scheme. REQUIRED. specUrl An HTTP addressable URL pointing to the Entitlement Scheme's specification.= OPTIONAL. documentationUrl An HTTP addressable URL pointing to the Entitlement Scheme's usage document= ation. OPTIONAL. When basic is supported, a service provider MUST also support the following= single value attribute which defines the entitlements that it supports. basicEntitlements A list of string values that represent the entitlements that the service pr= ovider supports. REQUIRED if the basic Entitlement Scheme is supported. To replace entitlements in section 6.2 of the core schema doc: entitlements A complex attribute containing the entitlements of a User. Entitlements are= the rights that a User has at the Service Provider as expressed according = to the policy language stipulated by the type sub-attribute. A basic syntax= is defined in this specification that allows the Client to specify a list = of entitlements as strings. There are NO canonical values specified, but a = Client can learn what values are supported by requesting the Service Provid= er Configuration Resource and examining the list found in the basicEntitlem= ents attribute. type A string indicating the type of policy language. The only acceptable canoni= cal value is basic. REQUIRED. If the type of policy is not understood, the = Service Provider MUST return an HTTP 400, bad request. value The entitlements of the user. If the type is basic, this MUST be a list of = strings where the elements are from the list of supported entitlements defi= ned in the Service Provider's basicEntitlements schema attribute. If the ty= pe is NOT basic, then the value MUST be a complex object that the Service P= rovider is expected to know how to process. If the complex object cannot be= processed according to the syntax of the policy language specified in the = type attribute, the Service Provider MUST return an HTTP 400, bad request. A non-normative examples of using the basic Entitlement Scheme is as follow= s: { "entitlements" : { "type": "basic", "value" : [ "calendar", "email", "spreadsheet" ] } } Service Providers MAY support additional policy languages instead of or in = addition to the basic one define herein. For example, a Service Provider ma= y support XACML and the Client may send the entitlements of a User in accor= dance to that specification as in the following non-normative example: { "entitlements" : { "type" : "xacml", "value" : { /* XACML policy encoded in JavaScript */ } } } -- Regards, Travis Spencer, BSCS, MBA | Sr. Technical Architect, CTO Office Ping Identity | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - M: +46 72 725 5655 Email: tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - Connect with Ping Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page Connect with me Twitter: @travisspencer LinkedIn: travisspencer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Regards, Travis Spencer, BSCS, MBA | Sr. Technical Architect, CTO Office Ping Identity | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - M: +46 72 725 5655 Email: tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - Connect with Ping Twitter: @pingidentity LinkedIn: Ping's Identity Cloud Facebook: Ping Identity Page Connect with me Twitter: @travisspencer LinkedIn: travisspencer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_B26C1EF377CB694EAB6BDDC8E624B6E745F9D502BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have many cases where = the policy is defined in multiple forms and is input to same resource as so= me parts of a company use XACML, the other part will use SECPAL and this is mixed input on a single resource that we have to deal w= ith

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Igor Faynberg
Sent: Tuesday, May 29, 2012 9:34 AM
To: scim@ietf.org
Subject: Re: [scim] AuthZ proposal for SCIM

 

Which makes me think that it is important to decide = early whether support of multiple types is a requirement.

But in either case, once the individual types for entitlemes are defined, I= don't see a problem with having a super type, too.

Igor

I thought of that, Samuel, but imagined that you'd n= ever have policies of multiple types. It's gonna be basic, XACML, SecPal, o= r whatever but its highly unlikely to be a mix. Because of that, I thought = the simplification was good. If it creates a new complex type which actually makes implementations more compl= ex, not simpler, we can go w/ your suggestion.

 

Feedback and thoughts= from others?

On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman <= samuel@erdtman.se> wrote:

Great write-up, I have some thoughts regarding the e= xamples and how the entitlements are encoded in the user object.

 

As I understand it the packaging in your example wou= ld make entitlements to a new complex type. For simplicity reason= s I would like to propose to use a multivalued string as follows:

{

  "entitlements":= [

    {

      "type": "basic&q= uot;,

      "value": "calendar" 

    },

    {

      "type": "basic&q= uot;,

      "value": "email" 

    },

    {

      "type": "basic&q= uot;,

      "value": "spreadsheet" 

    }

  ]

}

This representation would be a bit more ve= rbode but no new type would be needed. 

However it would be possible to mix entitlement= s types since the type is placed individually on each entitl= ement.

{

  "entitlements":= [

    {

      "type": "xacml&q= uot;,

      "value": "/*XACML policy*/" 

    },

    {

      "type": "basic&q= uot;,

      "value": "email" 

    }

  ]

}

 

Further, if we add language saying that basic is the= default type we could represent the entitlements list as follows= :

{

  "entitlements":= [ "calendar", "e= mail", "spreadsheet" ]<= o:p>

}

 

Thoughts?

 

Cheers

//Samuel

 

 

Hi All,

 

Please find below a proposal for changing how entitl= ements are handled in SCIM. This proposal is based on various discussions t= hat have been happening in the community, so hopefully there is a= greement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

 

To be added to .= well-known, SP Config, or whatever we end up w/ in the long-run (i.e., sect= ion 9 of the draft):

 

The following multi-valued attribute is defined in addition to= the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme pro= perties. Instead of the standard Canonical Value for type, this attribute d= efines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.<= /span>

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's s= pecification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's u= sage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support = the following single value attribute which defines the entitlements that it= supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that t= he service provider supports. REQUIRED if the basic Entitlement Scheme is s= upported.

 

To replace entit= lements in section 6.2 of the core schema doc:

 

entitlements

 

A complex attribute containing the entitlements of a User. Ent= itlements are the rights that a User has at the Service Provider as express= ed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that a= llows the Client to specify a list of entitlements as strings. There are NO= canonical values specified, but a Client can learn what values are support= ed by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlemen= ts attribute.

 

type

 

A string indicating the type of policy language. The only acce= ptable canonical value is basic. REQUIRED. If the type of policy is not und= erstood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST = be a list of strings where the elements are from the list of supported enti= tlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a compl= ex object that the Service Provider is expected to know how to process. If = the complex object cannot be processed according to the syntax of the polic= y language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.=

 

A non-normative examples of using the basic Entitlement Scheme= is as follows:

 

{

  "entitlements" : {

     "type": "basic",<= o:p>

      "value" : [ "cal= endar", "email", "spreadsheet" ]=

  }

}

 

Service Providers MAY support additional policy languages inst= ead of or in addition to the basic one define herein. For example, a Servic= e Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the follo= wing non-normative example:

 

{

  "entitlements" : {

         "type&qu= ot; : "xacml",

         "value&q= uot; : { /* XACML policy encoded in JavaScript */ }

   }

}

 

--

Regards,

 

= Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office=
Ping Identity                      &nbs= p;       |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -

Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud     Facebook: Ping Identity Page

Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer

 

 

 

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

 



 

--

Regards,

 

= Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office=
Ping Identity                      &nbs= p;       |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - -

Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud     Facebook: Ping Identity Page

Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer

 

 

 
 
_______________________________________________
scim mailing list
scim@ietf.org
https://www.iet=
f.org/mailman/listinfo/scim
--_000_B26C1EF377CB694EAB6BDDC8E624B6E745F9D502BL2PRD0310MB362_-- From igor.faynberg@alcatel-lucent.com Tue May 29 10:37:48 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66811E80EE for ; Tue, 29 May 2012 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.292 X-Spam-Level: X-Spam-Status: No, score=-8.292 tagged_above=-999 required=5 tests=[AWL=1.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUo+fUC3jJtv for ; Tue, 29 May 2012 10:37:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4B11E80F7 for ; Tue, 29 May 2012 10:37:46 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q4THbjRI006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 12:37:45 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4THbiBs029672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 May 2012 12:37:45 -0500 Received: from [135.222.232.150] (USMUYN0L055118.mh.lucent.com [135.222.232.150]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4THbiZm022178; Tue, 29 May 2012 12:37:44 -0500 (CDT) Message-ID: <4FC50968.20007@alcatel-lucent.com> Date: Tue, 29 May 2012 13:37:44 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phil Hunt References: <4FBFF4AA.9020508@alcatel-lucent.com> <1348C5A8-8889-4709-AEB2-32F31BB66943@oracle.com> In-Reply-To: <1348C5A8-8889-4709-AEB2-32F31BB66943@oracle.com> Content-Type: multipart/alternative; boundary="------------000809020003000104030805" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: scim@ietf.org, Travis Spencer Subject: Re: [scim] AuthZ proposal for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:37:48 -0000 This is a multi-part message in MIME format. --------------000809020003000104030805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ...Phil stole my question! Igor On 5/29/2012 12:03 PM, Phil Hunt wrote: > Why not simply encode it since the endpoint likely wants it back in > XML form anyway? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-05-29, at 1:21 AM, Travis Spencer wrote: > >> Whatever policy language is used, it needs to be relayed in a JSON >> message because that data model is MTI. So, you could take a XACML >> message, for example, and escape it or encode it in JSON as it's >> passed along. Whatever policy language is used and however its >> packaged up, it needs to be able to slip in via JSON; otherwise, it >> won't be compatible w/ SCIM. >> >> On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg >> > > wrote: >> >> Trevis, >> >> A question (out of curiosity, since you have mentioned that all >> examples are non-normative): Is it essential that XACML policy >> be encoded in JavaScript? Or maybe you ment a JSON structure here? >> >> With thanks, >> >> Igor >> >> >> >> On 5/25/2012 5:01 AM, Travis Spencer wrote: >>> Hi All, >>> >>> Please find below a proposal for changing how entitlements are >>> handled in SCIM. This proposal is based on various discussions >>> that have been happening in the community, so hopefully there is >>> agreement on the general idea. If there are objections or >>> details that need to be worked out, I welcome the feedback. >>> >>> To be added to .well-known, SP Config, or whatever we end up w/ >>> in the long-run (i.e., section 9 of the draft): >>> >>> The following multi-valued attribute is defined in addition to >>> the common attributes defined in Core Schema: >>> >>> entitlementSchemes >>> >>> A complex type that specifies supported Entitlement Scheme >>> properties. Instead of the standard Canonical Value for type, >>> this attribute defines the following Canonical Values to >>> represent common schemes: none and basic. REQUIRED. >>> >>> name >>> >>> The common Entitlement Scheme name; e.g., XACML. REQUIRED. >>> >>> description >>> >>> A description of the Entitlement Scheme. REQUIRED. >>> >>> specUrl >>> >>> An HTTP addressable URL pointing to the Entitlement Scheme's >>> specification. OPTIONAL. >>> >>> documentationUrl >>> >>> An HTTP addressable URL pointing to the Entitlement Scheme's >>> usage documentation. OPTIONAL. >>> >>> When basic is supported, a service provider MUST also support >>> the following single value attribute which defines the >>> entitlements that it supports. >>> >>> basicEntitlements >>> >>> A list of string values that represent the entitlements that the >>> service provider supports. REQUIRED if the basic Entitlement >>> Scheme is supported. >>> >>> To replace entitlements in section 6.2 of the core schema doc: >>> >>> entitlements >>> >>> A complex attribute containing the entitlements of a User. >>> Entitlements are the rights that a User has at the Service >>> Provider as expressed according to the policy language >>> stipulated by the type sub-attribute. A basic syntax is defined >>> in this specification that allows the Client to specify a list >>> of entitlements as strings. There are NO canonical values >>> specified, but a Client can learn what values are supported by >>> requesting the Service Provider Configuration Resource and >>> examining the list found in the basicEntitlements attribute. >>> >>> type >>> >>> A string indicating the type of policy language. The only >>> acceptable canonical value is basic. REQUIRED. If the type of >>> policy is not understood, the Service Provider MUST return an >>> HTTP 400, bad request. >>> >>> value >>> >>> The entitlements of the user. If the type is basic, this MUST be >>> a list of strings where the elements are from the list of >>> supported entitlements defined in the Service Provider's >>> basicEntitlements schema attribute. If the type is NOT basic, >>> then the value MUST be a complex object that the Service >>> Provider is expected to know how to process. If the complex >>> object cannot be processed according to the syntax of the policy >>> language specified in the type attribute, the Service Provider >>> MUST return an HTTP 400, bad request. >>> >>> A non-normative examples of using the basic Entitlement Scheme >>> is as follows: >>> >>> { >>> "entitlements" : { >>> "type": "basic", >>> "value" : [ "calendar", "email", "spreadsheet" ] >>> } >>> } >>> >>> Service Providers MAY support additional policy languages >>> instead of or in addition to the basic one define herein. For >>> example, a Service Provider may support XACML and the Client may >>> send the entitlements of a User in accordance to that >>> specification as in the following non-normative example: >>> >>> { >>> "entitlements" : { >>> "type" : "xacml", >>> "value" : { /* XACML policy encoded in JavaScript */ } >>> } >>> } >>> >>> -- >>> >>> Regards, >>> * >>> * >>> *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office >>> *Ping* *Identity* | >>> www.pingidentity.com >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - - - - - - - >>> *M:* +46 72 725 5655 >>> *Email:* tspencer@pingidentity.com >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - - - - - - - >>> *Connect with Ping* >>> Twitter: @pingidentity >>> LinkedIn: Ping's Identity Cloud >>> >>> Facebook: Ping Identity Page >>> >>> >>> *Connect with me* >>> Twitter: @travisspencer >>> LinkedIn: travisspencer >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> -- >> >> Regards, >> * >> * >> *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office >> *Ping* *Identity* | www.pingidentity.com >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> - - - - - >> *M:* +46 72 725 5655 >> *Email:* tspencer@pingidentity.com >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> - - - - - >> *Connect with Ping* >> Twitter: @pingidentity >> LinkedIn: Ping's Identity Cloud >> >> Facebook: Ping Identity Page >> >> *Connect with me* >> Twitter: @travisspencer >> LinkedIn: travisspencer >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > --------------000809020003000104030805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ...Phil stole my question!

Igor

On 5/29/2012 12:03 PM, Phil Hunt wrote:
Why not simply encode it since the endpoint likely wants it back in XML form anyway?  


On 2012-05-29, at 1:21 AM, Travis Spencer wrote:

Whatever policy language is used, it needs to be relayed in a JSON message because that data model is MTI. So, you could take a XACML message, for example, and escape it or encode it in JSON as it's passed along. Whatever policy language is used and however its packaged up, it needs to be able to slip in via JSON; otherwise, it won't be compatible w/ SCIM.

On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:
Trevis,

 A question (out of curiosity, since you have mentioned that all examples are non-normative):  Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment  a JSON structure here?

With thanks,

Igor



On 5/25/2012 5:01 AM, Travis Spencer wrote:
Hi All,

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

 

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

 

entitlementSchemes

 

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

 

name

 

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

 

description

 

A description of the Entitlement Scheme. REQUIRED.

 

specUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

 

documentationUrl

 

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

 

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

 

basicEntitlements

 

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

 

To replace entitlements in section 6.2 of the core schema doc:

 

entitlements

 

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

 

type

 

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

 

value

 

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

 

A non-normative examples of using the basic Entitlement Scheme is as follows:

 

{
  "entitlements" : {
     "type": "basic",
      "value" : [ "calendar", "email", "spreadsheet" ]
  }
}

 

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

 

{
  "entitlements" : {
         "type" : "xacml",
         "value" : { /* XACML policy encoded in JavaScript */ }
   }
}

--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer
 



_______________________________________________
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




--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655
Email: tspencer@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn: Ping's Identity Cloud    
Facebook: Ping Identity Page
Connect with me
Twitter: @travisspencer
LinkedIn: travisspencer


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

--------------000809020003000104030805-- From barryleiba.mailing.lists@gmail.com Tue May 29 16:45:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75921F86CE for ; Tue, 29 May 2012 16:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLxLae2+9Cmd for ; Tue, 29 May 2012 16:45:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F135721F86BB for ; Tue, 29 May 2012 16:45:29 -0700 (PDT) Received: by lagv3 with SMTP id v3so3316769lag.31 for ; Tue, 29 May 2012 16:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=RwMWv7UyCv+3IfJXnVfjmxzH2YeGOr4tMXBFskPWzew=; b=c6nGTf/Dt5nOIOO3a4N5mAuMVMhl7avAgcyi3S6A49f9dJ4c7c8lk980sJhvgG1Co5 JgtgGfUAcRtqQhGaVxlj0ngiSd24ff+gFxZeDgQSnEDCT4OevN+pJYpFxiu3Umejs3Le 5EK0ipwNn3GBzbSW/SHK143jTHdNKH9vKG0UumxA23Na7dEZLjAfj7JeCFos4eegb3fc jMUcVbpdpFNabA15c/vP7fOGxo0CJpJI2p4VdkkKF03xboCj3otW1tx/yYQDhkZ+HotQ bxq/1i1QQY7T1PmMpq5/boZeNg+0FJFmnpHcS5ht/79kTbrYW2MsnM7syg3LPsASD/RP qXpA== MIME-Version: 1.0 Received: by 10.152.106.12 with SMTP id gq12mr13254519lab.17.1338335128848; Tue, 29 May 2012 16:45:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Tue, 29 May 2012 16:45:28 -0700 (PDT) Date: Tue, 29 May 2012 19:45:28 -0400 X-Google-Sender-Auth: VTOJYkVVTeFvKXQ4uvIfsfwhXUQ Message-ID: From: Barry Leiba To: scim@ietf.org Content-Type: multipart/mixed; boundary=f46d04088de3f20b8304c1356d9d Subject: [scim] SCIM charter has passed the first step X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 23:45:31 -0000 --f46d04088de3f20b8304c1356d9d Content-Type: text/plain; charset=ISO-8859-1 The IESG just approved the attached charter for SCIM (System for Cross-domain Identity Management) for IETF and external review. You should see the official announcement soon. And I will say right here that the discussion of the name is now OVER, and I will not look kindly on any further chatter about THAT, don't'cha know. The charter will be back for final approval on the 7 June telechat. I don't expect serious objections during the review period, so I don't anticipate any problems. Expect to see a final "SCIM is chartered" announcement the week of 11 June, unless you hear something otherwise from me before then. Barry --f46d04088de3f20b8304c1356d9d Content-Type: text/plain; charset=US-ASCII; name="charter-ietf-scim-00-02.txt" Content-Disposition: attachment; filename="charter-ietf-scim-00-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2tlzoxl0 U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkKCkNoYWly KHMpOiBUQkQgCgpBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToKICBQZXRlIFJlc25pY2sg PHByZXNuaWNrQHF1YWxjb21tLmNvbT4gCiAgQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0 ZXIub3JnPiAKCk1haWxpbmcgTGlzdHM6CiAgR2VuZXJhbCBEaXNjdXNzaW9uOiBzY2ltQGlldGYu b3JnCiAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NjaW0KICBBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zY2ltLwogCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgpUaGUg U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgd29ya2lu ZyBncm91cAp3aWxsIHN0YW5kYXJkaXplIG1ldGhvZHMgZm9yIGNyZWF0aW5nLCByZWFkaW5nLCBz ZWFyY2hpbmcsIG1vZGlmeWluZywKYW5kIGRlbGV0aW5nIHVzZXIgaWRlbnRpdGllcyBhbmQgaWRl bnRpdHktcmVsYXRlZCBvYmplY3RzIGFjcm9zcwphZG1pbmlzdHJhdGl2ZSBkb21haW5zLCB3aXRo IHRoZSBnb2FsIG9mIHNpbXBsaWZ5aW5nIGNvbW1vbiB0YXNrcwpyZWxhdGVkIHRvIHVzZXIgaWRl bnRpdHkgbWFuYWdlbWVudCBpbiBzZXJ2aWNlcyBhbmQgYXBwbGljYXRpb25zLgoKIlN0YW5kYXJk aXplIiBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2ls bApkZXZlbG9wIG5ldyB0ZWNobm9sb2dpZXMuICBGb3IgZXhhbXBsZSwgdGhlIGV4aXN0aW5nIHNw ZWNpZmljYXRpb25zCmZvciAiU0NJTSAxLjAiIHByb3ZpZGUgUkVTVGZ1bCBpbnRlcmZhY2VzIG9u IHRvcCBvZiBIVFRQIHJhdGhlciB0aGFuCmRlZmluaW5nIGEgbmV3IGFwcGxpY2F0aW9uIHByb3Rv Y29sLgoKVG9kYXksIGRpc3RyaWJ1dGVkIGlkZW50aXR5IG1hbmFnZW1lbnQgYWNyb3NzIGFkbWlu aXN0cmF0aXZlIGRvbWFpbnMKaXMgY29tcGxpY2F0ZWQgYnkgYSBsYWNrIG9mIHByb3RvY29sIGFu ZCBzY2hlbWEgc3RhbmRhcmRpemF0aW9uCmJldHdlZW4gY29uc3VtZXJzIGFuZCBwcm9kdWNlcnMg b2YgaWRlbnRpdGllcy4gIFRoaXMgaGFzIGxlZCB0byBhCm51bWJlciBvZiBhcHByb2FjaGVzLCBp bmNsdWRpbmcgZXJyb3ItcHJvbmUgbWFudWFsIGFkbWluaXN0cmF0aW9uIGFuZApidWxrIGZpbGUg dXBsb2FkcywgYXMgd2VsbCBhcyBwcm9wcmlldGFyeSBwcm90b2NvbHMgYW5kIG1lZGlhdGlvbgpk ZXZpY2VzIHRoYXQgbXVzdCBiZSBhZGFwdGVkIHRvIGVhY2ggc2VydmljZSBmb3IgZWFjaCBvcmdh bml6YXRpb24uIApXaGlsZSB0aGVyZSBpcyBleGlzdGluZyB3b3JrIGluIHRoZSBmaWVsZCwgaXQg aGFzIG5vdCBiZWVuIHdpZGVseQphZG9wdGVkIGZvciBhIHZhcmlldHkgb2YgcmVhc29ucywgaW5j bHVkaW5nIGEgbGFjayBvZiBjb21tb24gYXJ0aWZhY3RzCnN1Y2ggYXMgc2NoZW1hLCB0b29sc2V0 cywgYW5kIGxpYnJhcmllcy4KClRoZSBTQ0lNIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXZlbG9wIHRo ZSBjb3JlIHNjaGVtYSBhbmQgUkVTVGZ1bAppbnRlcmZhY2VzIHRvIGFkZHJlc3MgdGhlc2UgcHJv YmxlbXMuICBJbml0aWFsbHksIHRoZSBncm91cCB3aWxsIGZvY3VzCm9uCi0gYSBzY2hlbWEgZGVm aW5pdGlvbgotIGEgc2V0IG9mIG9wZXJhdGlvbnMgZm9yIGNyZWF0aW9uLCBtb2RpZmljYXRpb24s IGFuZCBkZWxldGlvbiBvZiB1c2VycwotIHNjaGVtYSBkaXNjb3ZlcnkKLSByZWFkIGFuZCBzZWFy Y2gKLSBidWxrIG9wZXJhdGlvbnMKLSBtYXBwaW5nIGJldHdlZW4gdGhlIGluZXRPcmdQZXJzb24g TERBUCBvYmplY3QgY2xhc3MgKFJGQyAyNzk4KSBhbmQKICB0aGUgU0NJTSBzY2hlbWEKCkl0IHdp bGwgZm9sbG93IHRoYXQgYnkgY29uc2lkZXJpbmcgZXh0ZW5zaW9ucyBmb3IgY2xpZW50IHRhcmdl dGluZyBvZgpzcGVjaWZpYyBTQ0lNIGVuZHBvaW50cyBhbmQgU0FNTCBiaW5kaW5nLiAgVGhlIGFw cHJvYWNoIHdpbGwgYmUKZXh0ZW5zaWJsZS4KClRoZSBncm91cCB3aWxsIHVzZSwgYXMgc3RhcnRp bmcgcG9pbnRzLCB0aGUgZm9sbG93aW5nIGRyYWZ0cyBpbiB0aGUKZm9sbG93aW5nIHdheXM6CiAg ICAgZHJhZnQtc2NpbS11c2UtY2FzZXMtMDAgYXMgdGhlIGluaXRpYWwgdXNlIGNhc2VzIGZvciBT Q0lNCiAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMCBhcyB0aGUgc2NoZW1hIHNwZWNpZmlj YXRpb24KICAgICBkcmFmdC1zY2ltLWFwaS0wMCBhcyB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlv bgoKVGhlc2UgZHJhZnRzIGFyZSBiYXNlZCBvbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucywgd2hp Y2ggdG9nZXRoZXIgYXJlCmNvbW1vbmx5IGtub3duIGFzIFNDSU0gMS4wLiAgQmVjYXVzZSB0aGVy ZSBpcyBleGlzdGluZyB3b3JrIHdpdGgKZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLCBzb21lIGNv bnNpZGVyYXRpb24gc2hvdWxkIGJlIGdpdmVuIHRvCmJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHRo b3VnaCBnZXR0aW5nIGl0IHJpZ2h0IHRha2VzIHByaW9yaXR5LiAgVGhpcwpncm91cCB3aWxsIGNv bnNpZGVyIHRoZSBvcGVyYXRpb25hbCBleHBlcmllbmNlIGdhdGhlcmVkIGZyb20gdGhlCmV4aXN0 aW5nIHdvcmssIGFzIHdlbGwgYXMgZXhwZXJpZW5jZXMgd2l0aCB3b3JrIGRvbmUgYnkgb3RoZXIg Ym9kaWVzLAppbmNsdWRpbmcgdGhlIE9BU0lTIFByb3Zpc2lvbmluZyBUQy4KClRoZSB1c2UgY2Fz ZXMgZG9jdW1lbnQgd2lsbCBiZSBhICJsaXZpbmcgZG9jdW1lbnQiLCBndWlkaW5nIHRoZQp3b3Jr aW5nIGdyb3VwIGR1cmluZyBpdHMgZGV2ZWxvcG1lbnQgb2YgdGhlIHN0YW5kYXJkcy4gIFRoZSBn cm91cCBtYXkKdGFrZSBzbmFwc2hvdHMgb2YgdGhhdCBkb2N1bWVudCBmb3IgSW5mb3JtYXRpb25h bCBwdWJsaWNhdGlvbiwgdG8Kc2VydmUgYXMgZG9jdW1lbnRhdGlvbiBvZiB0aGUgbW90aXZhdGlv biBmb3IgdGhlIHdvcmsgaW4gcHJvZ3Jlc3MKYW5kIHRvIHNpbWlsYXJseSBndWlkZSBwbGFubmlu ZyBhbmQgaW1wbGVtZW50YXRpb24uCgpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlIFByb3Bvc2VkIFN0 YW5kYXJkcyBmb3IgYSBzY2hlbWEsIGEgUkVTVC1iYXNlZApwcm90b2NvbCwgYW5kIGEgU0FNTCBi aW5kaW5nLCBhcyB3ZWxsIGFzIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQKZGVmaW5pbmcgYW4g TERBUCBtYXBwaW5nLiBJbiBkb2luZyBzbywgdGhlIGdyb3VwIHdpbGwgbWFrZSB0aGUKdGVybWlu b2xvZ3kgY29uc2lzdGVudCwgaWRlbnRpZnkgYW55IGZ1bmN0aW9uYWwgZ2FwcyB0aGF0IHdvdWxk IGJlCnVzZWZ1bCBmb3IgZnV0dXJlIHdvcmssIGFkZHJlc3MgaW50ZXJuYXRpb25hbGl6YXRpb24s IGFuZCBwcm92aWRlCmd1aWRlbGluZXMgYW5kIG1lY2hhbmlzbXMgZm9yIGV4dGVuc2liaWxpdHku CgpJbiBhZGRpdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBlbnN1cmUgdGhhdCB0aGUgU0NJ TSBwcm90b2NvbAplbWJvZGllcyBnb29kIHNlY3VyaXR5IHByYWN0aWNlcy4gR2l2ZW4gYm90aCB0 aGUgc2Vuc2l0aXZpdHkgb2YgdGhlCmluZm9ybWF0aW9uIGJlaW5nIGNvbnZleWVkIGluIFNDSU0g bWVzc2FnZXMgYW5kIHRoZSByZWd1bGF0b3J5CnJlcXVpcmVtZW50cyByZWdhcmRpbmcgdGhlIHBy aXZhY3kgb2YgcGVyc29uYWxseSBpZGVudGlmaWFibGUKaW5mb3JtYXRpb24sIHRoZSB3b3JraW5n IGdyb3VwIHdpbGwgcGF5IHBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIGlzc3Vlcwphcm91bmQgYXV0 aG9yaXphdGlvbiwgYXV0aGVudGljaXR5LCBhbmQgcHJpdmFjeS4KClRoZSBncm91cCBjb25zaWRl cnMgdGhlIGZvbGxvd2luZyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZ3JvdXA6CiAgICAgRGVmaW5p bmcgbmV3IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMKICAgICBEZWZpbmluZyBuZXcgcG9saWN5L2F1 dGhvcml6YXRpb24gc2NoZW1lcwoKTWlsZXN0b25lcwoKMDYvMjAxMiAgICBJbml0aWFsIGFkb3B0 aW9uIG9mIFNDSU0gdXNlIGNhc2VzLCBhcyBhIGxpdmluZyBkb2N1bWVudAowNi8yMDEyICAgIElu aXRpYWwgYWRvcHRpb24gb2YgU0NJTSBjb3JlIHNjaGVtYQowOC8yMDEyICAgIEluaXRpYWwgYWRv cHRpb24gb2YgU0NJTSByZXN0ZnVsIGludGVyZmFjZSBkcmFmdAoxMi8yMDEyICAgIFNuYXBzaG90 IHZlcnNpb24gb2YgU0NJTSB1c2UgY2FzZXMgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIChwb3Nz aWJseSkKMTIvMjAxMiAgICBQcm9wb3NhbCBmb3IgY2xpZW50IHRhcmdldGluZyBvZiBTQ0lNIGVu ZHBvaW50cwowMS8yMDEzICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSBMREFQIGluZXRPcmdQ ZXJzb24gbWFwcGluZyBkcmFmdAowMi8yMDEzICAgIFNDSU0gY29yZSBzY2hlbWEgdG8gSUVTRyBh cyBQcm9wb3NlZCBTdGFuZGFyZAowNS8yMDEzICAgIFNDSU0gcmVzdGZ1bCBpbnRlcmZhY2UgdG8g SUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZAowNi8yMDEzICAgIFNDSU0gTERBUCBpbmV0T3JnUGVy c29uIG1hcHBpbmcgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsCjA3LzIwMTMgICAgSW5pdGlhbCBh ZG9wdGlvbiBvZiBTQ0lNIFNBTUwgYmluZGluZ3MgZHJhZnQKMDgvMjAxMyAgICBDbGllbnQgdGFy Z2V0aW5nIG9mIFNDSU0gZW5kcG9pbnRzIHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQKMDkv MjAxMyAgICBTbmFwc2hvdCB1cGRhdGUgb2YgU0NJTSB1c2UgY2FzZXMgYXMgSW5mb3JtYXRpb25h bCAocG9zc2libHkpCjExLzIwMTMgICAgU0NJTSBTQU1MIGJpbmRpbmdzIHRvIElFU0cgYXMgUHJv cG9zZWQgU3RhbmRhcmQKMDEvMjAxNCAgICBXb3JrIGNvbXBsZXRlZDsgZGlzY3VzcyByZS1jaGFy dGVyCg== --f46d04088de3f20b8304c1356d9d-- From moransar@cisco.com Tue May 29 22:39:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A27721F86B4 for ; Tue, 29 May 2012 22:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyxa0LMQt7+7 for ; Tue, 29 May 2012 22:39:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E182A21F86B2 for ; Tue, 29 May 2012 22:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=1025; q=dns/txt; s=iport; t=1338356382; x=1339565982; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AcdbGswO/N66IJ9epg5SfJG0Z+pWiozGN6IbA2u5WGQ=; b=iaoeD7BfO7XJisnsDiEBMLSO3yyU9llNh0kUNYNinj64uUojO6kKeT0p ETCAVLTmn1rF8PwahDsK1iQOREi27TMchlEMXOBX1pZ0GvsPTpJCKaQow uI5/aNTHyWbaJEYS1J/+tC3q2ctIu9BTwD0ulvjGy6UgMKK0WfLYKTinx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFqxxU+tJXG9/2dsb2JhbAA7CbQhgQeCFwEBAQQSAR0KSwQCAQgRBAEBCwYXAQYBRQkIAQEEARIIEgiHaZlDoBKLBRGEUWADiECaZIFmgn4 X-IronPort-AV: E=Sophos;i="4.75,681,1330905600"; d="scan'208";a="87784034" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 30 May 2012 05:39:41 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4U5dfqU017380; Wed, 30 May 2012 05:39:41 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 00:39:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 00:39:40 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE01624726@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] SCIM charter has passed the first step Thread-Index: Ac099SRNGW9rvBVETLOvYr2WJB5RigAMUHtg References: From: "Morteza Ansari (moransar)" To: "Barry Leiba" , X-OriginalArrivalTime: 30 May 2012 05:39:40.0647 (UTC) FILETIME=[9BC1EF70:01CD3E26] Subject: Re: [scim] SCIM charter has passed the first step X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 05:39:43 -0000 Thanks for the update Barry. This is great news and I would be very happy NOT to talk about "names" for a very long time :) Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, May 29, 2012 4:45 PM To: scim@ietf.org Subject: [scim] SCIM charter has passed the first step The IESG just approved the attached charter for SCIM (System for Cross-domain Identity Management) for IETF and external review. You should see the official announcement soon. And I will say right here that the discussion of the name is now OVER, and I will not look kindly on any further chatter about THAT, don't'cha know. The charter will be back for final approval on the 7 June telechat. I don't expect serious objections during the review period, so I don't anticipate any problems. Expect to see a final "SCIM is chartered" announcement the week of 11 June, unless you hear something otherwise from me before then. Barry From iesg-secretary@ietf.org Thu May 31 08:08:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9983F21F8778; Thu, 31 May 2012 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCGRasUAWYCB; Thu, 31 May 2012 08:08:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFE21F877D; Thu, 31 May 2012 08:08:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2012 08:08:37 -0700 Cc: scim@ietf.org Subject: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:08:38 -0000 A new IETF working group has been proposed in the Applications = Area. The IESG has not made any determination as yet. The following = draft charter was submitted, and is provided for informational purposes = only. Please send your comments to the IESG mailing list (iesg@ietf.org) = by June 7, 2012. = = System for Cross-domain Identity Management (SCIM) ---------------------------------------------- Status: Proposed Working Group Last updated: 2012-05-29 Chair(s): TBD = Applications Area Director(s): Pete Resnick = Barry Leiba = Mailing Lists: General Discussion: scim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scim Archive: http://www.ietf.org/mail-archive/web/scim/ = Description of Working Group: The System for Cross-domain Identity Management (SCIM) working group will standardize methods for creating, reading, searching, modifying, and deleting user identities and identity-related objects across administrative domains, with the goal of simplifying common tasks related to user identity management in services and applications. "Standardize" does not necessarily mean that the working group will develop new technologies. For example, the existing specifications for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than defining a new application protocol. Today, distributed identity management across administrative domains is complicated by a lack of protocol and schema standardization between consumers and producers of identities. This has led to a number of approaches, including error-prone manual administration and bulk file uploads, as well as proprietary protocols and mediation devices that must be adapted to each service for each organization. = While there is existing work in the field, it has not been widely adopted for a variety of reasons, including a lack of common artifacts such as schema, toolsets, and libraries. The SCIM working group will develop the core schema and RESTful interfaces to address these problems. Initially, the group will focus on - a schema definition - a set of operations for creation, modification, and deletion of users - schema discovery - read and search - bulk operations - mapping between the inetOrgPerson LDAP object class (RFC 2798) and the SCIM schema It will follow that by considering extensions for client targeting of specific SCIM endpoints and SAML binding. The approach will be extensible. The group will use, as starting points, the following drafts in the following ways: draft-scim-use-cases-00 as the initial use cases for SCIM draft-scim-core-schema-00 as the schema specification draft-scim-api-00 as the protocol specification These drafts are based on existing specifications, which together are commonly known as SCIM 1.0. Because there is existing work with existing implementations, some consideration should be given to backward compatibility, though getting it right takes priority. This group will consider the operational experience gathered from the existing work, as well as experiences with work done by other bodies, including the OASIS Provisioning TC. The use cases document will be a "living document", guiding the working group during its development of the standards. The group may take snapshots of that document for Informational publication, to serve as documentation of the motivation for the work in progress and to similarly guide planning and implementation. The group will produce Proposed Standards for a schema, a REST-based protocol, and a SAML binding, as well as an Informational document defining an LDAP mapping. In doing so, the group will make the terminology consistent, identify any functional gaps that would be useful for future work, address internationalization, and provide guidelines and mechanisms for extensibility. In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues around authorization, authenticity, and privacy. The group considers the following out of scope for this group: Defining new authentication schemes Defining new policy/authorization schemes Milestones 06/2012 Initial adoption of SCIM use cases, as a living document 06/2012 Initial adoption of SCIM core schema 08/2012 Initial adoption of SCIM restful interface draft 12/2012 Snapshot version of SCIM use cases to IESG as Informational (pos= sibly) 12/2012 Proposal for client targeting of SCIM endpoints 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft 02/2013 SCIM core schema to IESG as Proposed Standard 05/2013 SCIM restful interface to IESG as Proposed Standard 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational 07/2013 Initial adoption of SCIM SAML bindings draft 08/2013 Client targeting of SCIM endpoints to IESG as Proposed Standard 09/2013 Snapshot update of SCIM use cases as Informational (possibly) 11/2013 SCIM SAML bindings to IESG as Proposed Standard 01/2014 Work completed; discuss re-charter From soohongp@gmail.com Thu May 31 19:12:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4A11E80E0 for ; Thu, 31 May 2012 19:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fni3-lvZ9HbV for ; Thu, 31 May 2012 19:12:36 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97F9711E80E6 for ; Thu, 31 May 2012 19:12:35 -0700 (PDT) Received: by bkty8 with SMTP id y8so1599148bkt.31 for ; Thu, 31 May 2012 19:12:34 -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 :content-type:content-transfer-encoding; bh=OlAbLvHssGtXSKzamxObJLKL+PRD/YldlZb3+pjvF00=; b=reMSsEfptnxuHnr9vLZyfCWn8UGFTMiQ3II1pJ9ObHPpeVrFsNWHKCa9MlXkgkIdJ/ h2A9QUVVVB681aoFCe/hV9WlspzsHT2ecZ1F6BK3bnAhtOGp1FcZiTRmmlnmrCV9SqUp TAnEHmbYPNtNnpaV9TRh+fuefncOx78wTq6oob6XTflBRP0k9wYtJ+m8Rt4mLNx+24fP hrMaJ32jPpGZ9mZuaHWd0il7Tu1JJpe5aEvMKjDlRLoEZWMjxrlFLoU0u5rTdReBEk8w RpB1nmL+tNyA+ryUL7CA7IUfNr4TxUCDwTYbtajTDzsKOPUWl1k3cln3E9+PtW3kS4NN /tyg== MIME-Version: 1.0 Received: by 10.204.155.92 with SMTP id r28mr381552bkw.130.1338516754575; Thu, 31 May 2012 19:12:34 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Thu, 31 May 2012 19:12:34 -0700 (PDT) In-Reply-To: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> Date: Fri, 1 Jun 2012 11:12:34 +0900 Message-ID: From: Daniel Park To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:12:37 -0000 Sorry for asking, but I am very interested in this work and trying to catch up the related drafts quickly. However, I didn't find out them listed in the charter. Is it already published ? or just candidate items to be written down later on ? If available, please let kindly me know the live links for them. > draft-scim-use-cases-00 as the initial use cases for SCIM > draft-scim-core-schema-00 as the schema specification Thanks in advance, Daniel --=20 Soohong Daniel Park Samsung Electronics, SWC On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary w= rote: > A new IETF working group has been proposed in the Applications > Area. =A0The IESG has not made any determination as yet. The following > draft charter was submitted, and is provided for informational purposes > only. Please send your comments to the IESG mailing list (iesg@ietf.org) > by June 7, 2012. > > System for Cross-domain Identity Management (SCIM) > ---------------------------------------------- > Status: Proposed Working Group > > Last updated: 2012-05-29 > > Chair(s): TBD > > Applications Area Director(s): > =A0Pete Resnick > =A0Barry Leiba > > Mailing Lists: > =A0General Discussion: scim@ietf.org > =A0To Subscribe: =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/scim > =A0Archive: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/mail-archive/web/s= cim/ > > Description of Working Group: > > The System for Cross-domain Identity Management (SCIM) working group > will standardize methods for creating, reading, searching, modifying, > and deleting user identities and identity-related objects across > administrative domains, with the goal of simplifying common tasks > related to user identity management in services and applications. > > "Standardize" does not necessarily mean that the working group will > develop new technologies. =A0For example, the existing specifications > for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than > defining a new application protocol. > > Today, distributed identity management across administrative domains > is complicated by a lack of protocol and schema standardization > between consumers and producers of identities. =A0This has led to a > number of approaches, including error-prone manual administration and > bulk file uploads, as well as proprietary protocols and mediation > devices that must be adapted to each service for each organization. > While there is existing work in the field, it has not been widely > adopted for a variety of reasons, including a lack of common artifacts > such as schema, toolsets, and libraries. > > The SCIM working group will develop the core schema and RESTful > interfaces to address these problems. =A0Initially, the group will focus > on > - a schema definition > - a set of operations for creation, modification, and deletion of users > - schema discovery > - read and search > - bulk operations > - mapping between the inetOrgPerson LDAP object class (RFC 2798) and > =A0the SCIM schema > > It will follow that by considering extensions for client targeting of > specific SCIM endpoints and SAML binding. =A0The approach will be > extensible. > > The group will use, as starting points, the following drafts in the > following ways: > =A0 =A0 draft-scim-use-cases-00 as the initial use cases for SCIM > =A0 =A0 draft-scim-core-schema-00 as the schema specification > =A0 =A0 draft-scim-api-00 as the protocol specification > > These drafts are based on existing specifications, which together are > commonly known as SCIM 1.0. =A0Because there is existing work with > existing implementations, some consideration should be given to > backward compatibility, though getting it right takes priority. =A0This > group will consider the operational experience gathered from the > existing work, as well as experiences with work done by other bodies, > including the OASIS Provisioning TC. > > The use cases document will be a "living document", guiding the > working group during its development of the standards. =A0The group may > take snapshots of that document for Informational publication, to > serve as documentation of the motivation for the work in progress > and to similarly guide planning and implementation. > > The group will produce Proposed Standards for a schema, a REST-based > protocol, and a SAML binding, as well as an Informational document > defining an LDAP mapping. In doing so, the group will make the > terminology consistent, identify any functional gaps that would be > useful for future work, address internationalization, and provide > guidelines and mechanisms for extensibility. > > In addition, the working group will ensure that the SCIM protocol > embodies good security practices. Given both the sensitivity of the > information being conveyed in SCIM messages and the regulatory > requirements regarding the privacy of personally identifiable > information, the working group will pay particular attention to issues > around authorization, authenticity, and privacy. > > The group considers the following out of scope for this group: > =A0 =A0 Defining new authentication schemes > =A0 =A0 Defining new policy/authorization schemes > > Milestones > > 06/2012 =A0 =A0Initial adoption of SCIM use cases, as a living document > 06/2012 =A0 =A0Initial adoption of SCIM core schema > 08/2012 =A0 =A0Initial adoption of SCIM restful interface draft > 12/2012 =A0 =A0Snapshot version of SCIM use cases to IESG as Informationa= l (possibly) > 12/2012 =A0 =A0Proposal for client targeting of SCIM endpoints > 01/2013 =A0 =A0Initial adoption of SCIM LDAP inetOrgPerson mapping draft > 02/2013 =A0 =A0SCIM core schema to IESG as Proposed Standard > 05/2013 =A0 =A0SCIM restful interface to IESG as Proposed Standard > 06/2013 =A0 =A0SCIM LDAP inetOrgPerson mapping to IESG as Informational > 07/2013 =A0 =A0Initial adoption of SCIM SAML bindings draft > 08/2013 =A0 =A0Client targeting of SCIM endpoints to IESG as Proposed Sta= ndard > 09/2013 =A0 =A0Snapshot update of SCIM use cases as Informational (possib= ly) > 11/2013 =A0 =A0SCIM SAML bindings to IESG as Proposed Standard > 01/2014 =A0 =A0Work completed; discuss re-charter > From trey.drake@unboundid.com Thu May 31 19:21:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446DF11E80DB for ; Thu, 31 May 2012 19:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr045piMP2gR for ; Thu, 31 May 2012 19:21:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72111E8072 for ; Thu, 31 May 2012 19:21:55 -0700 (PDT) Received: by yenq13 with SMTP id q13so1550597yen.31 for ; Thu, 31 May 2012 19:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DDbezj9HvegRJ+/uQ/64ePcVrgOh9M3C8OPUSR1SAlw=; b=ou7OXmcaTYrXZv9eS2/qmtCzWKAlE2gBHbmm25gwsRXI+xL/oIL7p6BEWlkJDbVnRt BbutrDEu8J9jLbC3Ly7zoZUWmxKDflX3LIX+EFRgMu8JnkG/LfV1MBUDXnZf8u2I2i/N MPGNxy8bfOQY1hTTrq4beT3pxm8d3HbxADVskrh3vdl0zmIhWyh/2rAFtpUbLQfCgabs tx/ro57guV2fGG8h5ABXBk8pvWgfSc1q73HeCfuuxLj+qbObIbTh4cdegON23fsmT5PO XJZoyHRtNbwHvdjJspGbkUMUsFSU3HHqfoyRlu4f0gWBIfEOAi2MWwbCTFF8OT3xXeb5 J2cA== Received: by 10.236.126.133 with SMTP id b5mr956432yhi.50.1338517314708; Thu, 31 May 2012 19:21:54 -0700 (PDT) Received: from [192.168.5.198] (ip-64-134-188-79.public.wayport.net. [64.134.188.79]) by mx.google.com with ESMTPS id b4sm787097anh.16.2012.05.31.19.21.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 19:21:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Trey Drake In-Reply-To: Date: Thu, 31 May 2012 21:21:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> To: Daniel Park X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnqZjLiINhV7XIz+315Anfhv6vy/P054tKd/vf8AL5MNhEuKrIQF94w5EqklHarKMjky+aM Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:21:56 -0000 Hi Daniel. The drafts are posted @ API: https://datatracker.ietf.org/doc/draft-scim-api/ Schema: https://datatracker.ietf.org/doc/draft-scim-core-schema/ Thanks, Trey On May 31, 2012, at 9:12 PM, Daniel Park wrote: > Sorry for asking, but I am very interested in this work and trying to > catch up the related drafts quickly. However, I didn't find out them > listed in the charter. Is it already published ? or just candidate > items to be written down later on ? > If available, please let kindly me know the live links for them. >=20 >> draft-scim-use-cases-00 as the initial use cases for SCIM >> draft-scim-core-schema-00 as the schema specification >=20 >=20 > Thanks in advance, Daniel >=20 > --=20 > Soohong Daniel Park > Samsung Electronics, SWC >=20 > On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary = wrote: >> A new IETF working group has been proposed in the Applications >> Area. The IESG has not made any determination as yet. The following >> draft charter was submitted, and is provided for informational = purposes >> only. Please send your comments to the IESG mailing list = (iesg@ietf.org) >> by June 7, 2012. >>=20 >> System for Cross-domain Identity Management (SCIM) >> ---------------------------------------------- >> Status: Proposed Working Group >>=20 >> Last updated: 2012-05-29 >>=20 >> Chair(s): TBD >>=20 >> Applications Area Director(s): >> Pete Resnick >> Barry Leiba >>=20 >> Mailing Lists: >> General Discussion: scim@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/scim >> Archive: http://www.ietf.org/mail-archive/web/scim/ >>=20 >> Description of Working Group: >>=20 >> The System for Cross-domain Identity Management (SCIM) working group >> will standardize methods for creating, reading, searching, modifying, >> and deleting user identities and identity-related objects across >> administrative domains, with the goal of simplifying common tasks >> related to user identity management in services and applications. >>=20 >> "Standardize" does not necessarily mean that the working group will >> develop new technologies. For example, the existing specifications >> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than >> defining a new application protocol. >>=20 >> Today, distributed identity management across administrative domains >> is complicated by a lack of protocol and schema standardization >> between consumers and producers of identities. This has led to a >> number of approaches, including error-prone manual administration and >> bulk file uploads, as well as proprietary protocols and mediation >> devices that must be adapted to each service for each organization. >> While there is existing work in the field, it has not been widely >> adopted for a variety of reasons, including a lack of common = artifacts >> such as schema, toolsets, and libraries. >>=20 >> The SCIM working group will develop the core schema and RESTful >> interfaces to address these problems. Initially, the group will = focus >> on >> - a schema definition >> - a set of operations for creation, modification, and deletion of = users >> - schema discovery >> - read and search >> - bulk operations >> - mapping between the inetOrgPerson LDAP object class (RFC 2798) and >> the SCIM schema >>=20 >> It will follow that by considering extensions for client targeting of >> specific SCIM endpoints and SAML binding. The approach will be >> extensible. >>=20 >> The group will use, as starting points, the following drafts in the >> following ways: >> draft-scim-use-cases-00 as the initial use cases for SCIM >> draft-scim-core-schema-00 as the schema specification >> draft-scim-api-00 as the protocol specification >>=20 >> These drafts are based on existing specifications, which together are >> commonly known as SCIM 1.0. Because there is existing work with >> existing implementations, some consideration should be given to >> backward compatibility, though getting it right takes priority. This >> group will consider the operational experience gathered from the >> existing work, as well as experiences with work done by other bodies, >> including the OASIS Provisioning TC. >>=20 >> The use cases document will be a "living document", guiding the >> working group during its development of the standards. The group may >> take snapshots of that document for Informational publication, to >> serve as documentation of the motivation for the work in progress >> and to similarly guide planning and implementation. >>=20 >> The group will produce Proposed Standards for a schema, a REST-based >> protocol, and a SAML binding, as well as an Informational document >> defining an LDAP mapping. In doing so, the group will make the >> terminology consistent, identify any functional gaps that would be >> useful for future work, address internationalization, and provide >> guidelines and mechanisms for extensibility. >>=20 >> In addition, the working group will ensure that the SCIM protocol >> embodies good security practices. Given both the sensitivity of the >> information being conveyed in SCIM messages and the regulatory >> requirements regarding the privacy of personally identifiable >> information, the working group will pay particular attention to = issues >> around authorization, authenticity, and privacy. >>=20 >> The group considers the following out of scope for this group: >> Defining new authentication schemes >> Defining new policy/authorization schemes >>=20 >> Milestones >>=20 >> 06/2012 Initial adoption of SCIM use cases, as a living document >> 06/2012 Initial adoption of SCIM core schema >> 08/2012 Initial adoption of SCIM restful interface draft >> 12/2012 Snapshot version of SCIM use cases to IESG as = Informational (possibly) >> 12/2012 Proposal for client targeting of SCIM endpoints >> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft >> 02/2013 SCIM core schema to IESG as Proposed Standard >> 05/2013 SCIM restful interface to IESG as Proposed Standard >> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational >> 07/2013 Initial adoption of SCIM SAML bindings draft >> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed = Standard >> 09/2013 Snapshot update of SCIM use cases as Informational = (possibly) >> 11/2013 SCIM SAML bindings to IESG as Proposed Standard >> 01/2014 Work completed; discuss re-charter >>=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Thu May 31 19:22:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318A921F84D6 for ; Thu, 31 May 2012 19:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95DTN1rrEG43 for ; Thu, 31 May 2012 19:22:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 986FD21F8460 for ; Thu, 31 May 2012 19:22:35 -0700 (PDT) Received: from [192.168.0.7] (unknown [216.17.179.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6BBD4005A; Thu, 31 May 2012 20:39:07 -0600 (MDT) Message-ID: <4FC8276B.5080305@stpeter.im> Date: Thu, 31 May 2012 20:22:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Daniel Park References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:22:36 -0000 On 5/31/12 8:12 PM, Daniel Park wrote: > Sorry for asking, but I am very interested in this work and trying to > catch up the related drafts quickly. However, I didn't find out them > listed in the charter. Is it already published ? or just candidate > items to be written down later on ? > If available, please let kindly me know the live links for them. > >> draft-scim-use-cases-00 as the initial use cases for SCIM >> draft-scim-core-schema-00 as the schema specification Type "scim" at http://datatracker.ietf.org/ From soohongp@gmail.com Thu May 31 19:25:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9030E11E8089 for ; Thu, 31 May 2012 19:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.986 X-Spam-Level: X-Spam-Status: No, score=-2.986 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6cOhbk+cm5f for ; Thu, 31 May 2012 19:25:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1AEF11E8072 for ; Thu, 31 May 2012 19:25:42 -0700 (PDT) Received: by bkty8 with SMTP id y8so1605931bkt.31 for ; Thu, 31 May 2012 19:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rN+DXoEqVDhw4IBlwpM3dNakYJVd0y+4+7g0mnNCy8Y=; b=pfrL1KzJy+AVWg9TRgzTTONWM5lKI1nr/mP7qid/U8+HWU9pc9H/91f2fOy2akDRt6 QLTcTu2OdfvcVYtMuDdUkd1SqtsybAJMUG6sX5h0HhtyNPsfWhdS6pyrYdirtrkgB/Oh CINHbLRdX2hsa2B1xxtNpIniZnivA2RNAZB7eGcBMSBajSJrD1JAWiQLbcuggUjGx6ZD Y67Vytyv4aZVX7mSrbaoe0el5VQQ03rzYZ2jz7aHMTNMTy/1mKxEvT8JhlY3WwIdlq1I KRWAxPkxc0CFRkJeuJuUIYKSbXZcmuuqjHdCdcUh5EPA9l2rTySTpSIKb6UeWp7FBurF dnlQ== MIME-Version: 1.0 Received: by 10.205.117.3 with SMTP id fk3mr385879bkc.136.1338517541845; Thu, 31 May 2012 19:25:41 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Thu, 31 May 2012 19:25:41 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Thu, 31 May 2012 19:25:41 -0700 (PDT) In-Reply-To: References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> Date: Fri, 1 Jun 2012 11:25:41 +0900 Message-ID: From: Daniel Park To: Trey Drake Content-Type: multipart/alternative; boundary=00151747553e9b7ba604c15fe6b4 Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:25:44 -0000 --00151747553e9b7ba604c15fe6b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Trey for the prompt reply. What about use-case draft? Isn't it an official draft yet? Soohong Daniel Park from my Galaxy Note 2012. 6. 1. =EC=98=A4=EC=A0=84 11:21=EC=97=90 "Trey Drake" =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Hi Daniel. > > The drafts are posted @ > > API: https://datatracker.ietf.org/doc/draft-scim-api/ > Schema: https://datatracker.ietf.org/doc/draft-scim-core-schema/ > > Thanks, > Trey > > > On May 31, 2012, at 9:12 PM, Daniel Park wrote: > > > Sorry for asking, but I am very interested in this work and trying to > > catch up the related drafts quickly. However, I didn't find out them > > listed in the charter. Is it already published ? or just candidate > > items to be written down later on ? > > If available, please let kindly me know the live links for them. > > > >> draft-scim-use-cases-00 as the initial use cases for SCIM > >> draft-scim-core-schema-00 as the schema specification > > > > > > Thanks in advance, Daniel > > > > -- > > Soohong Daniel Park > > Samsung Electronics, SWC > > > > On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary > wrote: > >> A new IETF working group has been proposed in the Applications > >> Area. The IESG has not made any determination as yet. The following > >> draft charter was submitted, and is provided for informational purpose= s > >> only. Please send your comments to the IESG mailing list (iesg@ietf.or= g > ) > >> by June 7, 2012. > >> > >> System for Cross-domain Identity Management (SCIM) > >> ---------------------------------------------- > >> Status: Proposed Working Group > >> > >> Last updated: 2012-05-29 > >> > >> Chair(s): TBD > >> > >> Applications Area Director(s): > >> Pete Resnick > >> Barry Leiba > >> > >> Mailing Lists: > >> General Discussion: scim@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/scim > >> Archive: http://www.ietf.org/mail-archive/web/scim/ > >> > >> Description of Working Group: > >> > >> The System for Cross-domain Identity Management (SCIM) working group > >> will standardize methods for creating, reading, searching, modifying, > >> and deleting user identities and identity-related objects across > >> administrative domains, with the goal of simplifying common tasks > >> related to user identity management in services and applications. > >> > >> "Standardize" does not necessarily mean that the working group will > >> develop new technologies. For example, the existing specifications > >> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather than > >> defining a new application protocol. > >> > >> Today, distributed identity management across administrative domains > >> is complicated by a lack of protocol and schema standardization > >> between consumers and producers of identities. This has led to a > >> number of approaches, including error-prone manual administration and > >> bulk file uploads, as well as proprietary protocols and mediation > >> devices that must be adapted to each service for each organization. > >> While there is existing work in the field, it has not been widely > >> adopted for a variety of reasons, including a lack of common artifacts > >> such as schema, toolsets, and libraries. > >> > >> The SCIM working group will develop the core schema and RESTful > >> interfaces to address these problems. Initially, the group will focus > >> on > >> - a schema definition > >> - a set of operations for creation, modification, and deletion of user= s > >> - schema discovery > >> - read and search > >> - bulk operations > >> - mapping between the inetOrgPerson LDAP object class (RFC 2798) and > >> the SCIM schema > >> > >> It will follow that by considering extensions for client targeting of > >> specific SCIM endpoints and SAML binding. The approach will be > >> extensible. > >> > >> The group will use, as starting points, the following drafts in the > >> following ways: > >> draft-scim-use-cases-00 as the initial use cases for SCIM > >> draft-scim-core-schema-00 as the schema specification > >> draft-scim-api-00 as the protocol specification > >> > >> These drafts are based on existing specifications, which together are > >> commonly known as SCIM 1.0. Because there is existing work with > >> existing implementations, some consideration should be given to > >> backward compatibility, though getting it right takes priority. This > >> group will consider the operational experience gathered from the > >> existing work, as well as experiences with work done by other bodies, > >> including the OASIS Provisioning TC. > >> > >> The use cases document will be a "living document", guiding the > >> working group during its development of the standards. The group may > >> take snapshots of that document for Informational publication, to > >> serve as documentation of the motivation for the work in progress > >> and to similarly guide planning and implementation. > >> > >> The group will produce Proposed Standards for a schema, a REST-based > >> protocol, and a SAML binding, as well as an Informational document > >> defining an LDAP mapping. In doing so, the group will make the > >> terminology consistent, identify any functional gaps that would be > >> useful for future work, address internationalization, and provide > >> guidelines and mechanisms for extensibility. > >> > >> In addition, the working group will ensure that the SCIM protocol > >> embodies good security practices. Given both the sensitivity of the > >> information being conveyed in SCIM messages and the regulatory > >> requirements regarding the privacy of personally identifiable > >> information, the working group will pay particular attention to issues > >> around authorization, authenticity, and privacy. > >> > >> The group considers the following out of scope for this group: > >> Defining new authentication schemes > >> Defining new policy/authorization schemes > >> > >> Milestones > >> > >> 06/2012 Initial adoption of SCIM use cases, as a living document > >> 06/2012 Initial adoption of SCIM core schema > >> 08/2012 Initial adoption of SCIM restful interface draft > >> 12/2012 Snapshot version of SCIM use cases to IESG as Informational > (possibly) > >> 12/2012 Proposal for client targeting of SCIM endpoints > >> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping draft > >> 02/2013 SCIM core schema to IESG as Proposed Standard > >> 05/2013 SCIM restful interface to IESG as Proposed Standard > >> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational > >> 07/2013 Initial adoption of SCIM SAML bindings draft > >> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed > Standard > >> 09/2013 Snapshot update of SCIM use cases as Informational (possibl= y) > >> 11/2013 SCIM SAML bindings to IESG as Proposed Standard > >> 01/2014 Work completed; discuss re-charter > >> > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > > --00151747553e9b7ba604c15fe6b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Trey for the prompt reply.
What about use-case draft? Isn't it an official draft yet?

Soohong Daniel Park from my Galaxy Note

2012. 6. 1. =EC=98=A4=EC=A0=84 11:21=EC=97=90 &q= uot;Trey Drake" <trey.d= rake@unboundid.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Hi Daniel.

The drafts are posted @

API: https://datatracker.ietf.org/doc/draft-scim-api/
Schema: https://datatracker.ietf.org/doc/draft-scim-core-schema= /

Thanks,
Trey


On May 31, 2012, at 9:12 PM, Daniel Park wrote:

> Sorry for asking, but I am very interested in this work and trying to<= br> > catch up the related drafts quickly. However, I didn't find out th= em
> listed in the charter. Is it already published ? or just candidate
> items to be written down later on ?
> If available, please let kindly me know the live links for them.
>
>> draft-scim-use-cases-00 as the initial use cases for SCIM
>> draft-scim-core-schema-00 as the schema specification
>
>
> Thanks in advance, Daniel
>
> --
> Soohong Daniel Park
> Samsung Electronics, SWC
>
> On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary <iesg-secretary@ietf.org> wrote:
>> A new IETF working group has been proposed in the Applications
>> Area. =C2=A0The IESG has not made any determination as yet. The fo= llowing
>> draft charter was submitted, and is provided for informational pur= poses
>> only. Please send your comments to the IESG mailing list (iesg@ietf.org)
>> by June 7, 2012.
>>
>> System for Cross-domain Identity Management (SCIM)
>> ----------------------------------------------
>> Status: Proposed Working Group
>>
>> Last updated: 2012-05-29
>>
>> Chair(s): TBD
>>
>> Applications Area Director(s):
>> =C2=A0Pete Resnick <pr= esnick@qualcomm.com>
>> =C2=A0Barry Leiba <b= arryleiba@computer.org>
>>
>> Mailing Lists:
>> =C2=A0General Discussion: scim@ie= tf.org
>> =C2=A0To Subscribe: =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/scim
>> =C2=A0Archive: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.i= etf.org/mail-archive/web/scim/
>>
>> Description of Working Group:
>>
>> The System for Cross-domain Identity Management (SCIM) working gro= up
>> will standardize methods for creating, reading, searching, modifyi= ng,
>> and deleting user identities and identity-related objects across >> administrative domains, with the goal of simplifying common tasks<= br> >> related to user identity management in services and applications.<= br> >>
>> "Standardize" does not necessarily mean that the working= group will
>> develop new technologies. =C2=A0For example, the existing specific= ations
>> for "SCIM 1.0" provide RESTful interfaces on top of HTTP= rather than
>> defining a new application protocol.
>>
>> Today, distributed identity management across administrative domai= ns
>> is complicated by a lack of protocol and schema standardization >> between consumers and producers of identities. =C2=A0This has led = to a
>> number of approaches, including error-prone manual administration = and
>> bulk file uploads, as well as proprietary protocols and mediation<= br> >> devices that must be adapted to each service for each organization= .
>> While there is existing work in the field, it has not been widely<= br> >> adopted for a variety of reasons, including a lack of common artif= acts
>> such as schema, toolsets, and libraries.
>>
>> The SCIM working group will develop the core schema and RESTful >> interfaces to address these problems. =C2=A0Initially, the group w= ill focus
>> on
>> - a schema definition
>> - a set of operations for creation, modification, and deletion of = users
>> - schema discovery
>> - read and search
>> - bulk operations
>> - mapping between the inetOrgPerson LDAP object class (RFC 2798) a= nd
>> =C2=A0the SCIM schema
>>
>> It will follow that by considering extensions for client targeting= of
>> specific SCIM endpoints and SAML binding. =C2=A0The approach will = be
>> extensible.
>>
>> The group will use, as starting points, the following drafts in th= e
>> following ways:
>> =C2=A0 =C2=A0 draft-scim-use-cases-00 as the initial use cases for= SCIM
>> =C2=A0 =C2=A0 draft-scim-core-schema-00 as the schema specificatio= n
>> =C2=A0 =C2=A0 draft-scim-api-00 as the protocol specification
>>
>> These drafts are based on existing specifications, which together = are
>> commonly known as SCIM 1.0. =C2=A0Because there is existing work w= ith
>> existing implementations, some consideration should be given to >> backward compatibility, though getting it right takes priority. = =C2=A0This
>> group will consider the operational experience gathered from the >> existing work, as well as experiences with work done by other bodi= es,
>> including the OASIS Provisioning TC.
>>
>> The use cases document will be a "living document", guid= ing the
>> working group during its development of the standards. =C2=A0The g= roup may
>> take snapshots of that document for Informational publication, to<= br> >> serve as documentation of the motivation for the work in progress<= br> >> and to similarly guide planning and implementation.
>>
>> The group will produce Proposed Standards for a schema, a REST-bas= ed
>> protocol, and a SAML binding, as well as an Informational document=
>> defining an LDAP mapping. In doing so, the group will make the
>> terminology consistent, identify any functional gaps that would be=
>> useful for future work, address internationalization, and provide<= br> >> guidelines and mechanisms for extensibility.
>>
>> In addition, the working group will ensure that the SCIM protocol<= br> >> embodies good security practices. Given both the sensitivity of th= e
>> information being conveyed in SCIM messages and the regulatory
>> requirements regarding the privacy of personally identifiable
>> information, the working group will pay particular attention to is= sues
>> around authorization, authenticity, and privacy.
>>
>> The group considers the following out of scope for this group:
>> =C2=A0 =C2=A0 Defining new authentication schemes
>> =C2=A0 =C2=A0 Defining new policy/authorization schemes
>>
>> Milestones
>>
>> 06/2012 =C2=A0 =C2=A0Initial adoption of SCIM use cases, as a livi= ng document
>> 06/2012 =C2=A0 =C2=A0Initial adoption of SCIM core schema
>> 08/2012 =C2=A0 =C2=A0Initial adoption of SCIM restful interface dr= aft
>> 12/2012 =C2=A0 =C2=A0Snapshot version of SCIM use cases to IESG as= Informational (possibly)
>> 12/2012 =C2=A0 =C2=A0Proposal for client targeting of SCIM endpoin= ts
>> 01/2013 =C2=A0 =C2=A0Initial adoption of SCIM LDAP inetOrgPerson m= apping draft
>> 02/2013 =C2=A0 =C2=A0SCIM core schema to IESG as Proposed Standard=
>> 05/2013 =C2=A0 =C2=A0SCIM restful interface to IESG as Proposed St= andard
>> 06/2013 =C2=A0 =C2=A0SCIM LDAP inetOrgPerson mapping to IESG as In= formational
>> 07/2013 =C2=A0 =C2=A0Initial adoption of SCIM SAML bindings draft<= br> >> 08/2013 =C2=A0 =C2=A0Client targeting of SCIM endpoints to IESG as= Proposed Standard
>> 09/2013 =C2=A0 =C2=A0Snapshot update of SCIM use cases as Informat= ional (possibly)
>> 11/2013 =C2=A0 =C2=A0SCIM SAML bindings to IESG as Proposed Standa= rd
>> 01/2014 =C2=A0 =C2=A0Work completed; discuss re-charter
>>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

--00151747553e9b7ba604c15fe6b4-- From trey.drake@unboundid.com Thu May 31 19:34:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6611E8089 for ; Thu, 31 May 2012 19:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaIWxkDGdX0i for ; Thu, 31 May 2012 19:34:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38CBE11E8072 for ; Thu, 31 May 2012 19:34:34 -0700 (PDT) Received: by yhq56 with SMTP id 56so1435062yhq.31 for ; Thu, 31 May 2012 19:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=bFUgAGZ5hQTx/jMOYzqmVwrfK40dmPbv+hBphQxQnlQ=; b=IezbdVkRIX0kelnFH6kJGQgoaYkCk+FD0dbMyWb96gZKUCGj2/iYIt53tiJcA506dm Uud7ym0xEjCOFijh0VE4GAJmZv9c/6VFUH4xR8YTbwgzks4WlUDE4LxJIAwGCm30NNzl 2AbjxftxMamC5tU5pHiU9ElWkeuwkxIw3/mElVyWxjnI4lArwiBTJ/kT/zfILZu1hWDu /TaFT9S2ou27jbx1UdyDpCmdShg9aNGAAuuyckkylAOWKt8xBKkQw55XGeydL1O22F9x rwreseGAJLoMsrhw1zK90cZRBOrmAhtdnkkYfSb4e/bkb5thT5fO5DPdBuowaQ4MMJ19 YfCQ== Received: by 10.236.191.131 with SMTP id g3mr954085yhn.59.1338518073783; Thu, 31 May 2012 19:34:33 -0700 (PDT) Received: from [192.168.5.198] (ip-64-134-188-79.public.wayport.net. [64.134.188.79]) by mx.google.com with ESMTPS id l49sm1929419yhj.8.2012.05.31.19.34.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 19:34:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D8B05D07-5F91-4A06-A805-AD05D3271F66" From: Trey Drake In-Reply-To: Date: Thu, 31 May 2012 21:34:29 -0500 Message-Id: References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> To: Daniel Park X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnI5StVSnSuDscqy6E1qAJFl2SIfkBpXuxdtzrCFu32UdUa4dAd0TQN7NHanpO3JYiVt2fB Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:34:35 -0000 --Apple-Mail=_D8B05D07-5F91-4A06-A805-AD05D3271F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Daniel, We don't have a use case draft under IETF yet. I left out Phil's = targeting draft (apologies Phil). Its at = http://tools.ietf.org/html/draft-hunt-scim-targeting-00 Thanks, Trey On May 31, 2012, at 9:25 PM, Daniel Park wrote: > Thanks Trey for the prompt reply. > What about use-case draft? Isn't it an official draft yet? >=20 > Soohong Daniel Park from my Galaxy Note >=20 > 2012. 6. 1. =EC=98=A4=EC=A0=84 11:21=EC=97=90 "Trey Drake" = =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Hi Daniel. >=20 > The drafts are posted @ >=20 > API: https://datatracker.ietf.org/doc/draft-scim-api/ > Schema: https://datatracker.ietf.org/doc/draft-scim-core-schema/ >=20 > Thanks, > Trey >=20 >=20 > On May 31, 2012, at 9:12 PM, Daniel Park wrote: >=20 > > Sorry for asking, but I am very interested in this work and trying = to > > catch up the related drafts quickly. However, I didn't find out them > > listed in the charter. Is it already published ? or just candidate > > items to be written down later on ? > > If available, please let kindly me know the live links for them. > > > >> draft-scim-use-cases-00 as the initial use cases for SCIM > >> draft-scim-core-schema-00 as the schema specification > > > > > > Thanks in advance, Daniel > > > > -- > > Soohong Daniel Park > > Samsung Electronics, SWC > > > > On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary = wrote: > >> A new IETF working group has been proposed in the Applications > >> Area. The IESG has not made any determination as yet. The = following > >> draft charter was submitted, and is provided for informational = purposes > >> only. Please send your comments to the IESG mailing list = (iesg@ietf.org) > >> by June 7, 2012. > >> > >> System for Cross-domain Identity Management (SCIM) > >> ---------------------------------------------- > >> Status: Proposed Working Group > >> > >> Last updated: 2012-05-29 > >> > >> Chair(s): TBD > >> > >> Applications Area Director(s): > >> Pete Resnick > >> Barry Leiba > >> > >> Mailing Lists: > >> General Discussion: scim@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/scim > >> Archive: http://www.ietf.org/mail-archive/web/scim/ > >> > >> Description of Working Group: > >> > >> The System for Cross-domain Identity Management (SCIM) working = group > >> will standardize methods for creating, reading, searching, = modifying, > >> and deleting user identities and identity-related objects across > >> administrative domains, with the goal of simplifying common tasks > >> related to user identity management in services and applications. > >> > >> "Standardize" does not necessarily mean that the working group will > >> develop new technologies. For example, the existing specifications > >> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather = than > >> defining a new application protocol. > >> > >> Today, distributed identity management across administrative = domains > >> is complicated by a lack of protocol and schema standardization > >> between consumers and producers of identities. This has led to a > >> number of approaches, including error-prone manual administration = and > >> bulk file uploads, as well as proprietary protocols and mediation > >> devices that must be adapted to each service for each organization. > >> While there is existing work in the field, it has not been widely > >> adopted for a variety of reasons, including a lack of common = artifacts > >> such as schema, toolsets, and libraries. > >> > >> The SCIM working group will develop the core schema and RESTful > >> interfaces to address these problems. Initially, the group will = focus > >> on > >> - a schema definition > >> - a set of operations for creation, modification, and deletion of = users > >> - schema discovery > >> - read and search > >> - bulk operations > >> - mapping between the inetOrgPerson LDAP object class (RFC 2798) = and > >> the SCIM schema > >> > >> It will follow that by considering extensions for client targeting = of > >> specific SCIM endpoints and SAML binding. The approach will be > >> extensible. > >> > >> The group will use, as starting points, the following drafts in the > >> following ways: > >> draft-scim-use-cases-00 as the initial use cases for SCIM > >> draft-scim-core-schema-00 as the schema specification > >> draft-scim-api-00 as the protocol specification > >> > >> These drafts are based on existing specifications, which together = are > >> commonly known as SCIM 1.0. Because there is existing work with > >> existing implementations, some consideration should be given to > >> backward compatibility, though getting it right takes priority. = This > >> group will consider the operational experience gathered from the > >> existing work, as well as experiences with work done by other = bodies, > >> including the OASIS Provisioning TC. > >> > >> The use cases document will be a "living document", guiding the > >> working group during its development of the standards. The group = may > >> take snapshots of that document for Informational publication, to > >> serve as documentation of the motivation for the work in progress > >> and to similarly guide planning and implementation. > >> > >> The group will produce Proposed Standards for a schema, a = REST-based > >> protocol, and a SAML binding, as well as an Informational document > >> defining an LDAP mapping. In doing so, the group will make the > >> terminology consistent, identify any functional gaps that would be > >> useful for future work, address internationalization, and provide > >> guidelines and mechanisms for extensibility. > >> > >> In addition, the working group will ensure that the SCIM protocol > >> embodies good security practices. Given both the sensitivity of the > >> information being conveyed in SCIM messages and the regulatory > >> requirements regarding the privacy of personally identifiable > >> information, the working group will pay particular attention to = issues > >> around authorization, authenticity, and privacy. > >> > >> The group considers the following out of scope for this group: > >> Defining new authentication schemes > >> Defining new policy/authorization schemes > >> > >> Milestones > >> > >> 06/2012 Initial adoption of SCIM use cases, as a living document > >> 06/2012 Initial adoption of SCIM core schema > >> 08/2012 Initial adoption of SCIM restful interface draft > >> 12/2012 Snapshot version of SCIM use cases to IESG as = Informational (possibly) > >> 12/2012 Proposal for client targeting of SCIM endpoints > >> 01/2013 Initial adoption of SCIM LDAP inetOrgPerson mapping = draft > >> 02/2013 SCIM core schema to IESG as Proposed Standard > >> 05/2013 SCIM restful interface to IESG as Proposed Standard > >> 06/2013 SCIM LDAP inetOrgPerson mapping to IESG as Informational > >> 07/2013 Initial adoption of SCIM SAML bindings draft > >> 08/2013 Client targeting of SCIM endpoints to IESG as Proposed = Standard > >> 09/2013 Snapshot update of SCIM use cases as Informational = (possibly) > >> 11/2013 SCIM SAML bindings to IESG as Proposed Standard > >> 01/2014 Work completed; discuss re-charter > >> > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail=_D8B05D07-5F91-4A06-A805-AD05D3271F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 http://to= ols.ietf.org/html/draft-hunt-scim-targeting-00

Than= ks,
Trey

On May 31, 2012, at 9:25 PM, Daniel = Park wrote:

Thanks Trey for the prompt reply.
What about use-case draft? Isn't it an official draft yet?

Soohong = Daniel Park from my Galaxy Note

2012. 6. 1. =EC=98=A4=EC=A0=84 11:21=EC=97=90 = "Trey Drake" <trey.drake@unboundid.com>=EB= =8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Hi Daniel.

The drafts are posted @

API: https://datatracker.ietf.org/doc/draft-scim-api/
= Schema: https://datatracker.ietf.org/doc/draft-scim-core-schema/=

Thanks,
Trey


On May 31, 2012, at 9:12 PM, Daniel Park wrote:

> Sorry for asking, but I am very interested in this work and trying = to
> catch up the related drafts quickly. However, I didn't find out = them
> listed in the charter. Is it already published ? or just = candidate
> items to be written down later on ?
> If available, please let kindly me know the live links for = them.
>
>> draft-scim-use-cases-00 as the initial use cases for SCIM
>> draft-scim-core-schema-00 as the schema specification
>
>
> Thanks in advance, Daniel
>
> --
> Soohong Daniel Park
> Samsung Electronics, SWC
>
> On Fri, Jun 1, 2012 at 12:08 AM, IESG Secretary <iesg-secretary@ietf.org> = wrote:
>> A new IETF working group has been proposed in the = Applications
>> Area.  The IESG has not made any determination as yet. The = following
>> draft charter was submitted, and is provided for informational = purposes
>> only. Please send your comments to the IESG mailing list (iesg@ietf.org)
>> by June 7, 2012.
>>
>> System for Cross-domain Identity Management (SCIM)
>> ----------------------------------------------
>> Status: Proposed Working Group
>>
>> Last updated: 2012-05-29
>>
>> Chair(s): TBD
>>
>> Applications Area Director(s):
>>  Pete Resnick <presnick@qualcomm.com>
>>  Barry Leiba <barryleiba@computer.org> >>
>> Mailing Lists:
>>  General Discussion: scim@ietf.org
>>  To Subscribe:       https://www.ietf.org/mailman/listinfo/scim
>>  Archive:            http://www.ietf.org/mail-archive/web/scim/
>>
>> Description of Working Group:
>>
>> The System for Cross-domain Identity Management (SCIM) working = group
>> will standardize methods for creating, reading, searching, = modifying,
>> and deleting user identities and identity-related objects = across
>> administrative domains, with the goal of simplifying common = tasks
>> related to user identity management in services and = applications.
>>
>> "Standardize" does not necessarily mean that the working group = will
>> develop new technologies.  For example, the existing = specifications
>> for "SCIM 1.0" provide RESTful interfaces on top of HTTP rather = than
>> defining a new application protocol.
>>
>> Today, distributed identity management across administrative = domains
>> is complicated by a lack of protocol and schema = standardization
>> between consumers and producers of identities.  This has = led to a
>> number of approaches, including error-prone manual = administration and
>> bulk file uploads, as well as proprietary protocols and = mediation
>> devices that must be adapted to each service for each = organization.
>> While there is existing work in the field, it has not been = widely
>> adopted for a variety of reasons, including a lack of common = artifacts
>> such as schema, toolsets, and libraries.
>>
>> The SCIM working group will develop the core schema and = RESTful
>> interfaces to address these problems.  Initially, the = group will focus
>> on
>> - a schema definition
>> - a set of operations for creation, modification, and deletion = of users
>> - schema discovery
>> - read and search
>> - bulk operations
>> - mapping between the inetOrgPerson LDAP object class (RFC = 2798) and
>>  the SCIM schema
>>
>> It will follow that by considering extensions for client = targeting of
>> specific SCIM endpoints and SAML binding.  The approach = will be
>> extensible.
>>
>> The group will use, as starting points, the following drafts in = the
>> following ways:
>>     draft-scim-use-cases-00 as the initial use cases = for SCIM
>>     draft-scim-core-schema-00 as the schema = specification
>>     draft-scim-api-00 as the protocol = specification
>>
>> These drafts are based on existing specifications, which = together are
>> commonly known as SCIM 1.0.  Because there is existing = work with
>> existing implementations, some consideration should be given = to
>> backward compatibility, though getting it right takes priority. =  This
>> group will consider the operational experience gathered from = the
>> existing work, as well as experiences with work done by other = bodies,
>> including the OASIS Provisioning TC.
>>
>> The use cases document will be a "living document", guiding = the
>> working group during its development of the standards. =  The group may
>> take snapshots of that document for Informational publication, = to
>> serve as documentation of the motivation for the work in = progress
>> and to similarly guide planning and implementation.
>>
>> The group will produce Proposed Standards for a schema, a = REST-based
>> protocol, and a SAML binding, as well as an Informational = document
>> defining an LDAP mapping. In doing so, the group will make = the
>> terminology consistent, identify any functional gaps that would = be
>> useful for future work, address internationalization, and = provide
>> guidelines and mechanisms for extensibility.
>>
>> In addition, the working group will ensure that the SCIM = protocol
>> embodies good security practices. Given both the sensitivity of = the
>> information being conveyed in SCIM messages and the = regulatory
>> requirements regarding the privacy of personally = identifiable
>> information, the working group will pay particular attention to = issues
>> around authorization, authenticity, and privacy.
>>
>> The group considers the following out of scope for this = group:
>>     Defining new authentication schemes
>>     Defining new policy/authorization schemes
>>
>> Milestones
>>
>> 06/2012    Initial adoption of SCIM use cases, as a = living document
>> 06/2012    Initial adoption of SCIM core schema
>> 08/2012    Initial adoption of SCIM restful interface = draft
>> 12/2012    Snapshot version of SCIM use cases to IESG = as Informational (possibly)
>> 12/2012    Proposal for client targeting of SCIM = endpoints
>> 01/2013    Initial adoption of SCIM LDAP = inetOrgPerson mapping draft
>> 02/2013    SCIM core schema to IESG as Proposed = Standard
>> 05/2013    SCIM restful interface to IESG as Proposed = Standard
>> 06/2013    SCIM LDAP inetOrgPerson mapping to IESG as = Informational
>> 07/2013    Initial adoption of SCIM SAML bindings = draft
>> 08/2013    Client targeting of SCIM endpoints to IESG = as Proposed Standard
>> 09/2013    Snapshot update of SCIM use cases as = Informational (possibly)
>> 11/2013    SCIM SAML bindings to IESG as Proposed = Standard
>> 01/2014    Work completed; discuss re-charter
>>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


= --Apple-Mail=_D8B05D07-5F91-4A06-A805-AD05D3271F66-- From melinda.shore@gmail.com Thu May 31 20:22:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD411E80F2 for ; Thu, 31 May 2012 20:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBs2MW9wzwdX for ; Thu, 31 May 2012 20:22:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2930811E8072 for ; Thu, 31 May 2012 20:22:39 -0700 (PDT) Received: by dacx6 with SMTP id x6so2138518dac.31 for ; Thu, 31 May 2012 20:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=miUyDrvK53CSouTXDup9xQnE8xLpTFl+qupIopGcZV8=; b=s0zphp4Rd3sLE4KJ0tNU+UWQDf/O+hI+o0Bb/g5YonBZWjBzgsBPbAt2fAe/GKWbEg odLvOQ6YoVLkpD4Gvc7aQswJ93Ph46fiCAhV/srUJlrDNFD5MNuyZI5HZXHc0n3XED+V f1+XmqHdOOQKqxORilD8wYviVeXtagtj+pn6IsUBduKGmvSBkGgZd2mgGm0hVg9jgTDo LMZG0x3YOyeG+O+cSFMtYFJ8hS/EdqfEfi+/fusyjYBq/cCQk2au6GhE4zCMJEGmFJM2 zRscB9yXL/0L0EybG9QEoMWBkkxO9gFzgIhEok275qMuYb4d6SBnfp/AP+GekHyuDWgE M9UQ== Received: by 10.68.130.197 with SMTP id og5mr5836857pbb.56.1338520958827; Thu, 31 May 2012 20:22:38 -0700 (PDT) Received: from spandex.local (66-230-85-178-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.85.178]) by mx.google.com with ESMTPS id qm6sm1209817pbc.10.2012.05.31.20.22.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 20:22:38 -0700 (PDT) Message-ID: <4FC8357B.7030404@gmail.com> Date: Thu, 31 May 2012 19:22:35 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 03:22:39 -0000 On 5/31/12 6:25 PM, Daniel Park wrote: > Thanks Trey for the prompt reply. > What about use-case draft? Isn't it an official draft yet? Inasmuch as the working group hasn't been chartered yet, it has no working group drafts. Melinda From stpeter@stpeter.im Thu May 31 20:31:25 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5E11E80F3 for ; Thu, 31 May 2012 20:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxoA77UcJwRk for ; Thu, 31 May 2012 20:31:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8011E8072 for ; Thu, 31 May 2012 20:31:23 -0700 (PDT) Received: from [192.168.0.7] (unknown [216.17.179.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9473C4005A; Thu, 31 May 2012 21:47:55 -0600 (MDT) Message-ID: <4FC8378A.6000907@stpeter.im> Date: Thu, 31 May 2012 21:31:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melinda Shore References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FC8357B.7030404@gmail.com> In-Reply-To: <4FC8357B.7030404@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 03:31:25 -0000 On 5/31/12 9:22 PM, Melinda Shore wrote: > On 5/31/12 6:25 PM, Daniel Park wrote: >> Thanks Trey for the prompt reply. >> What about use-case draft? Isn't it an official draft yet? > > Inasmuch as the working group hasn't been chartered yet, it has > no working group drafts. It sounds like Daniel Park might want to read "The Tao of the IETF": http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ Peter -- Peter Saint-Andre https://stpeter.im/ From trey.drake@unboundid.com Thu May 31 20:34:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2B21F8453 for ; Thu, 31 May 2012 20:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eljTUprOuOX for ; Thu, 31 May 2012 20:33:59 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFB21F8452 for ; Thu, 31 May 2012 20:33:59 -0700 (PDT) Received: by yhq56 with SMTP id 56so1461108yhq.31 for ; Thu, 31 May 2012 20:33:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=tYcy06HqAMYkcSg2cw9BSPZI4uMdlHPA/Uc6xyWL1jc=; b=E9HxVh+OOJJ92m5zmGjBInxB7PwTAeLZ6fvmTSIwK94lF2yCXam5UjXUqbQRpfEMry esuZX1hcWw+Lkj4MNQ7lMADq2PIX9OZ9zt7W8aqwPtKUgxQBu/x4cV9fYMFJr1X1u4WG 58PqShzbNUE7Iuo4Swv0vV9Cmo2C3qBFCYYNpSDNHM+prlGDBGKYdBdYjfWCJ3YfK+ts AWs3oh5bgD4BiTYAw+nvRTBD9EGfCjEHqNf9ojPIvtND3cJ7GRh9xL6voqqK5pvHLucz QtrS9ivaoT63Lu/0LpimWiV8MREu5PpmMSen8WcUKDeNql2ODE9lwuwjcRH7V11j8cMt 5+Mw== Received: by 10.236.115.196 with SMTP id e44mr1066992yhh.90.1338521638798; Thu, 31 May 2012 20:33:58 -0700 (PDT) Received: from [107.16.2.246] ([107.16.2.246]) by mx.google.com with ESMTPS id l49sm2361440yhj.8.2012.05.31.20.33.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 20:33:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Trey Drake In-Reply-To: <4FC8357B.7030404@gmail.com> Date: Thu, 31 May 2012 23:33:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <628562CD-107A-4198-8A1A-F276730500BF@unboundid.com> References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FC8357B.7030404@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkqkqWiw9SmZdga8fhL/gcL4Qh4KCQYhS3H0f6tw/u7ztDOdKuK499AWe0StJwXnTyhgkRm Cc: scim@ietf.org Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 03:34:00 -0000 Daniel asked for the drafts related to the charter. For obvious reasons, = I'm not claiming the drafts are endorsed by the non-existant working = group. The drafts I sent are specifically referenced in the charter. =20= Thanks, Trey =20 On May 31, 2012, at 11:22 PM, Melinda Shore wrote: > On 5/31/12 6:25 PM, Daniel Park wrote: >> Thanks Trey for the prompt reply. >> What about use-case draft? Isn't it an official draft yet? >=20 > Inasmuch as the working group hasn't been chartered yet, it has > no working group drafts. >=20 > Melinda >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From soohongp@gmail.com Thu May 31 20:52:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34311E8072 for ; Thu, 31 May 2012 20:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgGTLZjC1jkE for ; Thu, 31 May 2012 20:52:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47E9611E8086 for ; Thu, 31 May 2012 20:52:57 -0700 (PDT) Received: by bkty8 with SMTP id y8so1648175bkt.31 for ; Thu, 31 May 2012 20:52:56 -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=Lc+fkmvl4hOPf+YhRwFih8MaMeLv1Uv0upO3l9AvhkI=; b=n+2orNg44sEuJUFmf2DqsGIysnqZVR+9086FHJqUE5Q3FPte9+LhPBaheP14IxwFOg 5X7bH+lbTLBYD6FYTtVe6dIBEb3wphU7f+iQz3yP/MQdby6bz5X7lLvnOSkNXVP3sZ6k T9mB3MaH132W8dDmCAf00lrfpXxasaz5SoqLUw/d+468uRm/f6S2B9/ZSl5FMGK5ia44 +IaxVIQDl7FMwxjEldkgvkmiX7qXC+vpeXnaeAPCDwT0fs7yqItzIsj0I3y17/pOzPg+ 9M0Kt9mnqRLw6RgN9++b/z3bZ1TqotGmZ41prfg+hpG4G98tgvphLbyvbrIFSYNamKJs ymMA== MIME-Version: 1.0 Received: by 10.205.119.12 with SMTP id fs12mr502280bkc.49.1338522776183; Thu, 31 May 2012 20:52:56 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Thu, 31 May 2012 20:52:56 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Thu, 31 May 2012 20:52:56 -0700 (PDT) In-Reply-To: <628562CD-107A-4198-8A1A-F276730500BF@unboundid.com> References: <20120531150837.7422.10288.idtracker@ietfa.amsl.com> <4FC8357B.7030404@gmail.com> <628562CD-107A-4198-8A1A-F276730500BF@unboundid.com> Date: Fri, 1 Jun 2012 12:52:56 +0900 Message-ID: From: Daniel Park To: Trey Drake Content-Type: multipart/alternative; boundary=000e0ce0464e9925a104c1611edd Cc: scim@ietf.org, Melinda Shore Subject: Re: [scim] WG Review: System for Cross-domain Identity Management (SCIM) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 03:52:58 -0000 --000e0ce0464e9925a104c1611edd Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Sorry for making the noise. I just wanted to go through the relevant drafts before reviewing the charter specifically. By the way thanks a lot. Daniel. Soohong Daniel Park from my Galaxy Note 2012. 6. 1. =BF=C0=C8=C4 12:34=BF=A1 "Trey Drake" =B4=D4=C0=CC =C0=DB=BC=BA: > Daniel asked for the drafts related to the charter. For obvious reasons, > I'm not claiming the drafts are endorsed by the non-existant working grou= p. > The drafts I sent are specifically referenced in the charter. > > Thanks, > Trey > > > On May 31, 2012, at 11:22 PM, Melinda Shore wrote: > > > On 5/31/12 6:25 PM, Daniel Park wrote: > >> Thanks Trey for the prompt reply. > >> What about use-case draft? Isn't it an official draft yet? > > > > Inasmuch as the working group hasn't been chartered yet, it has > > no working group drafts. > > > > Melinda > > > > _______________________________________________ > > 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 > --000e0ce0464e9925a104c1611edd Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

Sorry for making the noise. I just wanted to go through the relevant dra= fts before reviewing the charter specifically.

By the way thanks a lot.

Daniel.

Soohong Daniel Park from my Galaxy Note

2012. 6. 1. =BF=C0=C8=C4 12:34=BF=A1 "Trey = Drake" <trey.drake@unbo= undid.com>=B4=D4=C0=CC =C0=DB=BC=BA:
Daniel asked for the drafts related to the charter. For obvious reasons, I&= #39;m not claiming the drafts are endorsed by the non-existant working grou= p.  The drafts I sent are specifically referenced in the charter.

Thanks,
Trey


On May 31, 2012, at 11:22 PM, Melinda Shore wrote:

> On 5/31/12 6:25 PM, Daniel Park wrote:
>> Thanks Trey for the prompt reply.
>> What about use-case draft? Isn't it an official draft yet?
>
> Inasmuch as the working group hasn't been chartered yet, it has > no working group drafts.
>
> Melinda
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

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