From prvs=744093763A=erik.wahlstrom@nexussafe.com Tue Apr 3 10:24: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 D107F11E8072 for ; Tue, 3 Apr 2012 10:24:32 -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 OwZcTpOHYolT for ; Tue, 3 Apr 2012 10:24:32 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9211321F864D for ; Tue, 3 Apr 2012 10:24:31 -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, 3 Apr 2012 19:24:24 +0200 Received: from MARVMAILDB.technxs.com ([fe80::93a:970c:f043:1455]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 19:24:26 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: "scim@ietf.org" Thread-Topic: [scim] Scope change request Thread-Index: AQHNDaMOk+6CPg4Z6EWpQw9ikaNU4JaJQG6A Date: Tue, 3 Apr 2012 17:24:26 +0000 Message-ID: <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> In-Reply-To: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.95] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A6BD67402D581448B2456C4B64DF6A2@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 03 Apr 2012 17:24:32 -0000 Hi, I truly believe that the Consumer shall have no knowledge of the complexity= that's behind a Service Provider. Once a SCIM Resource is created at a ser= vice provider, the consumer will loose control over the resource. The servi= ce provider can choose to store the resource within a sql-database, nosql-d= atabase, a file system, a directory or to sent it to one or more down strea= ms scim service providers. It's the same logic as you do not know if a sql = server is replicated or not while calling it. This considered, isn't a reverse proxy a viable solution that would resolve= the targeting requirement? A reverse proxy is good at targeting specific r= esources and you get the added features of logging, authorization and in so= me cases authentication. Targeting have a couple of other challenges that we run into while developi= ng the ScimProxy, a open source implementation that tries to solve this spe= cific problem, but in a more transparent way. For example, the problem that= 's solved with accountRefs in the targeting proposal. It's good that it's t= here in some way because it must be handled by someone but isn't it enough = that it's handled by the service provider and not by the consumer? See it a= s the magic of the somewhat special service provider (hub) hence leaving it= out of the core schema. If using versioning, the Consumer need to have one or many provisioning str= ategies for different targets. If a target has changed one of it's resource= s and hence it's version the consumer will get a conflict if making a PUT/P= ATCH/DELETE. The consumer must decide if it should fail the request, get la= test version from the service provider and try a merge it with the current = change, and if many targets is targeted possible rollback already changed r= esources. This is something that should be handled by a specialized service= provider, not by the consumer. Authentication is another thing. Should the hub keep track on the authentic= ation methods and creds to the different targets or should the client do th= at and send it to the server. Targets using JSON or XML is another one. Targeting opens up to many questions and a good reverse proxy or some hub-l= ike scim implementations solves the problem without adding this complexity = to the core schema making SCIM harder to implement. I would "hum" no for ad= ding it to the charter at this moment. It's great work though and I learned a lot reading the proposal. Nice work = implementing everything as extensions. Best Regards Erik Wahlstr=F6m On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: > I would like to request that the Targeting proposal presented today at th= e BoF be added to the charter for consideration. >=20 > A draft proposal has been submitted (new this week --> draft-hunt-scim-ta= rgeting) which shows how targeting could be done. >=20 > A brief summary: When provisioning to a service provider that has multip= le applications that may be provisioned, there are 3 alternatives: >=20 > 1. Use schema extensions to objects (e.g. entitlements) to infer app req= uests > 2. Use separate domains and implement app specific endpoints (or combine= d multi-homed service) > 3. Use targeting for a RESTful explicit approach. >=20 > Item 1 IMHO leads to complexity and future inter-op problems. Instead it= is better to keep SCIM requests simple and app-specific. >=20 > As far as 2 and 3 goes, the proposal difference is: >=20 > app-tennantid.scim.cloud.com/Users/xxxxxx > vs. > scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >=20 > The first one requires many more certificates to be issued and leads to c= omplexity for things like proxies and load-balancers. Putting the app targ= et in the path is going to be logistically much easier to manage. It also m= eans the semantics of the transaction are simplified because the operation = is now focused on a specific application target. >=20 > I submitted the draft only to get the ball rolling and am very open to ot= her ideas. I do however feel that this requirement is a deliverable that th= e IETF SCIM WG should address in the first round of specifications. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Apr 3 10:51: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 C206221F8546 for ; Tue, 3 Apr 2012 10:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.903 X-Spam-Level: X-Spam-Status: No, score=-8.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0w9dRa5ZPNEQ for ; Tue, 3 Apr 2012 10:51:34 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 779D321F850D for ; Tue, 3 Apr 2012 10:51:27 -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 q33HpPqi029998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 17:51:26 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q33HpOIb012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 17:51:25 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q33HpOkL031583; Tue, 3 Apr 2012 12:51:24 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Apr 2012 10:51:24 -0700 References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> In-Reply-To: <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Tue, 3 Apr 2012 10:51:42 -0700 To: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4F7B389E.0087,ss=1,re=0.000,fgs=0 Cc: "scim@ietf.org" Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 03 Apr 2012 17:51:36 -0000 Erik, I agree. I'm not saying the client has specific knowledge-quite the opposite= . In current practice i am told deployers use a single complex endpoint where t= he client must know a lot about site specific schema extensions and all the a= pp services behind that scim SP. For example the client must know about how t= he SP models entitlements. The is a somewhat directory centric view.=20 In target mode a single operation is more narrowly defined in a logical way a= nd is therefore simpler. Add xyz to crm is simpler than add xyz with extensi= ons abc to directory.=20 By routing all operations through a single SP the targeted ops can still be m= apped, if desired, to a single common directory entry as before, but the cli= ents perspective is simple and the sp architecure is flexible and can be fir= ewalled. =20 Regards Phil On 2012-04-03, at 10:24, Erik Wahlstr=C3=B6m w= rote: > Hi, >=20 > I truly believe that the Consumer shall have no knowledge of the complexit= y that's behind a Service Provider. Once a SCIM Resource is created at a ser= vice provider, the consumer will loose control over the resource. The servic= e provider can choose to store the resource within a sql-database, nosql-dat= abase, a file system, a directory or to sent it to one or more down streams s= cim service providers. It's the same logic as you do not know if a sql serve= r is replicated or not while calling it. >=20 > This considered, isn't a reverse proxy a viable solution that would resolv= e the targeting requirement? A reverse proxy is good at targeting specific r= esources and you get the added features of logging, authorization and in som= e cases authentication. >=20 > Targeting have a couple of other challenges that we run into while develop= ing the ScimProxy, a open source implementation that tries to solve this spe= cific problem, but in a more transparent way. For example, the problem that'= s solved with accountRefs in the targeting proposal. It's good that it's the= re in some way because it must be handled by someone but isn't it enough tha= t it's handled by the service provider and not by the consumer? See it as th= e magic of the somewhat special service provider (hub) hence leaving it out o= f the core schema. >=20 > If using versioning, the Consumer need to have one or many provisioning st= rategies for different targets. If a target has changed one of it's resource= s and hence it's version the consumer will get a conflict if making a PUT/PA= TCH/DELETE. The consumer must decide if it should fail the request, get late= st version from the service provider and try a merge it with the current cha= nge, and if many targets is targeted possible rollback already changed resou= rces. This is something that should be handled by a specialized service prov= ider, not by the consumer. >=20 > Authentication is another thing. Should the hub keep track on the authenti= cation methods and creds to the different targets or should the client do th= at and send it to the server. Targets using JSON or XML is another one. >=20 > Targeting opens up to many questions and a good reverse proxy or some hub-= like scim implementations solves the problem without adding this complexity t= o the core schema making SCIM harder to implement. I would "hum" no for addi= ng it to the charter at this moment. >=20 > It's great work though and I learned a lot reading the proposal. Nice work= implementing everything as extensions. >=20 > Best Regards > Erik Wahlstr=C3=B6m >=20 >=20 > On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >=20 >> I would like to request that the Targeting proposal presented today at th= e BoF be added to the charter for consideration. >>=20 >> A draft proposal has been submitted (new this week --> draft-hunt-scim-ta= rgeting) which shows how targeting could be done. >>=20 >> A brief summary: When provisioning to a service provider that has multip= le applications that may be provisioned, there are 3 alternatives: >>=20 >> 1. Use schema extensions to objects (e.g. entitlements) to infer app req= uests >> 2. Use separate domains and implement app specific endpoints (or combine= d multi-homed service) >> 3. Use targeting for a RESTful explicit approach. >>=20 >> Item 1 IMHO leads to complexity and future inter-op problems. Instead it= is better to keep SCIM requests simple and app-specific. >>=20 >> As far as 2 and 3 goes, the proposal difference is: >>=20 >> app-tennantid.scim.cloud.com/Users/xxxxxx >> vs. >> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>=20 >> The first one requires many more certificates to be issued and leads to c= omplexity for things like proxies and load-balancers. Putting the app targe= t in the path is going to be logistically much easier to manage. It also mea= ns the semantics of the transaction are simplified because the operation is n= ow focused on a specific application target. >>=20 >> I submitted the draft only to get the ball rolling and am very open to ot= her ideas. I do however feel that this requirement is a deliverable that the= IETF SCIM WG should address in the first round of specifications. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From prvs=144035544D=erik.wahlstrom@nexussafe.com Tue Apr 3 13:18:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3111E81D2 for ; Tue, 3 Apr 2012 13:18:07 -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 Fxz9kdEHxRhp for ; Tue, 3 Apr 2012 13:18:06 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id BE64311E81C3 for ; Tue, 3 Apr 2012 13:18:05 -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, 3 Apr 2012 22:18:00 +0200 Received: from MARVMAILDB.technxs.com ([fe80::93a:970c:f043:1455]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 22:18:03 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: "scim@ietf.org" Thread-Topic: [scim] Scope change request Thread-Index: AQHNDaMOk+6CPg4Z6EWpQw9ikaNU4JaJQG6AgAAHnwCAACjhgA== Date: Tue, 3 Apr 2012 20:18:03 +0000 Message-ID: References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> In-Reply-To: <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.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: <5E646F50246B38469B13C0B03DE396C2@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 03 Apr 2012 20:18:07 -0000 Hi Phil, Another approach would be to use the schema discovery end point by the cons= umer. The service provider can compile all data needed (and potentially any= extensions that's needed) into one scim resource that the consumer sends a= nd the service provider distribute it to all down steams servers. The servi= ce providers schema can be discovered using the schema end point and is com= piled from all the attributes needed by using the schemas from all downstre= am servers. That means that the service provider can keep hiding the comple= xity. If there is a need for many extension I guess a couple of missing attribute= s should be added to the core schema. The service provider can also define = a good format for it's entitlements attribute to support all down stream se= rvers. Best Regards Erik Wahlstr=F6m On Apr 3, 2012, at 7:51 PM, Phil Hunt wrote: > Erik, >=20 > I agree. I'm not saying the client has specific knowledge-quite the oppos= ite. >=20 > In current practice i am told deployers use a single complex endpoint whe= re the client must know a lot about site specific schema extensions and all= the app services behind that scim SP. For example the client must know abo= ut how the SP models entitlements. The is a somewhat directory centric vie= w.=20 >=20 > In target mode a single operation is more narrowly defined in a logical w= ay and is therefore simpler. Add xyz to crm is simpler than add xyz with ex= tensions abc to directory.=20 >=20 > By routing all operations through a single SP the targeted ops can still = be mapped, if desired, to a single common directory entry as before, but th= e clients perspective is simple and the sp architecure is flexible and can = be firewalled. =20 >=20 > Regards >=20 > Phil >=20 > On 2012-04-03, at 10:24, Erik Wahlstr=F6m = wrote: >=20 >> Hi, >>=20 >> I truly believe that the Consumer shall have no knowledge of the complex= ity that's behind a Service Provider. Once a SCIM Resource is created at a = service provider, the consumer will loose control over the resource. The se= rvice provider can choose to store the resource within a sql-database, nosq= l-database, a file system, a directory or to sent it to one or more down st= reams scim service providers. It's the same logic as you do not know if a s= ql server is replicated or not while calling it. >>=20 >> This considered, isn't a reverse proxy a viable solution that would reso= lve the targeting requirement? A reverse proxy is good at targeting specifi= c resources and you get the added features of logging, authorization and in= some cases authentication. >>=20 >> Targeting have a couple of other challenges that we run into while devel= oping the ScimProxy, a open source implementation that tries to solve this = specific problem, but in a more transparent way. For example, the problem t= hat's solved with accountRefs in the targeting proposal. It's good that it'= s there in some way because it must be handled by someone but isn't it enou= gh that it's handled by the service provider and not by the consumer? See i= t as the magic of the somewhat special service provider (hub) hence leaving= it out of the core schema. >>=20 >> If using versioning, the Consumer need to have one or many provisioning = strategies for different targets. If a target has changed one of it's resou= rces and hence it's version the consumer will get a conflict if making a PU= T/PATCH/DELETE. The consumer must decide if it should fail the request, get= latest version from the service provider and try a merge it with the curre= nt change, and if many targets is targeted possible rollback already change= d resources. This is something that should be handled by a specialized serv= ice provider, not by the consumer. >>=20 >> Authentication is another thing. Should the hub keep track on the authen= tication methods and creds to the different targets or should the client do= that and send it to the server. Targets using JSON or XML is another one. >>=20 >> Targeting opens up to many questions and a good reverse proxy or some hu= b-like scim implementations solves the problem without adding this complexi= ty to the core schema making SCIM harder to implement. I would "hum" no for= adding it to the charter at this moment. >>=20 >> It's great work though and I learned a lot reading the proposal. Nice wo= rk implementing everything as extensions. >>=20 >> Best Regards >> Erik Wahlstr=F6m >>=20 >>=20 >> On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >>=20 >>> I would like to request that the Targeting proposal presented today at = the BoF be added to the charter for consideration. >>>=20 >>> A draft proposal has been submitted (new this week --> draft-hunt-scim-= targeting) which shows how targeting could be done. >>>=20 >>> A brief summary: When provisioning to a service provider that has mult= iple applications that may be provisioned, there are 3 alternatives: >>>=20 >>> 1. Use schema extensions to objects (e.g. entitlements) to infer app r= equests >>> 2. Use separate domains and implement app specific endpoints (or combi= ned multi-homed service) >>> 3. Use targeting for a RESTful explicit approach. >>>=20 >>> Item 1 IMHO leads to complexity and future inter-op problems. Instead = it is better to keep SCIM requests simple and app-specific. >>>=20 >>> As far as 2 and 3 goes, the proposal difference is: >>>=20 >>> app-tennantid.scim.cloud.com/Users/xxxxxx >>> vs. >>> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>>=20 >>> The first one requires many more certificates to be issued and leads to= complexity for things like proxies and load-balancers. Putting the app ta= rget in the path is going to be logistically much easier to manage. It also= means the semantics of the transaction are simplified because the operatio= n is now focused on a specific application target. >>>=20 >>> I submitted the draft only to get the ball rolling and am very open to = other ideas. I do however feel that this requirement is a deliverable that = the IETF SCIM WG should address in the first round of specifications. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Apr 3 14: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 90B5D11E80B6 for ; Tue, 3 Apr 2012 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 fcme0Qq+z4qi for ; Tue, 3 Apr 2012 14:03:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF8911E809D for ; Tue, 3 Apr 2012 14:03:22 -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 q33L3KOS019726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 21:03:21 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 q33L3Ju0018025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 21:03:19 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q33L3IKP014998; Tue, 3 Apr 2012 16:03:18 -0500 Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Apr 2012 14:03:18 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: Date: Tue, 3 Apr 2012 14:03:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090209.4F7B6599.0066,ss=1,re=0.000,fgs=0 Cc: "scim@ietf.org" Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 03 Apr 2012 21:03:23 -0000 Ok. If I work on your premise, we would have a single user object that = is a conglomeration of accounts in many services. In LDAP this often = becomes unwieldy and is often broken into several entities. The inter-op = issue comes in the form that different sites will do this very = differently. In SCIM what happens when a User object is broken apart? Consider when each service being provisioned has the possibility for = Users to hold multiple accounts. E-mail is one example that shows up in = the new SCIM schema and where there is a complex attribute showing = primary account etc. But what of other application scenarios where it is = reasonable for users to have one or more accounts? Hypothetically, = consider AOL where I may have one or more email, AIM, or FlickR = accounts. This gets awfully complex quickly trying to show an = amalgamated entity. What if instead the hub view showed that the hub Person was related to = one ore more accounts in each system.? Thus each Flickr account in = Flickr is a simple User object from the SCIM perspective. But, via the = hypothetical AOL Hub there is a clear relationship between the User = object there and the 2 or 3 FlickR accounts. Likewise, Google has many different services where users may have many = Calendar, Doc, or Blogspot accounts. This model of single end-point is too simplistic IMHO and likely to = quickly go insanely complicated. Trey and I talked about some ways to do this without an explicit Targets = object just using a path before the SCIM endpoints (e.g. = scim.cloud.com/crm/tenant/Users/xxxxx). But I think this would require = modification of the core specification to allow this. I'm neutral as = long as inter-operability is not complicated. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-03, at 1:18 PM, Erik Wahlstr=F6m wrote: > Hi Phil, >=20 > Another approach would be to use the schema discovery end point by the = consumer. The service provider can compile all data needed (and = potentially any extensions that's needed) into one scim resource that = the consumer sends and the service provider distribute it to all down = steams servers. The service providers schema can be discovered using the = schema end point and is compiled from all the attributes needed by using = the schemas from all downstream servers. That means that the service = provider can keep hiding the complexity. >=20 > If there is a need for many extension I guess a couple of missing = attributes should be added to the core schema. The service provider can = also define a good format for it's entitlements attribute to support all = down stream servers. >=20 > Best Regards > Erik Wahlstr=F6m >=20 >=20 > On Apr 3, 2012, at 7:51 PM, Phil Hunt wrote: >=20 >> Erik, >>=20 >> I agree. I'm not saying the client has specific knowledge-quite the = opposite. >>=20 >> In current practice i am told deployers use a single complex endpoint = where the client must know a lot about site specific schema extensions = and all the app services behind that scim SP. For example the client = must know about how the SP models entitlements. The is a somewhat = directory centric view.=20 >>=20 >> In target mode a single operation is more narrowly defined in a = logical way and is therefore simpler. Add xyz to crm is simpler than add = xyz with extensions abc to directory.=20 >>=20 >> By routing all operations through a single SP the targeted ops can = still be mapped, if desired, to a single common directory entry as = before, but the clients perspective is simple and the sp architecure is = flexible and can be firewalled. =20 >>=20 >> Regards >>=20 >> Phil >>=20 >> On 2012-04-03, at 10:24, Erik Wahlstr=F6m = wrote: >>=20 >>> Hi, >>>=20 >>> I truly believe that the Consumer shall have no knowledge of the = complexity that's behind a Service Provider. Once a SCIM Resource is = created at a service provider, the consumer will loose control over the = resource. The service provider can choose to store the resource within a = sql-database, nosql-database, a file system, a directory or to sent it = to one or more down streams scim service providers. It's the same logic = as you do not know if a sql server is replicated or not while calling = it. >>>=20 >>> This considered, isn't a reverse proxy a viable solution that would = resolve the targeting requirement? A reverse proxy is good at targeting = specific resources and you get the added features of logging, = authorization and in some cases authentication. >>>=20 >>> Targeting have a couple of other challenges that we run into while = developing the ScimProxy, a open source implementation that tries to = solve this specific problem, but in a more transparent way. For example, = the problem that's solved with accountRefs in the targeting proposal. = It's good that it's there in some way because it must be handled by = someone but isn't it enough that it's handled by the service provider = and not by the consumer? See it as the magic of the somewhat special = service provider (hub) hence leaving it out of the core schema. >>>=20 >>> If using versioning, the Consumer need to have one or many = provisioning strategies for different targets. If a target has changed = one of it's resources and hence it's version the consumer will get a = conflict if making a PUT/PATCH/DELETE. The consumer must decide if it = should fail the request, get latest version from the service provider = and try a merge it with the current change, and if many targets is = targeted possible rollback already changed resources. This is something = that should be handled by a specialized service provider, not by the = consumer. >>>=20 >>> Authentication is another thing. Should the hub keep track on the = authentication methods and creds to the different targets or should the = client do that and send it to the server. Targets using JSON or XML is = another one. >>>=20 >>> Targeting opens up to many questions and a good reverse proxy or = some hub-like scim implementations solves the problem without adding = this complexity to the core schema making SCIM harder to implement. I = would "hum" no for adding it to the charter at this moment. >>>=20 >>> It's great work though and I learned a lot reading the proposal. = Nice work implementing everything as extensions. >>>=20 >>> Best Regards >>> Erik Wahlstr=F6m >>>=20 >>>=20 >>> On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >>>=20 >>>> I would like to request that the Targeting proposal presented today = at the BoF be added to the charter for consideration. >>>>=20 >>>> A draft proposal has been submitted (new this week --> = draft-hunt-scim-targeting) which shows how targeting could be done. >>>>=20 >>>> A brief summary: When provisioning to a service provider that has = multiple applications that may be provisioned, there are 3 alternatives: >>>>=20 >>>> 1. Use schema extensions to objects (e.g. entitlements) to infer = app requests >>>> 2. Use separate domains and implement app specific endpoints (or = combined multi-homed service) >>>> 3. Use targeting for a RESTful explicit approach. >>>>=20 >>>> Item 1 IMHO leads to complexity and future inter-op problems. = Instead it is better to keep SCIM requests simple and app-specific. >>>>=20 >>>> As far as 2 and 3 goes, the proposal difference is: >>>>=20 >>>> app-tennantid.scim.cloud.com/Users/xxxxxx >>>> vs. >>>> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>>>=20 >>>> The first one requires many more certificates to be issued and = leads to complexity for things like proxies and load-balancers. Putting = the app target in the path is going to be logistically much easier to = manage. It also means the semantics of the transaction are simplified = because the operation is now focused on a specific application target. >>>>=20 >>>> I submitted the draft only to get the ball rolling and am very open = to other ideas. I do however feel that this requirement is a deliverable = that the IETF SCIM WG should address in the first round of = specifications. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> 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 vumip1@gmail.com Tue Apr 3 19:38:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEADC21F856C; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.773, 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 dBQWpDA-oaDb; Tue, 3 Apr 2012 19:38:11 -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 37C8F21F8568; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so587840obb.31 for ; Tue, 03 Apr 2012 19:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6uEBZ9heJkgKZQdg8XGDIyAo9fY484LtFO+LXwB22SQ=; b=Cu4yBE1GGi/5dcs1VLoLR22aNE1Qv2js3jXoSf9I07NQruwi+Z5VDOnV7xMNmtzIRj p3aSWAOnoCMGNcxLsfUiAZKLNvXuxhUPsnfD+IXO8LumZTY0Y1e5OXVSKvH5ENEWMWo8 fJt7R9LWMqjON1LB7iiqM3amHfO7ATkUH/pMXd4kFPlS/sqi5Wh+G8OSgyJVvFYtaMGf INnv4b+RNORrsXVPdXXnlMskUpl+uAxnynFbC/dRLiQj9N5+zpx+6wHtEdp1eOrccVtJ 87z4OAskACWmZXcjQ1XwzQKtnTrdfhJVPVlBuFjUT6KR5LX9UUE8xz1OW3m5lWlTWnM4 3WpA== MIME-Version: 1.0 Received: by 10.182.188.38 with SMTP id fx6mr22118610obc.77.1333507090880; Tue, 03 Apr 2012 19:38:10 -0700 (PDT) Received: by 10.182.171.104 with HTTP; Tue, 3 Apr 2012 19:38:10 -0700 (PDT) Date: Tue, 3 Apr 2012 22:38:10 -0400 Message-ID: From: Bhumip Khasnabish To: opsawg@ietf.org, apps-discuss@ietf.org, dc@ietf.org, cdni@ietf.org, scim@ietf.org, dcrg-interest@irtf.org Content-Type: multipart/alternative; boundary=f46d04478bdd7518e904bcd150de Subject: [scim] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 04 Apr 2012 02:38:12 -0000 --f46d04478bdd7518e904bcd150de Content-Type: text/plain; charset=ISO-8859-1 The slides from IETF83 Cloud Storage Talk by Giorgio are now available at the following Website: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds File names are as follows: IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part1.pdf and IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part2.pdf --f46d04478bdd7518e904bcd150de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The slides from IETF83 Cloud Storage Talk by Giorgio are now available a= t the following Website:
http://trac.tools.ietf.org/area/app/tra= c/wiki/Clouds

File names are as follows:
=A0
IETF83-Cloud-Storage-Talk-Giorgio-2= 9Mar2012-part1.pdf
and
IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-= part2.pdf
=A0
=A0
=A0

--f46d04478bdd7518e904bcd150de-- From kelly.grizzle@sailpoint.com Wed Apr 4 06:57: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 AA23D21F86B6 for ; Wed, 4 Apr 2012 06:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ZTfPo23q1ZwG for ; Wed, 4 Apr 2012 06:57:35 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8A21F86B3 for ; Wed, 4 Apr 2012 06:57:34 -0700 (PDT) Received: from mail81-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 4 Apr 2012 13:57:33 +0000 Received: from mail81-db3 (localhost [127.0.0.1]) by mail81-db3-R.bigfish.com (Postfix) with ESMTP id 614543E0173; Wed, 4 Apr 2012 13:57:33 +0000 (UTC) X-SpamScore: -38 X-BigFish: PS-38(zz9371Ic89bh936eK542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail81-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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail81-db3 (localhost.localdomain [127.0.0.1]) by mail81-db3 (MessageSwitch) id 1333547851464105_20508; Wed, 4 Apr 2012 13:57:31 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.242]) by mail81-db3.bigfish.com (Postfix) with ESMTP id 6AC3A34004B; Wed, 4 Apr 2012 13:57:31 +0000 (UTC) Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 4 Apr 2012 13:57:30 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.2.194]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0135.002; Wed, 4 Apr 2012 13:57:23 +0000 From: Kelly Grizzle To: Phil Hunt , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] Scope change request Thread-Index: AQHNDaMPvZMshp36J0iiGuzZvi3ez5aJYfYAgAAHngCAACjkgIAADKIAgAEVgkA= Date: Wed, 4 Apr 2012 13:57:22 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C662997@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> In-Reply-To: <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 04 Apr 2012 13:57:36 -0000 I agree with Phil. Lots of meta-directory software has been developed to t= ry to give the single directory-centric view of a user. If the service pro= vider is sophisticated enough (and the data model simple enough), it is pos= sible to give a single view of a user that can encompass data from other ac= counts. As Phil mentions, this can fall apart very quickly for a variety o= f reasons (multiple accounts, data transformations, desire to see specific = account-level attributes). In these cases, it is much easier for the clien= t to have a more direct view and explicit control over the targets. I see a lot of value in targeting and would like to see it added to the cha= rter as an extension to be worked on in parallel with the other core work. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Tuesday, April 03, 2012 4:03 PM To: Erik Wahlstr=F6m Cc: scim@ietf.org Subject: Re: [scim] Scope change request Ok. If I work on your premise, we would have a single user object that is a= conglomeration of accounts in many services. In LDAP this often becomes u= nwieldy and is often broken into several entities. The inter-op issue comes= in the form that different sites will do this very differently. In SCIM wh= at happens when a User object is broken apart? Consider when each service being provisioned has the possibility for Users = to hold multiple accounts. E-mail is one example that shows up in the new = SCIM schema and where there is a complex attribute showing primary account = etc. But what of other application scenarios where it is reasonable for use= rs to have one or more accounts? Hypothetically, consider AOL where I may = have one or more email, AIM, or FlickR accounts. This gets awfully complex = quickly trying to show an amalgamated entity. What if instead the hub view showed that the hub Person was related to one = ore more accounts in each system.? Thus each Flickr account in Flickr is a = simple User object from the SCIM perspective. But, via the hypothetical AOL= Hub there is a clear relationship between the User object there and the 2 = or 3 FlickR accounts. Likewise, Google has many different services where users may have many Cale= ndar, Doc, or Blogspot accounts. This model of single end-point is too simplistic IMHO and likely to quickly= go insanely complicated. Trey and I talked about some ways to do this without an explicit Targets ob= ject just using a path before the SCIM endpoints (e.g. scim.cloud.com/crm/t= enant/Users/xxxxx). But I think this would require modification of the core= specification to allow this. I'm neutral as long as inter-operability is n= ot complicated. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-03, at 1:18 PM, Erik Wahlstr=F6m wrote: > Hi Phil, >=20 > Another approach would be to use the schema discovery end point by the co= nsumer. The service provider can compile all data needed (and potentially a= ny extensions that's needed) into one scim resource that the consumer sends= and the service provider distribute it to all down steams servers. The ser= vice providers schema can be discovered using the schema end point and is c= ompiled from all the attributes needed by using the schemas from all downst= ream servers. That means that the service provider can keep hiding the comp= lexity. >=20 > If there is a need for many extension I guess a couple of missing attribu= tes should be added to the core schema. The service provider can also defin= e a good format for it's entitlements attribute to support all down stream = servers. >=20 > Best Regards > Erik Wahlstr=F6m >=20 >=20 > On Apr 3, 2012, at 7:51 PM, Phil Hunt wrote: >=20 >> Erik, >>=20 >> I agree. I'm not saying the client has specific knowledge-quite the oppo= site. >>=20 >> In current practice i am told deployers use a single complex endpoint wh= ere the client must know a lot about site specific schema extensions and al= l the app services behind that scim SP. For example the client must know ab= out how the SP models entitlements. The is a somewhat directory centric vi= ew.=20 >>=20 >> In target mode a single operation is more narrowly defined in a logical = way and is therefore simpler. Add xyz to crm is simpler than add xyz with e= xtensions abc to directory.=20 >>=20 >> By routing all operations through a single SP the targeted ops can still= be mapped, if desired, to a single common directory entry as before, but t= he clients perspective is simple and the sp architecure is flexible and can= be firewalled. =20 >>=20 >> Regards >>=20 >> Phil >>=20 >> On 2012-04-03, at 10:24, Erik Wahlstr=F6m = wrote: >>=20 >>> Hi, >>>=20 >>> I truly believe that the Consumer shall have no knowledge of the comple= xity that's behind a Service Provider. Once a SCIM Resource is created at a= service provider, the consumer will loose control over the resource. The s= ervice provider can choose to store the resource within a sql-database, nos= ql-database, a file system, a directory or to sent it to one or more down s= treams scim service providers. It's the same logic as you do not know if a = sql server is replicated or not while calling it. >>>=20 >>> This considered, isn't a reverse proxy a viable solution that would res= olve the targeting requirement? A reverse proxy is good at targeting specif= ic resources and you get the added features of logging, authorization and i= n some cases authentication. >>>=20 >>> Targeting have a couple of other challenges that we run into while deve= loping the ScimProxy, a open source implementation that tries to solve this= specific problem, but in a more transparent way. For example, the problem = that's solved with accountRefs in the targeting proposal. It's good that it= 's there in some way because it must be handled by someone but isn't it eno= ugh that it's handled by the service provider and not by the consumer? See = it as the magic of the somewhat special service provider (hub) hence leavin= g it out of the core schema. >>>=20 >>> If using versioning, the Consumer need to have one or many provisioning= strategies for different targets. If a target has changed one of it's reso= urces and hence it's version the consumer will get a conflict if making a P= UT/PATCH/DELETE. The consumer must decide if it should fail the request, ge= t latest version from the service provider and try a merge it with the curr= ent change, and if many targets is targeted possible rollback already chang= ed resources. This is something that should be handled by a specialized ser= vice provider, not by the consumer. >>>=20 >>> Authentication is another thing. Should the hub keep track on the authe= ntication methods and creds to the different targets or should the client d= o that and send it to the server. Targets using JSON or XML is another one. >>>=20 >>> Targeting opens up to many questions and a good reverse proxy or some h= ub-like scim implementations solves the problem without adding this complex= ity to the core schema making SCIM harder to implement. I would "hum" no fo= r adding it to the charter at this moment. >>>=20 >>> It's great work though and I learned a lot reading the proposal. Nice w= ork implementing everything as extensions. >>>=20 >>> Best Regards >>> Erik Wahlstr=F6m >>>=20 >>>=20 >>> On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >>>=20 >>>> I would like to request that the Targeting proposal presented today at= the BoF be added to the charter for consideration. >>>>=20 >>>> A draft proposal has been submitted (new this week --> draft-hunt-scim= -targeting) which shows how targeting could be done. >>>>=20 >>>> A brief summary: When provisioning to a service provider that has mul= tiple applications that may be provisioned, there are 3 alternatives: >>>>=20 >>>> 1. Use schema extensions to objects (e.g. entitlements) to infer=20 >>>> app requests 2. Use separate domains and implement app specific=20 >>>> endpoints (or combined multi-homed service) 3. Use targeting for a RE= STful explicit approach. >>>>=20 >>>> Item 1 IMHO leads to complexity and future inter-op problems. Instead= it is better to keep SCIM requests simple and app-specific. >>>>=20 >>>> As far as 2 and 3 goes, the proposal difference is: >>>>=20 >>>> app-tennantid.scim.cloud.com/Users/xxxxxx >>>> vs. >>>> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>>>=20 >>>> The first one requires many more certificates to be issued and leads t= o complexity for things like proxies and load-balancers. Putting the app t= arget in the path is going to be logistically much easier to manage. It als= o means the semantics of the transaction are simplified because the operati= on is now focused on a specific application target. >>>>=20 >>>> I submitted the draft only to get the ball rolling and am very open to= other ideas. I do however feel that this requirement is a deliverable that= the IETF SCIM WG should address in the first round of specifications. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> 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 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From trey.drake@unboundid.com Wed Apr 4 07:17:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7578721F85A7 for ; Wed, 4 Apr 2012 07:17:49 -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 H55nBrnkMWln for ; Wed, 4 Apr 2012 07:17: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 3D0D321F859A for ; Wed, 4 Apr 2012 07:17:48 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so470765obb.31 for ; Wed, 04 Apr 2012 07:17:47 -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=EswCLvU5/4qv99Ymrzpry1h0ZqaWIUOHH3leiGgW+hM=; b=nXvmEB7Z/0SbB8mAwyeBAtKXbSrW2gfYtP+RT+E/AyHnzsD8BZ1qtzpRBQdE2CIsQr bIofg6xVIx/f7HUqR0Svcz7OytZAqZsMWTsdwfLw1p+Nsv8vPTGvHyPDNpfmGB2sWWno OtA2Vty8C/m95QkTKtqdG3L5M0mNaHCB913PODbyvy2OKNngDUIsE7V6SD1E+qdU6VNY IlHz08AsZ+r+dWFXZUsvna6/1UAuLbq9jnsnhe6aK7zUdsebBK7qA50Dfm/rzjsjui+l 8CSwwWOgY8S1VMEsOOJU5repej2nM+4onW9tZoZBXHT0d+CBOW/APDYX4OpZOF6agOsv 0uUg== Received: by 10.182.136.41 with SMTP id px9mr25109839obb.21.1333549067885; Wed, 04 Apr 2012 07:17:47 -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 b6sm665429obe.12.2012.04.04.07.17.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 07:17:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_DE498034-7A3F-421B-9BC7-A995560871F5"; protocol="application/pkcs7-signature"; micalg=sha1 From: Trey Drake In-Reply-To: <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> Date: Wed, 4 Apr 2012 09:17:45 -0500 Message-Id: References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlAdOxFOraGu4uMF+Psw2EDPNHt7kRwzL6udPBeBEQ+NjqdxXSoSA+Ufpxo0PEWWK73Dgje Cc: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "scim@ietf.org" Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 04 Apr 2012 14:17:49 -0000 --Apple-Mail=_DE498034-7A3F-421B-9BC7-A995560871F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 3, 2012, at 4:03 PM, Phil Hunt wrote: > Ok. If I work on your premise, we would have a single user object that = is a conglomeration of accounts in many services. In LDAP this often = becomes unwieldy and is often broken into several entities. The inter-op = issue comes in the form that different sites will do this very = differently. In SCIM what happens when a User object is broken apart? >=20 > Consider when each service being provisioned has the possibility for = Users to hold multiple accounts. E-mail is one example that shows up in = the new SCIM schema and where there is a complex attribute showing = primary account etc. But what of other application scenarios where it is = reasonable for users to have one or more accounts? Hypothetically, = consider AOL where I may have one or more email, AIM, or FlickR = accounts. This gets awfully complex quickly trying to show an = amalgamated entity. >=20 > What if instead the hub view showed that the hub Person was related to = one ore more accounts in each system.? Thus each Flickr account in = Flickr is a simple User object from the SCIM perspective. But, via the = hypothetical AOL Hub there is a clear relationship between the User = object there and the 2 or 3 FlickR accounts. >=20 > Likewise, Google has many different services where users may have many = Calendar, Doc, or Blogspot accounts. >=20 > This model of single end-point is too simplistic IMHO and likely to = quickly go insanely complicated. >=20 > Trey and I talked about some ways to do this without an explicit = Targets object just using a path before the SCIM endpoints (e.g. = scim.cloud.com/crm/tenant/Users/xxxxx). But I think this would require = modification of the core specification to allow this. I'm neutral as = long as inter-operability is not complicated. >=20 Hi Phil, What are your thoughts on formalizing the spec to accommodate targeting = via the URL scheme we discussed? In my view, this can be handled as an = operational/deployment decision vs something that must be formalized = into the spec. For example, supporting a multi-tenant deployment is = shared by the majority of current contributors though we haven't yet = prescribed the mechanics as some will want to work it out via the bound = client (the authenticated principal), aspects of the url and/or = attribute extension. =20 Its worth noting that different tenants in a SCIM deployment could = expose different schema and that's perfectly legit behavior in the = current draft; e.g., https://example.com/tenant1/Schemas and = https://example.com/tenant2/Schemas are for all practical purposes = separate backends. In the same fashion an addressable 'target' aka = 'app' could be expressed in this fashion w/o changing the current draft; = e.g., https://example.com/crm/tenant1/Schemas and = https://example.com/email/tenant1/Schemas Given my understanding, the ugly in targeting is the need to provide a = different resource schema for each target; e.g., 'User' attributes in = the email target will be different than those of the crm target . If an = answer to targeting is to prefix the URL path to accommodate the target = then we don't have to change the spec since the client (via = configuration of some sort) will need to be smart enough to work out the = targets it needs to address. Conceptually this feels similar to = multi-tenant handling. If the client is expected to be 'dumb' (has no = idea what targets it needs to address) a discovery mechanism will need = to be introduced in the protocol. is this an accurate assessment (the = crux is what to do about schema)? Thanks, Trey > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-03, at 1:18 PM, Erik Wahlstr=F6m wrote: >=20 >> Hi Phil, >>=20 >> Another approach would be to use the schema discovery end point by = the consumer. The service provider can compile all data needed (and = potentially any extensions that's needed) into one scim resource that = the consumer sends and the service provider distribute it to all down = steams servers. The service providers schema can be discovered using the = schema end point and is compiled from all the attributes needed by using = the schemas from all downstream servers. That means that the service = provider can keep hiding the complexity. >>=20 >> If there is a need for many extension I guess a couple of missing = attributes should be added to the core schema. The service provider can = also define a good format for it's entitlements attribute to support all = down stream servers. >>=20 >> Best Regards >> Erik Wahlstr=F6m >>=20 >>=20 >> On Apr 3, 2012, at 7:51 PM, Phil Hunt wrote: >>=20 >>> Erik, >>>=20 >>> I agree. I'm not saying the client has specific knowledge-quite the = opposite. >>>=20 >>> In current practice i am told deployers use a single complex = endpoint where the client must know a lot about site specific schema = extensions and all the app services behind that scim SP. For example the = client must know about how the SP models entitlements. The is a = somewhat directory centric view.=20 >>>=20 >>> In target mode a single operation is more narrowly defined in a = logical way and is therefore simpler. Add xyz to crm is simpler than add = xyz with extensions abc to directory.=20 >>>=20 >>> By routing all operations through a single SP the targeted ops can = still be mapped, if desired, to a single common directory entry as = before, but the clients perspective is simple and the sp architecure is = flexible and can be firewalled. =20 >>>=20 >>> Regards >>>=20 >>> Phil >>>=20 >>> On 2012-04-03, at 10:24, Erik Wahlstr=F6m = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I truly believe that the Consumer shall have no knowledge of the = complexity that's behind a Service Provider. Once a SCIM Resource is = created at a service provider, the consumer will loose control over the = resource. The service provider can choose to store the resource within a = sql-database, nosql-database, a file system, a directory or to sent it = to one or more down streams scim service providers. It's the same logic = as you do not know if a sql server is replicated or not while calling = it. >>>>=20 >>>> This considered, isn't a reverse proxy a viable solution that would = resolve the targeting requirement? A reverse proxy is good at targeting = specific resources and you get the added features of logging, = authorization and in some cases authentication. >>>>=20 >>>> Targeting have a couple of other challenges that we run into while = developing the ScimProxy, a open source implementation that tries to = solve this specific problem, but in a more transparent way. For example, = the problem that's solved with accountRefs in the targeting proposal. = It's good that it's there in some way because it must be handled by = someone but isn't it enough that it's handled by the service provider = and not by the consumer? See it as the magic of the somewhat special = service provider (hub) hence leaving it out of the core schema. >>>>=20 >>>> If using versioning, the Consumer need to have one or many = provisioning strategies for different targets. If a target has changed = one of it's resources and hence it's version the consumer will get a = conflict if making a PUT/PATCH/DELETE. The consumer must decide if it = should fail the request, get latest version from the service provider = and try a merge it with the current change, and if many targets is = targeted possible rollback already changed resources. This is something = that should be handled by a specialized service provider, not by the = consumer. >>>>=20 >>>> Authentication is another thing. Should the hub keep track on the = authentication methods and creds to the different targets or should the = client do that and send it to the server. Targets using JSON or XML is = another one. >>>>=20 >>>> Targeting opens up to many questions and a good reverse proxy or = some hub-like scim implementations solves the problem without adding = this complexity to the core schema making SCIM harder to implement. I = would "hum" no for adding it to the charter at this moment. >>>>=20 >>>> It's great work though and I learned a lot reading the proposal. = Nice work implementing everything as extensions. >>>>=20 >>>> Best Regards >>>> Erik Wahlstr=F6m >>>>=20 >>>>=20 >>>> On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >>>>=20 >>>>> I would like to request that the Targeting proposal presented = today at the BoF be added to the charter for consideration. >>>>>=20 >>>>> A draft proposal has been submitted (new this week --> = draft-hunt-scim-targeting) which shows how targeting could be done. >>>>>=20 >>>>> A brief summary: When provisioning to a service provider that has = multiple applications that may be provisioned, there are 3 alternatives: >>>>>=20 >>>>> 1. Use schema extensions to objects (e.g. entitlements) to infer = app requests >>>>> 2. Use separate domains and implement app specific endpoints (or = combined multi-homed service) >>>>> 3. Use targeting for a RESTful explicit approach. >>>>>=20 >>>>> Item 1 IMHO leads to complexity and future inter-op problems. = Instead it is better to keep SCIM requests simple and app-specific. >>>>>=20 >>>>> As far as 2 and 3 goes, the proposal difference is: >>>>>=20 >>>>> app-tennantid.scim.cloud.com/Users/xxxxxx >>>>> vs. >>>>> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>>>>=20 >>>>> The first one requires many more certificates to be issued and = leads to complexity for things like proxies and load-balancers. Putting = the app target in the path is going to be logistically much easier to = manage. It also means the semantics of the transaction are simplified = because the operation is now focused on a specific application target. >>>>>=20 >>>>> I submitted the draft only to get the ball rolling and am very = open to other ideas. I do however feel that this requirement is a = deliverable that the IETF SCIM WG should address in the first round of = specifications. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_DE498034-7A3F-421B-9BC7-A995560871F5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM9jCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGujCCBaKg AwIBAgIDAopvMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNTEzMTY1MjQ5WhcNMTIwNTEzMDU0NzU2WjBLMSAwHgYDVQQNExc0MjU3NjEteUxidzRqMkwy Z0FqSG92UzEnMCUGCSqGSIb3DQEJARYYdHJleS5kcmFrZUB1bmJvdW5kaWQuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqid9tc427LEtBahNAplYUQztLpGRwt7J1hxi3mHkMBzr s3LxhGspxGij4JZogkqolFpIhu0amwHXsDv7DbkET1O8TN2S2ttetn2o/gQMhAlXp7MP4SfHnIHL awiDyKZ96l49FFuOt107G9SYpOceuY+AfBssNfxVpTfzqvBzQ/zdbGwqg+ndyPmsWZCYc036/dHV VWDPpLbohj8GmtoNp8p2LjXe4hOvOfxNnlg6hRlHwiPkudSpEaHwW5dlQUjtcBNvowCq2uq2fbQq 5jyswWRGRIQINo4UgSsyDAB5SfagyGMx32EUGrx1NJWOHWK3eqPknuYdgtU2nJZ+aTtBpQIDAQAB o4IDYzCCA18wCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBTFEY17wcVFokE4T9NZv3jxliACzjAfBgNVHSMEGDAWgBRTcu2SnODa ywFcfH6WNU7y1LhRgjAjBgNVHREEHDAagRh0cmV5LmRyYWtlQHVuYm91bmRpZC5jb20wggHRBgNV HSAEggHIMIIBxDCCAcAGCysGAQQBgbU3AQICMIIBrzAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCCAUUGCCsGAQUFBwICMIIBNzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoIBClRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IHBvbGljeSBhbmQgbWF5IGJlIHJlbGllZCB1cG9u IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGFuZCBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLiBMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3Ns LmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNz bC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAfcC87DDCF7sIIY5qIDIS7MmSAJjr GlCfGP11cJrO88bsQiSgtJYYeIATEUsH1r78aJOzU8p8P/lOrSoDr3kxVlUaOam6xIvlW9Uv6AUN DBjYeDUMaEIwPl/Eox0tvZPas4JwW1K+N085ya1IKCK/l7x2K97JQqQhE44ymJ873mcEbBNz6HOo JtyNMc204G0mREpQs4RSb7vsT9x93QUs6QpP/Mn/w+HaXQQzgs4HmfgL8z+qlH4vX4S/rKvwv95m fdCIrdSBAeSKBco9hHTIny9XpkTR2qk1Uq0eqSk1LtufDoQy9c5KKQKINCKrjioMseRufmAY/0Nu VbekcRMyIDGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKKbzAJ BgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x MjA0MDQxNDE3NDZaMCMGCSqGSIb3DQEJBDEWBBQl6+xyY+hgfy6R7eljWOOXDBdbvDCBpQYJKwYB BAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKKbzCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAopvMA0GCSqGSIb3DQEB AQUABIIBAKl38NfsDRbMx/lf55OwCWDmJCr+66hnWtOwOyi876FKST8eU5xn3PBiKRuzlYWB6byi 0T/6LICVbjpw+Tjn9IeLulPjaCOxyNfVdszA7koMMDWjyjyNitwfl0YTiP/QuUeBrSCH16DrQINb uasD4K4/jPogKotjmPMeLYJkPI84FGiH0yvx8ouwwnyjspaI6kf5T3sos5zFKIvH2yDxQQWzr+O1 WksUyxDD8bhQ2owZIEHzRZF/pYrFrkc5aK9txGWDD3wiUrSa6SVKoSKVyllgI00/Xn+UXLCg2Aw7 XY2hnQjxcqFRU3mRRkBuyGX5RdwG0skSq6u89jymjal/jswAAAAAAAA= --Apple-Mail=_DE498034-7A3F-421B-9BC7-A995560871F5-- From phil.hunt@oracle.com Wed Apr 4 08:10: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 7503B21F8827 for ; Wed, 4 Apr 2012 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.402 X-Spam-Level: X-Spam-Status: No, score=-9.402 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 rMN1eW8m5trL for ; Wed, 4 Apr 2012 08:10:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2042C21F8826 for ; Wed, 4 Apr 2012 08:10:16 -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 q34FADau014530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 15:10:14 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 q34FAC5A009553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 15:10:13 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q34FAB1O012955; Wed, 4 Apr 2012 10:10:11 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Apr 2012 08:10:11 -0700 References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <7C0ECA6F-6CCC-4434-8380-3C15970D34CB@oracle.com> X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Wed, 4 Apr 2012 08:10:32 -0700 To: Trey Drake X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090204.4F7C6457.0038,ss=1,re=-2.300,fgs=0 Cc: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= , "scim@ietf.org" Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 04 Apr 2012 15:10:17 -0000 I think it ia possible but then would you not have to formalize the (optiona= l) behavior in the core spec along with AttributeRef schema change? Either way is fine.=20 Would it be better to define a person object that holds the references to us= er accounts in order to keep track of relations in the SP rather then extend= user to point to user via relative URLs? Phil On 2012-04-04, at 7:17, Trey Drake wrote: >=20 > On Apr 3, 2012, at 4:03 PM, Phil Hunt wrote: >=20 >> Ok. If I work on your premise, we would have a single user object that is= a conglomeration of accounts in many services. In LDAP this often becomes u= nwieldy and is often broken into several entities. The inter-op issue comes i= n the form that different sites will do this very differently. In SCIM what h= appens when a User object is broken apart? >>=20 >> Consider when each service being provisioned has the possibility for User= s to hold multiple accounts. E-mail is one example that shows up in the new= SCIM schema and where there is a complex attribute showing primary account e= tc. But what of other application scenarios where it is reasonable for users= to have one or more accounts? Hypothetically, consider AOL where I may hav= e one or more email, AIM, or FlickR accounts. This gets awfully complex quic= kly trying to show an amalgamated entity. >>=20 >> What if instead the hub view showed that the hub Person was related to on= e ore more accounts in each system.? Thus each Flickr account in Flickr is a= simple User object from the SCIM perspective. But, via the hypothetical AOL= Hub there is a clear relationship between the User object there and the 2 o= r 3 FlickR accounts. >>=20 >> Likewise, Google has many different services where users may have many Ca= lendar, Doc, or Blogspot accounts. >>=20 >> This model of single end-point is too simplistic IMHO and likely to quick= ly go insanely complicated. >>=20 >> Trey and I talked about some ways to do this without an explicit Targets o= bject just using a path before the SCIM endpoints (e.g. scim.cloud.com/crm/t= enant/Users/xxxxx). But I think this would require modification of the core s= pecification to allow this. I'm neutral as long as inter-operability is not c= omplicated. >>=20 >=20 > Hi Phil, >=20 > What are your thoughts on formalizing the spec to accommodate targeting vi= a the URL scheme we discussed? In my view, this can be handled as an operat= ional/deployment decision vs something that must be formalized into the spec= . For example, supporting a multi-tenant deployment is shared by the majori= ty of current contributors though we haven't yet prescribed the mechanics as= some will want to work it out via the bound client (the authenticated princ= ipal), aspects of the url and/or attribute extension. =20 >=20 > Its worth noting that different tenants in a SCIM deployment could expose d= ifferent schema and that's perfectly legit behavior in the current draft; e.= g., https://example.com/tenant1/Schemas and https://example.com/tenant2/Sche= mas are for all practical purposes separate backends. In the same fashion a= n addressable 'target' aka 'app' could be expressed in this fashion w/o chan= ging the current draft; e.g., https://example.com/crm/tenant1/Schemas and h= ttps://example.com/email/tenant1/Schemas >=20 > Given my understanding, the ugly in targeting is the need to provide a dif= ferent resource schema for each target; e.g., 'User' attributes in the email= target will be different than those of the crm target . If an answer to ta= rgeting is to prefix the URL path to accommodate the target then we don't ha= ve to change the spec since the client (via configuration of some sort) will= need to be smart enough to work out the targets it needs to address. Conce= ptually this feels similar to multi-tenant handling. If the client is expec= ted to be 'dumb' (has no idea what targets it needs to address) a discovery m= echanism will need to be introduced in the protocol. is this an accurate as= sessment (the crux is what to do about schema)? >=20 > Thanks, > Trey >=20 >=20 >=20 >=20 >=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-04-03, at 1:18 PM, Erik Wahlstr=C3=B6m wrote: >>=20 >>> Hi Phil, >>>=20 >>> Another approach would be to use the schema discovery end point by the c= onsumer. The service provider can compile all data needed (and potentially a= ny extensions that's needed) into one scim resource that the consumer sends a= nd the service provider distribute it to all down steams servers. The servic= e providers schema can be discovered using the schema end point and is compi= led from all the attributes needed by using the schemas from all downstream s= ervers. That means that the service provider can keep hiding the complexity.= >>>=20 >>> If there is a need for many extension I guess a couple of missing attrib= utes should be added to the core schema. The service provider can also defin= e a good format for it's entitlements attribute to support all down stream s= ervers. >>>=20 >>> Best Regards >>> Erik Wahlstr=C3=B6m >>>=20 >>>=20 >>> On Apr 3, 2012, at 7:51 PM, Phil Hunt wrote: >>>=20 >>>> Erik, >>>>=20 >>>> I agree. I'm not saying the client has specific knowledge-quite the opp= osite. >>>>=20 >>>> In current practice i am told deployers use a single complex endpoint w= here the client must know a lot about site specific schema extensions and al= l the app services behind that scim SP. For example the client must know abo= ut how the SP models entitlements. The is a somewhat directory centric view= .=20 >>>>=20 >>>> In target mode a single operation is more narrowly defined in a logical= way and is therefore simpler. Add xyz to crm is simpler than add xyz with e= xtensions abc to directory.=20 >>>>=20 >>>> By routing all operations through a single SP the targeted ops can stil= l be mapped, if desired, to a single common directory entry as before, but t= he clients perspective is simple and the sp architecure is flexible and can b= e firewalled. =20 >>>>=20 >>>> Regards >>>>=20 >>>> Phil >>>>=20 >>>> On 2012-04-03, at 10:24, Erik Wahlstr=C3=B6m wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I truly believe that the Consumer shall have no knowledge of the compl= exity that's behind a Service Provider. Once a SCIM Resource is created at a= service provider, the consumer will loose control over the resource. The se= rvice provider can choose to store the resource within a sql-database, nosql= -database, a file system, a directory or to sent it to one or more down stre= ams scim service providers. It's the same logic as you do not know if a sql s= erver is replicated or not while calling it. >>>>>=20 >>>>> This considered, isn't a reverse proxy a viable solution that would re= solve the targeting requirement? A reverse proxy is good at targeting specif= ic resources and you get the added features of logging, authorization and in= some cases authentication. >>>>>=20 >>>>> Targeting have a couple of other challenges that we run into while dev= eloping the ScimProxy, a open source implementation that tries to solve this= specific problem, but in a more transparent way. For example, the problem t= hat's solved with accountRefs in the targeting proposal. It's good that it's= there in some way because it must be handled by someone but isn't it enough= that it's handled by the service provider and not by the consumer? See it a= s the magic of the somewhat special service provider (hub) hence leaving it o= ut of the core schema. >>>>>=20 >>>>> If using versioning, the Consumer need to have one or many provisionin= g strategies for different targets. If a target has changed one of it's reso= urces and hence it's version the consumer will get a conflict if making a PU= T/PATCH/DELETE. The consumer must decide if it should fail the request, get l= atest version from the service provider and try a merge it with the current c= hange, and if many targets is targeted possible rollback already changed res= ources. This is something that should be handled by a specialized service pr= ovider, not by the consumer. >>>>>=20 >>>>> Authentication is another thing. Should the hub keep track on the auth= entication methods and creds to the different targets or should the client d= o that and send it to the server. Targets using JSON or XML is another one. >>>>>=20 >>>>> Targeting opens up to many questions and a good reverse proxy or some h= ub-like scim implementations solves the problem without adding this complexi= ty to the core schema making SCIM harder to implement. I would "hum" no for a= dding it to the charter at this moment. >>>>>=20 >>>>> It's great work though and I learned a lot reading the proposal. Nice w= ork implementing everything as extensions. >>>>>=20 >>>>> Best Regards >>>>> Erik Wahlstr=C3=B6m >>>>>=20 >>>>>=20 >>>>> On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote: >>>>>=20 >>>>>> I would like to request that the Targeting proposal presented today a= t the BoF be added to the charter for consideration. >>>>>>=20 >>>>>> A draft proposal has been submitted (new this week --> draft-hunt-sci= m-targeting) which shows how targeting could be done. >>>>>>=20 >>>>>> A brief summary: When provisioning to a service provider that has mu= ltiple applications that may be provisioned, there are 3 alternatives: >>>>>>=20 >>>>>> 1. Use schema extensions to objects (e.g. entitlements) to infer app= requests >>>>>> 2. Use separate domains and implement app specific endpoints (or com= bined multi-homed service) >>>>>> 3. Use targeting for a RESTful explicit approach. >>>>>>=20 >>>>>> Item 1 IMHO leads to complexity and future inter-op problems. Instea= d it is better to keep SCIM requests simple and app-specific. >>>>>>=20 >>>>>> As far as 2 and 3 goes, the proposal difference is: >>>>>>=20 >>>>>> app-tennantid.scim.cloud.com/Users/xxxxxx >>>>>> vs. >>>>>> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx >>>>>>=20 >>>>>> The first one requires many more certificates to be issued and leads t= o complexity for things like proxies and load-balancers. Putting the app ta= rget in the path is going to be logistically much easier to manage. It also m= eans the semantics of the transaction are simplified because the operation i= s now focused on a specific application target. >>>>>>=20 >>>>>> I submitted the draft only to get the ball rolling and am very open t= o other ideas. I do however feel that this requirement is a deliverable that= the IETF SCIM WG should address in the first round of specifications. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Wed Apr 4 19:33: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 F063511E80FE for ; Wed, 4 Apr 2012 19:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.53 X-Spam-Level: X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 Hs884KnW+Enr for ; Wed, 4 Apr 2012 19:33:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1911E80EE for ; Wed, 4 Apr 2012 19:33:16 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3C654005B; Wed, 4 Apr 2012 20:46:45 -0600 (MDT) Message-ID: <4F7C5BEA.70006@stpeter.im> Date: Wed, 04 Apr 2012 08:34:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Bhumip Khasnabish References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2012 02:33:17 -0000 [ trimming to scim@ietf.org ] On 4/3/12 8:38 PM, Bhumip Khasnabish wrote: > The slides from IETF83 Cloud Storage Talk by Giorgio are now available > at the following Website: > http://trac.tools.ietf.org/area/app/trac/wiki/Clouds Bhumip, it would be more helpful if you would inform this group about how Giorgio's talk is related to the SCIM work, if at all. Peter -- Peter Saint-Andre https://stpeter.im/ From moransar@cisco.com Wed Apr 4 20:56: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 508ED21F8792 for ; Wed, 4 Apr 2012 20:56: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 KGP08Qzzb-S9 for ; Wed, 4 Apr 2012 20:56:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9084721F8793 for ; Wed, 4 Apr 2012 20:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=1249; q=dns/txt; s=iport; t=1333598168; x=1334807768; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/P7fDP2+AwVb2Z57rUB8Zqdwiw4qM9OczdUTp2BZQ8M=; b=fu84sXn2v/KnHSE6dA3xV2Hi446C/XKcfHnyDkbHkq2SUqZ+IPRc3mPo /ffH8Rtl597WVgCAHsbw76YhEcqqo/AyBQEV7mYrDb/ljt7MI2XQb4xrR dGVu1ErurLfmfy0/IHxo5+G7Y/AamSd/t5kPx3NyE9lfHgZWcxYkxWKfI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJUXfU+tJXG//2dsb2JhbABFuFuBB4IJAQEBAgEBAQEBDwEdCjQLBQcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodnBQubQZ9VixeEVWMEiFmOII05gWmDBYE3 X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="72235239" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 05 Apr 2012 03:55:56 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q353ttTj018629; Thu, 5 Apr 2012 03:55:56 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, 4 Apr 2012 22:55:55 -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, 4 Apr 2012 22:55:54 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE010C4E4D@XMB-RCD-313.cisco.com> In-Reply-To: <4F7C5BEA.70006@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio Thread-Index: Ac0S1Hv3drmQ0QWKR6a3LtwGnJo5AgACzEUA References: <4F7C5BEA.70006@stpeter.im> From: "Morteza Ansari (moransar)" To: "Peter Saint-Andre" , "Bhumip Khasnabish" X-OriginalArrivalTime: 05 Apr 2012 03:55:55.0647 (UTC) FILETIME=[00A610F0:01CD12E0] Cc: scim@ietf.org Subject: Re: [scim] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2012 03:56:09 -0000 I looked at the slides and also the material on the snia.org. There are some very basic aspects of user provisioning that is built into the SNIA apis (http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.1.pdf). Interesting data point, thanks for sharing. Can you also share a bit more about the context of this within IETF and what was the result of the discussion? Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, April 04, 2012 7:34 AM To: Bhumip Khasnabish Cc: scim@ietf.org Subject: Re: [scim] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio [ trimming to scim@ietf.org ] On 4/3/12 8:38 PM, Bhumip Khasnabish wrote: > The slides from IETF83 Cloud Storage Talk by Giorgio are now available > at the following Website: > http://trac.tools.ietf.org/area/app/trac/wiki/Clouds Bhumip, it would be more helpful if you would inform this group about how Giorgio's talk is related to the SCIM work, if at all. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From prvs=844295F52E=erik.wahlstrom@nexussafe.com Thu Apr 5 05:52: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 1139D21F87FC for ; Thu, 5 Apr 2012 05:52:21 -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 XPgKSU7sAaVW for ; Thu, 5 Apr 2012 05:52:20 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id DC61121F87F8 for ; Thu, 5 Apr 2012 05:52:19 -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; Thu, 5 Apr 2012 14:21:55 +0200 Received: from MARVMAILDB.technxs.com ([fe80::93a:970c:f043:1455]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 14:21:57 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Scope change request Thread-Index: AQHNDaMOk+6CPg4Z6EWpQw9ikaNU4JaJQG6AgAAHnwCAACjhgIAADKUAgAEhCICAAA6/AIABYzmA Date: Thu, 5 Apr 2012 12:21:56 +0000 Message-ID: <5A7CEA2D-9A9B-40F4-825F-C135A07541B7@nexussafe.com> References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> <7C0ECA6F-6CCC-4434-8380-3C15970D34CB@oracle.com> In-Reply-To: <7C0ECA6F-6CCC-4434-8380-3C15970D34CB@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.95] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <11FBB9460B1FFC42950E0B1F1315756D@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2012 12:52:21 -0000 On Apr 4, 2012, at 5:10 PM, Phil Hunt wrote: >=20 > Would it be better to define a person object that holds the references to= user accounts in order to keep track of relations in the SP rather then ex= tend user to point to user via relative URLs? If I understand it correctly it sounds like it's very Group-like or it coul= d at least borrow a lot from the Group representation. Instead of a group r= epresenting users within a group it's a group of Users for a specific perso= n. / Erik= From kelly.grizzle@sailpoint.com Thu Apr 5 06:37: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 1316B21F882E for ; Thu, 5 Apr 2012 06:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 f4epp6NYpDWj for ; Thu, 5 Apr 2012 06:37:49 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1515F21F8828 for ; Thu, 5 Apr 2012 06:37:48 -0700 (PDT) Received: from mail9-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 13:37:47 +0000 Received: from mail9-db3 (localhost [127.0.0.1]) by mail9-db3-R.bigfish.com (Postfix) with ESMTP id CCC6E30060C; Thu, 5 Apr 2012 13:37:47 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz9371Ic89bh542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839hd25h) 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 Received-SPF: pass (mail9-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=BL2PRD0410HT003.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3 (MessageSwitch) id 1333633065568221_6848; Thu, 5 Apr 2012 13:37:45 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.250]) by mail9-db3.bigfish.com (Postfix) with ESMTP id 7C0A02200D0; Thu, 5 Apr 2012 13:37:45 +0000 (UTC) Received: from BL2PRD0410HT003.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 13:37:44 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.2.159]) by BL2PRD0410HT003.namprd04.prod.outlook.com ([10.255.99.38]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 13:37:43 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , Phil Hunt Thread-Topic: [scim] Scope change request Thread-Index: AQHNDaMPvZMshp36J0iiGuzZvi3ez5aJYfYAgAAHngCAACjkgIAADKIAgAEhCICAAA6/AIABYzoAgAAQ+WA= Date: Thu, 5 Apr 2012 13:37:42 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C663E56@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> <7C0ECA6F-6CCC-4434-8380-3C15970D34CB@oracle.com> <5A7CEA2D-9A9B-40F4-825F-C135A07541B7@nexussafe.com> In-Reply-To: <5A7CEA2D-9A9B-40F4-825F-C135A07541B7@nexussafe.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2012 13:37:50 -0000 I don't know that we need a different person resource type. Typically, top= -level users and target users will have similar schemas. Top-level users w= ould have the additional account references and target users would potentia= lly have some target-specific schema items (eg - mailboxSize, etc...). Oth= erwise, most of the schema would be shared. Regarding groups, while these are collections of users, the current schema = doc describes them as "enabl[ing] expression of common Group or role based = access control models". Other than this, group is pretty thin, only contai= ning id, externalId, displayName, and members. Using this as a container f= or account references seems semantically incorrect. It is imperative that targeting sticks with the "simple" part of SCIM. To = me, it feels like the current draft proposal of *optionally* adding a Targe= ts resource and a small schema extension for top-level users fits this bill= pretty well. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eri= k Wahlstr=F6m Sent: Thursday, April 05, 2012 7:22 AM To: Phil Hunt Cc: scim@ietf.org; Trey Drake Subject: Re: [scim] Scope change request On Apr 4, 2012, at 5:10 PM, Phil Hunt wrote: >=20 > Would it be better to define a person object that holds the references to= user accounts in order to keep track of relations in the SP rather then ex= tend user to point to user via relative URLs? If I understand it correctly it sounds like it's very Group-like or it coul= d at least borrow a lot from the Group representation. Instead of a group r= epresenting users within a group it's a group of Users for a specific perso= n. / Erik _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From prvs=435ca47a9=Mark.Diodati@gartner.com Thu Apr 5 16:05: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 C450C21F8720 for ; Thu, 5 Apr 2012 16:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ODgGYmGyzwh9 for ; Thu, 5 Apr 2012 16:05:39 -0700 (PDT) Received: from iron-main.gartner.com (iron-main.gartner.com [207.140.148.93]) by ietfa.amsl.com (Postfix) with ESMTP id E0F8921F86E5 for ; Thu, 5 Apr 2012 16:05:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALQkfk8KQCMD/2dsb2JhbABDug6CCQEBAQMBAQEBawQHDAQCAQgRBAEBCwsSBycLFAkIAgQBDQUIiAEQtxYEix2CDYJNYwSIJqBggVw X-IronPort-AV: E=Sophos;i="4.75,378,1330923600"; d="scan'208";a="107231943" From: "Diodati,Mark" To: Kelly Grizzle , Phil Hunt , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] Scope change request Thread-Index: AQHNE15vY2k+wq4lhkSTt5wiJc2j3paM2ezg Date: Thu, 5 Apr 2012 23:05:36 +0000 References: <7C203A08-0F44-4B10-8643-0C2BAF55EC6C@oracle.com> <71975274-E722-46FB-A3C8-33DB8A8A710C@nexussafe.com> <4BC05730-1043-4993-84C0-75FADB9C18FC@oracle.com> <1A2B595E-2FB5-4206-8C3D-E09EEB23948E@oracle.com> <7C0ECA6F-6CCC-4434-8380-3C15970D34CB@oracle.com> <5A7CEA2D-9A9B-40F4-825F-C135A07541B7@nexussafe.com> <56C3C758F9D6534CA3778EAA1E0C34371C663E56@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C663E56@BL2PRD0410MB351.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20120405230538.E0F8921F86E5@ietfa.amsl.com> Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] Scope change request X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2012 23:05:39 -0000 I agree with Kelly. Thanks, Mark -----Original Message----- From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 05, 2012 8:38 AM To: Erik Wahlstr=F6m; Phil Hunt Cc: scim@ietf.org; Trey Drake Subject: Re: [scim] Scope change request I don't know that we need a different person resource type. Typically, top= -level users and target users will have similar schemas. Top-level users w= ould have the additional account references and target users would potentia= lly have some target-specific schema items (eg - mailboxSize, etc...). Oth= erwise, most of the schema would be shared. Regarding groups, while these are collections of users, the current schema = doc describes them as "enabl[ing] expression of common Group or role based = access control models". Other than this, group is pretty thin, only contai= ning id, externalId, displayName, and members. Using this as a container f= or account references seems semantically incorrect. It is imperative that targeting sticks with the "simple" part of SCIM. To = me, it feels like the current draft proposal of *optionally* adding a Targe= ts resource and a small schema extension for top-level users fits this bill= pretty well. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eri= k Wahlstr=F6m Sent: Thursday, April 05, 2012 7:22 AM To: Phil Hunt Cc: scim@ietf.org; Trey Drake Subject: Re: [scim] Scope change request On Apr 4, 2012, at 5:10 PM, Phil Hunt wrote: > > Would it be better to define a person object that holds the references to= user accounts in order to keep track of relations in the SP rather then ex= tend user to point to user via relative URLs? If I understand it correctly it sounds like it's very Group-like or it coul= d at least borrow a lot from the Group representation. Instead of a group r= epresenting users within a group it's a group of Users for a specific perso= n. / Erik _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ________________________________ This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute,= or otherwise use this message or its attachments. Please notify the sender= immediately by return e-mail and permanently delete this message and any a= ttachments. Gartner makes no warranty that this e-mail is error or virus fr= ee. From moransar@cisco.com Mon Apr 9 01:19: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 7605821F8622 for ; Mon, 9 Apr 2012 01:19:12 -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, 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 ie73kkOhUyQx for ; Mon, 9 Apr 2012 01:19:10 -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 6603321F852D for ; Mon, 9 Apr 2012 01:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=4966; q=dns/txt; s=iport; t=1333959550; x=1335169150; h=mime-version:subject:date:message-id:from:to; bh=mmvS1j3KeIL9m5HBzZcuSj+ytKpqptPOBBUN+Ew8LtM=; b=G/UgAs5GV8dDUjIkTaGEGNgQxtxVT3z013FSu4TA0SkWZF1IWxNld7tO 4b6nqpX2HpxWnZyoWBEGL1AWRhi33PalQeSPq9g3uyH7WpypFhqvNQTLZ sE5GTBvfmzOz2Rrr8llb8pl+kcGjlbxbyoyHSfRrkXQMzRjcu3EmB4jyA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEabgk+tJXG8/2dsb2JhbABCglO2bIEHggsBBBIBCREDPh0BKgYYB1cBBAEaDA6HbJ8Jl1CPd2MEiFqbX4FpgwU X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208,217";a="73073997" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 09 Apr 2012 08:19:08 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q398J7sf016764; Mon, 9 Apr 2012 08:19:07 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, 9 Apr 2012 03:19:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1629.6E893943" Date: Mon, 9 Apr 2012 03:19:06 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for ADs: bug fixes to 1.0 spec? Thread-Index: Ac0WIUy/DpNjdjCLSS++ldRwNy27xA== From: "Morteza Ansari (moransar)" To: , "Barry Leiba" , X-OriginalArrivalTime: 09 Apr 2012 08:19:07.0589 (UTC) FILETIME=[6F082F50:01CD1629] Subject: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 09 Apr 2012 08:19:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1629.6E893943 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barry, Pete, =20 A question for you guys as to process and best way to proceed while we are waiting to see if a SCIM WG is formed or not. =20 During the interop testing in Paris we discovered a few bugs in the spec that require clarification and some additions. Should we discuss such issues and resulting changes on the IETF mailing list or continue to work on these very specific 1.0 issues on the old mailing list and weekly calls we had? =20 The work will be very specific to 1.0. On one side it will be helpful to the larger IETF community to also hear about the issues with the current spec and learn about the changes. On other hand it might cause confusion as such changes will need to be done very specific to 1.0 spec and done quickly. And the result will be published as an addendum or revision to the OWF 1.0 spec. Note that regardless of where the discussion takes place, once the changes are complete the document editors will update the current ID's and publish them to have the correct starting point for the WG (assuming we end up creating one). =20 A number of us talked about this and we didn't see a clear answer and figured we reach out to you guys for guidance. =20 =20 Cheers, Morteza=20 ------_=_NextPart_001_01CD1629.6E893943 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barry, = Pete,

 

A question for you guys as to process and best way to = proceed while we are waiting to see if a SCIM WG is formed or = not.

 

During the interop testing in Paris we discovered a = few bugs in the spec that require clarification and some additions. = Should we discuss such issues and resulting changes on the IETF mailing = list or continue to work on these very specific 1.0 issues on the old = mailing list and weekly calls we had?

 

The work = will be very specific to 1.0. On one side it will be helpful to the = larger IETF community to also hear about the issues with the current = spec and learn about the changes. On other hand it might cause confusion = as such changes will need to be done very specific to 1.0 spec and done = quickly. And the result will be published as an addendum or revision to = the OWF 1.0 spec. Note that regardless of where the discussion takes = place, once the changes are complete the document editors will update = the current ID’s and publish them to have the correct starting = point for the WG (assuming we end up creating one).

 

A number of = us talked about this and we didn’t see a clear answer and figured = we reach out to you guys for guidance.

 

 

Cheers,

Morteza =

------_=_NextPart_001_01CD1629.6E893943-- From melinda.shore@gmail.com Mon Apr 9 12:48: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 E9DA921F87DC for ; Mon, 9 Apr 2012 12:48:58 -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 rwRQkspOV35r for ; Mon, 9 Apr 2012 12:48:58 -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 7D1F621F87DE for ; Mon, 9 Apr 2012 12:48:58 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so5007525pbb.31 for ; Mon, 09 Apr 2012 12:48:58 -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=qbl4S40nN9kzNZJUEQ35FlEizpF4I2HH4ABARQgvpko=; b=PeGkP7IhJW10mZXOwGvoF7tFB8EJYs+TrI9gWbW8zHeAU3X9Mv9Kp+NNCylnsdZ7kr luB1SKOYCMu+VAG20QZD/sMeYdSPMsUvDEMg50K+LEPvpAD5wORUlA1wILrZOh7p+5BR kGuxMicvXpwFEbuAv7Gn2mAjR/GuMBKkHkJWTcpHi3pmpASFV7WVgb/ewhaFjbbJJWQK poRLpAyOzziX4bBom6sDa6eGlObo3L1MbLPK2o4nYuvITLoN9IHiIUmrY0MyVwSlyw9B YKcq4rBqbuiNTSh3F/Cv0iDDauZtPBbdJ2mMPFXKMvPmmG6NpMNIXgwTJliGajhUE/iT LpLg== Received: by 10.68.193.135 with SMTP id ho7mr21703667pbc.119.1334000938269; Mon, 09 Apr 2012 12:48:58 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id l6sm15731378pbp.33.2012.04.09.12.48.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 12:48:57 -0700 (PDT) Message-ID: <4F833D26.4000105@gmail.com> Date: Mon, 09 Apr 2012 11:48:54 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 09 Apr 2012 19:48:59 -0000 On 4/9/12 12:19 AM, Morteza Ansari (moransar) wrote: > During the interop testing in Paris we discovered a few bugs in the spec > that require clarification and some additions. Should we discuss such > issues and resulting changes on the IETF mailing list or continue to > work on these very specific 1.0 issues on the old mailing list and > weekly calls we had? I haven't seen a response from the ADs but from my perspective I don't see any reason why the drafts shouldn't reflect the current state of the protocol (assuming you don't go the websockets route and post several updates/day). If at some point in the future there's a working group chartered it's pretty much a given that you can expect changes both large and small to what's currently defined, and I don't know whether or not you're planning on tracking what the IETF does or forking off an IETF version while keeping the current collaborative version, but either way it seems premature to me to fork versions, which I think is effectively what you're asking about. Melinda From phil.hunt@oracle.com Mon Apr 9 13:09: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 5A24F21F87F9 for ; Mon, 9 Apr 2012 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.336 X-Spam-Level: X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 2TAqig97xCdy for ; Mon, 9 Apr 2012 13:09:42 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8E72921F87F4 for ; Mon, 9 Apr 2012 13:09:42 -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 q39K9bga023591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Apr 2012 20:09:38 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 q39K9aEu027679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 20:09:37 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q39K9aDC026217; Mon, 9 Apr 2012 15:09:36 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Apr 2012 13:09:36 -0700 References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> In-Reply-To: <4F833D26.4000105@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Mon, 9 Apr 2012 13:10:08 -0700 To: Melinda Shore X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090205.4F834202.008D,ss=1,re=0.000,fgs=0 Cc: "scim@ietf.org" Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 09 Apr 2012 20:09:43 -0000 I have no problem with the authors revising the drafts-it isnt like we are i= n WGLC. :) IMHO all feedback/discussion should go through the ietf scim mailing list. Phil On 2012-04-09, at 12:48, Melinda Shore wrote: > On 4/9/12 12:19 AM, Morteza Ansari (moransar) wrote: >> During the interop testing in Paris we discovered a few bugs in the spec >> that require clarification and some additions. Should we discuss such >> issues and resulting changes on the IETF mailing list or continue to >> work on these very specific 1.0 issues on the old mailing list and >> weekly calls we had? >=20 > I haven't seen a response from the ADs but from my perspective I don't > see any reason why the drafts shouldn't reflect the current state of the > protocol (assuming you don't go the websockets route and post several > updates/day). If at some point in the future there's a working group > chartered it's pretty much a given that you can expect changes both > large and small to what's currently defined, and I don't know whether > or not you're planning on tracking what the IETF does or forking off > an IETF version while keeping the current collaborative version, but > either way it seems premature to me to fork versions, which I think > is effectively what you're asking about. >=20 > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From lear@cisco.com Mon Apr 9 13:15: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 A27B621F87FF for ; Mon, 9 Apr 2012 13:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 u4OKyS8zI-Dy for ; Mon, 9 Apr 2012 13:15:52 -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 E769021F878A for ; Mon, 9 Apr 2012 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=5234; q=dns/txt; s=iport; t=1334002540; x=1335212140; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VuSzvlDKmkhyysy7esbZen/8BbgzqlqQtOtas3czJmc=; b=B6Px3LkfmSZhl5/4dR26Kg3Garf4ZG2HG9VGWDjpaL4DCAtaovHIfW8j KNphlfsgYNybPTXaNOXdUtdm6JhvNrFlcJLjB5QTKRH2gTSCy5gkxXfop iRS07R6hGp4HrmYPneAMtSGqVKInud9o4PELkPNdql0v6MWttGVniVVbU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHBCg0+Q/khN/2dsb2JhbABDhXOzbYEHggkBAQEEAQEBDwEQSwoBEAsEFAkWCwICCQMCAQIBDwYwBg0BBQIBAR6HXgMLC55ejQuJKA2BZwSKLYUmgRgElWyLOYMUgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,395,1330905600"; d="scan'208,217";a="134635346" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2012 20:15:38 +0000 Received: from dhcp-10-55-82-137.cisco.com (dhcp-10-55-82-137.cisco.com [10.55.82.137]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q39KFbIT007984; Mon, 9 Apr 2012 20:15:37 GMT Message-ID: <4F834369.1000705@cisco.com> Date: Mon, 09 Apr 2012 22:15:37 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Phil Hunt References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> In-Reply-To: <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> X-Enigmail-Version: 1.4 Content-Type: multipart/alternative; boundary="------------080104080404030909040506" Cc: "scim@ietf.org" , Melinda Shore Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 09 Apr 2012 20:15:52 -0000 This is a multi-part message in MIME format. --------------080104080404030909040506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit What Melinda and Phil said. From an IETF perspective the procedure is *normally* that WG control is asserted at the point of adoption of WG drafts. That having been said, if the drafts are mentioned in the charter and the charter is approved, they should be relatively stable during that period, IMHO. Eliot On 4/9/12 10:10 PM, Phil Hunt wrote: > I have no problem with the authors revising the drafts-it isnt like we are in WGLC. :) > > IMHO all feedback/discussion should go through the ietf scim mailing list. > > Phil > > On 2012-04-09, at 12:48, Melinda Shore wrote: > >> On 4/9/12 12:19 AM, Morteza Ansari (moransar) wrote: >>> During the interop testing in Paris we discovered a few bugs in the spec >>> that require clarification and some additions. Should we discuss such >>> issues and resulting changes on the IETF mailing list or continue to >>> work on these very specific 1.0 issues on the old mailing list and >>> weekly calls we had? >> I haven't seen a response from the ADs but from my perspective I don't >> see any reason why the drafts shouldn't reflect the current state of the >> protocol (assuming you don't go the websockets route and post several >> updates/day). If at some point in the future there's a working group >> chartered it's pretty much a given that you can expect changes both >> large and small to what's currently defined, and I don't know whether >> or not you're planning on tracking what the IETF does or forking off >> an IETF version while keeping the current collaborative version, but >> either way it seems premature to me to fork versions, which I think >> is effectively what you're asking about. >> >> 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 > --------------080104080404030909040506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit What Melinda and Phil said.  From an IETF perspective the procedure is normally that WG control is asserted at the point of adoption of WG drafts.  That having been said, if the drafts are mentioned in the charter and the charter is approved, they should be relatively stable during that period, IMHO.

Eliot

On 4/9/12 10:10 PM, Phil Hunt wrote: 
I have no problem with the authors revising the drafts-it isnt like we are in WGLC. :)

IMHO all feedback/discussion should go through the ietf scim mailing list.

Phil

On 2012-04-09, at 12:48, Melinda Shore <melinda.shore@gmail.com> wrote:


On 4/9/12 12:19 AM, Morteza Ansari (moransar) wrote:

During the interop testing in Paris we discovered a few bugs in the spec
that require clarification and some additions. Should we discuss such
issues and resulting changes on the IETF mailing list or continue to
work on these very specific 1.0 issues on the old mailing list and
weekly calls we had?

I haven't seen a response from the ADs but from my perspective I don't
see any reason why the drafts shouldn't reflect the current state of the
protocol (assuming you don't go the websockets route and post several
updates/day).  If at some point in the future there's a working group
chartered it's pretty much a given that you can expect changes both
large and small to what's currently defined, and I don't know whether
or not you're planning on tracking what the IETF does or forking off
an IETF version while keeping the current collaborative version, but
either way it seems premature to me to fork versions, which I think
is effectively what you're asking about.

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
--------------080104080404030909040506-- From moransar@cisco.com Mon Apr 9 18:55: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 CDEDC11E8074 for ; Mon, 9 Apr 2012 18:55:36 -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 4jkbNnfAqMwP for ; Mon, 9 Apr 2012 18:55:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C758B11E8073 for ; Mon, 9 Apr 2012 18:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=8159; q=dns/txt; s=iport; t=1334022935; x=1335232535; h=mime-version:subject:date:message-id:from:to; bh=/3AAhiWyMWq9EqsRcmxth+5KBMQ4D1ojU37WUWABL6M=; b=K+oyLixDTWWQC25w2Gprc25PMhB8YmH+BQx3h2IbvgdbMWqHnemENOFL Gcy6/l98rtu+UmdcrnP7cagzOYl1u/9WBb8AKkNLg7heXDUNFRvvJ2Kf6 hOCa9D4Yi8uFt4rXjL09R0uAlaAIUJJwtz9UBzjpr9YXOOUkZSqRJlxHG c=; X-Files: charter7.txt : 3351 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADCSg0+tJXHA/2dsb2JhbAA5AQmCU7cMgQeCCwEEAQEBDwEJEQM+HQEMHgIEGAcBJTEBBBECCAEZh2wLnUaBJ5hHixMGAQiEXGMEiFqGEoEjlCqBaYMFIIEWCA X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="txt'?scan'208,217";a="73315501" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 10 Apr 2012 01:55:35 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3A1tZsf013159 for ; Tue, 10 Apr 2012 01:55:35 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); Mon, 9 Apr 2012 20:55:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD16BD.04D741B5" Date: Mon, 9 Apr 2012 20:55:33 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1A== From: "Morteza Ansari (moransar)" To: X-OriginalArrivalTime: 10 Apr 2012 01:55:34.0863 (UTC) FILETIME=[04CA9DF0:01CD16BD] Subject: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 01:55:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD16BD.04D741B5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD16BD.04D741B5" ------_=_NextPart_002_01CD16BD.04D741B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting. Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs. =20 Phil, I added a note regarding targeting extensions in the updated charter given the email discussions. =20 =20 Cheers, Morteza ------_=_NextPart_002_01CD16BD.04D741B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = folks,

 

Here is the updated charter based on the discussions = that took place in the BoF meeting and some guidance from a hallway = conversation with Pete after the meeting.  Please review the text = and send your comments. Hopefully we can close this soon and hand it = over to the ADs.

 

Phil, I = added a note regarding targeting extensions in the updated charter given = the email discussions.

 

 

Cheers,

Morteza

------_=_NextPart_002_01CD16BD.04D741B5-- ------_=_NextPart_001_01CD16BD.04D741B5 Content-Type: text/plain; name="charter7.txt" Content-Transfer-Encoding: base64 Content-Description: charter7.txt Content-Disposition: attachment; filename="charter7.txt" U2ltcGxlIENsb3VkIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pCkNoYWlyKHMpOiBUQkQgCkFw cGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yKHMpOgogICAgIFBldGUgUmVzbmljayA8cHJlc25pY2tA cXVhbGNvbW0uY29tPiAKICAgICBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+ IApNYWlsaW5nIExpc3RzOgogICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogc2NpbUBpZXRmLm9yZwog ICAgIFRvIFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z Y2ltCiAgICAgQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Nj aW0vY3VycmVudC9tYWlsbGlzdC5odG1sCiAKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoK VGhlIFNpbXBsZSBDbG91ZCBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSBzcGVjaWZpY2F0aW9u IHdpbGwgYmUgZGVzaWduZWQgdG8gCnNpbXBsaWZ5IHVzZXIgaWRlbnRpdHkgbWFuYWdlbWVudCBp biBzZXJ2aWNlcyBhbmQgYXBwbGljYXRpb25zIGJ5IGRlZmluaW5nCnN0YW5kYXJkIHByb3RvY29s cyBhbmQgc2NoZW1hcyBmb3IgY3JlYXRpbmcsIHJlYWRpbmcvc2VhcmNoaW5nLCBtb2RpZnlpbmcs CmFuZCBkZWxldGluZyB1c2VyIGlkZW50aXRpZXMgYW5kIGlkZW50aXR5LXJlbGF0ZWQgb2JqZWN0 cyBhY3Jvc3MgCmFkbWluaXN0cmF0aXZlIGRvbWFpbnMuCgpUb2RheSwgZGlzdHJpYnV0ZWQgaWRl bnRpdHkgbWFuYWdlbWVudCBhY3Jvc3Mgc3VjaCBkb21haW5zIGlzIGNvbXBsaWNhdGVkCmJ5IGEg bGFjayBvZiBwcm90b2NvbCBhbmQgc2NoZW1hIHN0YW5kYXJkaXphdGlvbiBiZXR3ZWVuIGNvbnN1 bWVycyBhbmQKcHJvZHVjZXJzIG9mIGlkZW50aXRpZXMuICBUaGlzIGhhcyBsZWQgdG8gYSBudW1i ZXIgb2YgYXBwcm9hY2hlcywKaW5jbHVkaW5nIGVycm9yIHByb25lIG1hbnVhbCBhZG1pbmlzdHJh dGlvbiBhbmQgYnVsayBmaWxlIHVwbG9hZHMsCmFzIHdlbGwgYXMgcHJvcHJpZXRhcnkgcHJvdG9j b2xzIGFuZCBtZWRpYXRpb24gZGV2aWNlcyB0aGF0IG11c3QgYmUKYWRhcHRlZCB0byBlYWNoIHNl cnZpY2UgZm9yIGVhY2ggb3JnYW5pemF0aW9uLiAgV2hpbGUgdGhlcmUgaXMgZXhpc3Rpbmcgd29y awppbiB0aGUgZmllbGQsIGl0IGhhcyBub3QgYmVlbiB3aWRlbHkgYWRvcHRlZCBmb3IgYSB2YXJp ZXR5IG9mIHJlYXNvbnMKaW5jbHVkaW5nLCBhIGxhY2sgb2YgY29tbW9uIHNjaGVtYSwgdG9vbHNl dHMsIGFuZCBsaWJyYXJpZXMuCgpUaGUgU0NJTSB3b3JraW5nIGdyb3VwIHdpbGwgZGV2ZWxvcCB0 aGUgY29yZSBzY2hlbWEgYW5kIFJFU1RmdWwgaW50ZXJmYWNlcwp0byBhZGRyZXNzIHRoZXNlIHBy b2JsZW1zLiBJbml0aWFsbHksIHRoZSBXRyB3aWxsIGZvY3VzIG9uIGEgc2NoZW1hIGRlZmluaXRp b24KYW5kIHNldCBvZiBvcGVyYXRpb25zIGZvciBjcmVhdGlvbiwgbW9kaWZpY2F0aW9uLCBhbmQg ZGVsZXRpb24gb2YgdXNlcnMsIGFzCndlbGwgYXMgc2NoZW1hIGRpc2NvdmVyeSwgc2VhcmNoLCBh bmQgYnVsayBvcGVyYXRpb25zIGZvbGxvd2VkIGJ5IGV4dGVuc2lvbnMKaW5jbHVkaW5nIGNsaWVu dCB0YXJnZXRpbmcgb2Ygc3BlY2lmaWMgU0NJTSBlbmRwb2ludHMuICBUaGUgYXBwcm9hY2ggd2ls bCBiZQpleHRlbnNpYmxlLgoKVGhlIGdyb3VwIHdpbGwgdXNlLCBhcyBzdGFydGluZyBwb2ludHMs IHRoZSBmb2xsb3dpbmcgZHJhZnRzIGluIHRoZSBmb2xsb3dpbmcKd2F5czoKCiAgICAgZHJhZnQt c2NpbS11c2UtY2FzZXMtMDAgYXMgdGhlIGluaXRpYWwgdXNlIGNhc2VzIGZvciBTQ0lNLAogICAg IGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDAgYXMgdGhlIHNjaGVtYSBzcGVjaWZpY2F0aW9uLAog ICAgIGRyYWZ0LXNjaW0tYXBpLTAwIGFzIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLAoKVGhl c2UgZHJhZnRzIGFyZSBiYXNlZCBvbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucywgd2hpY2ggdG9n ZXRoZXIgYXJlIGNvbW1vbmx5Cmtub3duIGFzIFNDSU0gMS4wLiAgQXMgc3VjaCwgc29tZSBjb25z aWRlcmF0aW9uIHNob3VsZCBiZSBnaXZlbiBmb3IgYmFja3dhcmQKY29tcGF0aWJpbGl0eSBhcyB0 aGUgZ3JvdXAgZXZvbHZlcyB0aGUgd29yay4gIFRoaXMgZ3JvdXAgd2lsbCBjb25zaWRlciwKdGhl IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgZ2F0aGVyZWQgZnJvbSB0aGUgZXhpc3Rpbmcgd29yaywg YXMgd2VsbCBhcyAKZXhwZXJpZW5jZXMgd2l0aCB3b3JrIGRvbmUgYnkgb3RoZXIgYm9kaWVzLCBp bmNsdWRpbmcgdGhlIE9BU0lTIFByb3Zpc2lvbmluZyAKVEMuCgpUaGUgZ3JvdXAgd2lsbCBwcm9k dWNlIFByb3Bvc2VkIFN0YW5kYXJkcyBmb3IgYSBzY2hlbWEsIGEgcHJvdG9jb2wsIGEgU0FNTApi aW5kaW5nLCBhbmQgYW4gTERBUCBtYXBwaW5nLiAgSW4gZG9pbmcgc28sIHRoZSBncm91cCB3aWxs IG1ha2UgY29uc2lzdGVudAp0aGUgdGVybWlub2xvZ3ksIHJldmlldyBhbmQgaW1wcm92ZSBzZWN1 cml0eSBvZiB0aGUgb3ZlcmFsbCBzeXN0ZW0sCmlkZW50aWZ5IGFueSBmdW5jdGlvbmFsIGdhcHMg dGhhdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGZ1dHVyZSB3b3JrLCBhZGRyZXNzCmludGVybmF0aW9u YWxpemF0aW9uLCBhbmQgcHJvdmlkZSBndWlkZWxpbmVzIGZvciBleHRlbnNpYmlsaXR5IChlaXRo ZXIKdGhyb3VnaCBJQU5BIHJlZ2lzdHJpZXMgb3Igb3RoZXIgbWVhbnMpLiAgCgpUaGUgZ3JvdXAg Y29uc2lkZXJzIHRoZSBmb2xsb3dpbmcgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGdyb3VwOgogICAg IERlZmluaW5nIG5ldyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzCiAgICAgRGVmaW5pbmcgbmV3IHBv bGljeS9hdXRob3JpemF0aW9uIHNjaGVtZXMKCk1pbGVzdG9uZXMKCm1tL3l5eXkgICAgSW5pdGlh bCBhZG9wdGlvbiBvZiBTQ0lNIHVzZSBjYXNlcywgYXMgYSBsaXZpbmcgZG9jdW1lbnQKbW0veXl5 eSAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gY29yZSBzY2hlbWEKbW0veXl5eSAgICBJbml0 aWFsIGFkb3B0aW9uIG9mIFNDSU0gcmVzdGZ1bCBpbnRlcmZhY2UgZHJhZnQKbW0veXl5eSAgICBJ bml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gU0FNTCBiaW5kaW5ncyBkcmFmdAptbS95eXl5ICAgIElu aXRpYWwgYWRvcHRpb24gb2YgU0NJTSBMREFQIG1hcHBpbmcgZHJhZnQKbW0veXl5eSAgICBXR0xD IFNDSU0gY29yZSBzY2hlbWEKbW0veXl5eSAgICBXR0xDIFNDSU0gcmVzdGZ1bCBpbnRlcmZhY2UK bW0veXl5eSAgICBXR0xDIFNDSU0gU0FNTCBiaW5kaW5ncwptbS95eXl5ICAgIFdHTEMgU0NJTSBM REFQIG1hcHBpbmcKbW0veXl5eSAgICBSZS1jaGFydGVyIGRpc2N1c3Npb24K ------_=_NextPart_001_01CD16BD.04D741B5-- From Paul.Lipton@ca.com Mon Apr 9 18:58: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 1CFEF11E8074 for ; Mon, 9 Apr 2012 18:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zgP5-+EZw6w for ; Mon, 9 Apr 2012 18:58:34 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id C2ECA11E8073 for ; Mon, 9 Apr 2012 18:58:33 -0700 (PDT) Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKT4OTyX/Xi2gD4RgFZa8PCDCLSN7YMNJ7@postini.com; Mon, 09 Apr 2012 18:58:33 PDT Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com (141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 21:58:32 -0400 Received: from USILMS111B.ca.com ([169.254.8.145]) by usilms173.ca.com ([141.202.6.23]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 21:58:32 -0400 From: "Lipton, Paul C" To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AANPdrQ Date: Tue, 10 Apr 2012 01:58:31 +0000 Message-ID: References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.6.54] Content-Type: multipart/alternative; boundary="_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F24C9usilms111bcacom_" MIME-Version: 1.0 Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 01:58:35 -0000 --_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F24C9usilms111bcacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Could somebody please provide a brief summary of where SCIM now stands and = the proposed next steps / timeline? I think it would be very helpful to tho= se who could not attend the BoF. Thanks, Paul Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mor= teza Ansari (moransar) Sent: Monday, April 09, 2012 9:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 Hi folks, Here is the updated charter based on the discussions that took place in the= BoF meeting and some guidance from a hallway conversation with Pete after = the meeting. Please review the text and send your comments. Hopefully we c= an close this soon and hand it over to the ADs. Phil, I added a note regarding targeting extensions in the updated charter = given the email discussions. Cheers, Morteza --_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F24C9usilms111bcacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Could somebody please provide a brief s= ummary of where SCIM now stands and the proposed next steps / timeline? I t= hink it would be very helpful to those who could not attend the BoF.

 

Thanks,=

Paul

 <= /p>

Paul Lipton

CA Technologies

VP, Industry Standards an= d Open Source

Member, CA Council for Te= chnical Excellence

Office Phone:= +1 609 583-9718

Mobile: += 1 267 987-6887

Email: paul.lipton@ca.com

 <= /p>

 

 

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, April 09, 2012 9:56 PM
To: scim@ietf.org
Subject: [scim] Draft charter - v7

 

Hi folks,

 

Here is the updated charter based on the discussions= that took place in the BoF meeting and some guidance from a hallway conver= sation with Pete after the meeting.  Please review the text and send y= our comments. Hopefully we can close this soon and hand it over to the ADs.

 

Phil, I added a note regarding targeting extensions = in the updated charter given the email discussions.

 

 

Cheers,

Morteza

--_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F24C9usilms111bcacom_-- From melinda.shore@gmail.com Mon Apr 9 19:13: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 F1D3E21F871A for ; Mon, 9 Apr 2012 19:13: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 ZXuP9CtZssFG for ; Mon, 9 Apr 2012 19:13:38 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8117F21F85B6 for ; Mon, 9 Apr 2012 19:13:38 -0700 (PDT) Received: by dady13 with SMTP id y13so8254461dad.27 for ; Mon, 09 Apr 2012 19:13: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=OUhj41XOZlw8q+iEFyHCpWGouzwWo2mOcfXWotVJeNA=; b=evZdPPsK9iisVrXFI97LvXNVvTkKqQE+lu+CBUthzAS4RXncb3ohKUA7r8uS/5kE4j 1Q+eCegUq2rTkUEzQXF396O2dvFPBTEI7wL0DhJUnzHfNbS5gbZN9QtxUL6MObLzFSyg ogv+OJeG19e/HWTstPlq9/Rgi19ud2DtoRB3CG9XHNXxlk/mqklj/DMUH/8HSYQyN5hf 7sbE0kBW3+M6xhMNIJphB4M59GgBy1VJLX93bSsxjU7cKmu3TJ5k+iYKaYkPqT/qhGTd 3Ic0+wOY4m8nPGFFE7Fz1hjqA7lOuntCqi4Z1cUS1YwDPyyORZl8ZJ0nqXoYqwz694vo EW7A== Received: by 10.68.132.69 with SMTP id os5mr24291311pbb.60.1334024018354; Mon, 09 Apr 2012 19:13:38 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id z5sm16520667pbn.35.2012.04.09.19.13.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 19:13:37 -0700 (PDT) Message-ID: <4F83974F.40302@gmail.com> Date: Mon, 09 Apr 2012 18:13:35 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:13:39 -0000 On 4/9/12 5:55 PM, Morteza Ansari (moransar) wrote: > Here is the updated charter based on the discussions that took place in > the BoF meeting and some guidance from a hallway conversation with Pete > after the meeting. Please review the text and send your comments. > Hopefully we can close this soon and hand it over to the ADs. I'd like to see the whole "cloud" thing go away, for several reasons: 1) The architecture as it currently stands is actually more general than that, and is applicable other use cases. For example, it's now reasonably common to provision enterprise accounts out of an ERP application and it's often done in a batch mode through generated LDIF or even SQL. 2) This is really not your fault but the whole "cloud" thing has been poisoned at the IETF and I would not to see cycles wasted dealing with that. I'd be happy to write up a non-cloud use case. I think there's a compelling argument to be made that this is a more generally useful mechanism/architecture than you may fully realize, and that it can be leveraged without much change to what you've already got. Melinda From moransar@cisco.com Mon Apr 9 19:24:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F221F8681 for ; Mon, 9 Apr 2012 19:24:49 -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 1wIej56r40pl for ; Mon, 9 Apr 2012 19:24:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CD31811E8074 for ; Mon, 9 Apr 2012 19:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=1623; q=dns/txt; s=iport; t=1334024688; x=1335234288; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dg1RKIb+rSl1E3vp5iQJVgEHqoyb/a/48HzjzHnzfuk=; b=dQTxehPVwl2pkGlxSPFndOat91HOqP+BsuAqUgXBYyx9fBia/OuWRFCe 1Bfk3Qw52Dh8liMxqA64vXneFJ7nXk7BihCZL0pMHaKB+t1Gw/yuN36HG eEf3c9Vq3J0MylQimLY/M2ER4bzjNJ1y1yvhMOA0O0q4DWesHy6crIhh3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGyZg0+tJV2c/2dsb2JhbABEuVKBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRAQMBAQEKBhcBBgEmHwMGCAEBBAESCBqHbAuaKqArBI9+YwSIWptfgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="73346214" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 10 Apr 2012 02:24:48 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3A2OmA7027877; Tue, 10 Apr 2012 02:24:48 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); Mon, 9 Apr 2012 21:24: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, 9 Apr 2012 21:24:47 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C36@XMB-RCD-313.cisco.com> In-Reply-To: <4F83974F.40302@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0Wv41ElH++ZDzjSKGXmHMNnyApZAAAQkpA References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> From: "Morteza Ansari (moransar)" To: "Melinda Shore" , X-OriginalArrivalTime: 10 Apr 2012 02:24:47.0979 (UTC) FILETIME=[19BAE3B0:01CD16C1] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:24:49 -0000 Other than the working group name, there is no mention of cloud in the charter anymore.=20 Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Monday, April 09, 2012 7:14 PM To: scim@ietf.org Subject: Re: [scim] Draft charter - v7 On 4/9/12 5:55 PM, Morteza Ansari (moransar) wrote: > Here is the updated charter based on the discussions that took place=20 > in the BoF meeting and some guidance from a hallway conversation with=20 > Pete after the meeting. Please review the text and send your comments. > Hopefully we can close this soon and hand it over to the ADs. I'd like to see the whole "cloud" thing go away, for several reasons: 1) The architecture as it currently stands is actually more general than that, and is applicable other use cases. For example, it's now reasonably common to provision enterprise accounts out of an ERP application and it's often done in a batch mode through generated LDIF or even SQL. 2) This is really not your fault but the whole "cloud" thing has been poisoned at the IETF and I would not to see cycles wasted dealing with that. I'd be happy to write up a non-cloud use case. I think there's a compelling argument to be made that this is a more generally useful mechanism/architecture than you may fully realize, and that it can be leveraged without much change to what you've already got. Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From moransar@cisco.com Mon Apr 9 19:28: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 E1CDB21F86DE for ; Mon, 9 Apr 2012 19:28:56 -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 uoF5QJgeF5rf for ; Mon, 9 Apr 2012 19:28:55 -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 1B98921F8672 for ; Mon, 9 Apr 2012 19:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=10027; q=dns/txt; s=iport; t=1334024935; x=1335234535; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=I0QFK+zDEPOGG8yjKbX6FCpctvZOs7zWgPILxPw5OAc=; b=DttpT5XDeaeF+VRBWxQnEIR7hQubU6gW7sJSn7RWUHaGkpHyCE+KcN9/ dTQFG8/FkE/dbha9rG78t7OKM2musuNWUnGchrSPLo2k4SmrFpPmp2GF5 aguYKQygPN6cPl5ZQsBJsvVcCw1WAd1sJ3BAMeCMlLFfGvY8TFWeGhO1/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJyZg0+tJXG//2dsb2JhbABBA4JGtwyBB4IJAQEBBBIBCREDPhkCAgEIEQQBAQsGFwEGARorCQgBAQQBEggah2yaNaAvBI00gkZjBIham1+BaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208,217";a="73333273" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 10 Apr 2012 02:28:54 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3A2Ss9L002212; Tue, 10 Apr 2012 02:28:54 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 21:28:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD16C1.AC708DDD" Date: Mon, 9 Apr 2012 21:28:53 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C37@XMB-RCD-313.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AANPdrQAAD6UVA= References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> From: "Morteza Ansari (moransar)" To: "Lipton, Paul C" , X-OriginalArrivalTime: 10 Apr 2012 02:28:54.0272 (UTC) FILETIME=[AC883800:01CD16C1] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:28:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD16C1.AC708DDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We had a BoF in Paris and are revising the proposed charter based on the discussions in the meeting. Once we settle on the text of the charter in the mailing list we will ask the AD's/IESG to review and discuss it. If IESG decides to form a WG, then we are set and we move forward. =20 =20 Cheers, Morteza =20 From: Lipton, Paul C [mailto:Paul.Lipton@ca.com]=20 Sent: Monday, April 09, 2012 6:59 PM To: Morteza Ansari (moransar); scim@ietf.org Subject: RE: Draft charter - v7 =20 Hi all, =20 Could somebody please provide a brief summary of where SCIM now stands and the proposed next steps / timeline? I think it would be very helpful to those who could not attend the BoF.=20 =20 Thanks, Paul=20 =20 Paul Lipton CA Technologies VP, Industry Standards and Open Source=20 Member, CA Council for Technical Excellence=20 Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com =20 =20 =20 =20 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Monday, April 09, 2012 9:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 =20 Hi folks, =20 Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting. Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs. =20 Phil, I added a note regarding targeting extensions in the updated charter given the email discussions. =20 =20 Cheers, Morteza ------_=_NextPart_001_01CD16C1.AC708DDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We had a BoF in Paris and are revising the = proposed charter based on the discussions in the meeting. Once we settle = on the text of the charter in the mailing list we will ask the = AD’s/IESG to review and discuss it. If IESG decides to form a WG, = then we are set and we move forward.

 

 

Cheers,

Morteza

 

From:= = Lipton, Paul C [mailto:Paul.Lipton@ca.com]
Sent: Monday, = April 09, 2012 6:59 PM
To: Morteza Ansari (moransar); = scim@ietf.org
Subject: RE: Draft charter - = v7

 

Hi = all,

 =

Could = somebody please provide a brief summary of where SCIM now stands and the = proposed next steps / timeline? I think it would be very helpful to = those who could not attend the BoF.

 =

Thanks,

Paul

 

Paul Lipton

CA Technologies

VP, Industry Standards and Open Source

Member, CA Council for Technical Excellence

Office Phone: +1 609 583-9718

Mobile: +1 267 987-6887

Email: paul.lipton@ca.com

 

 

 =

From:= = scim-bounces@ietf.org [mailto:scim-bounces@ietf.= org] On Behalf Of Morteza Ansari (moransar)
Sent: = Monday, April 09, 2012 9:56 PM
To: scim@ietf.org
Subject: = [scim] Draft charter - v7

 

Hi = folks,

 

Here is the updated charter based on the discussions = that took place in the BoF meeting and some guidance from a hallway = conversation with Pete after the meeting.  Please review the text = and send your comments. Hopefully we can close this soon and hand it = over to the ADs.

 

Phil, I = added a note regarding targeting extensions in the updated charter given = the email discussions.

 

 

Cheers,

Morteza

------_=_NextPart_001_01CD16C1.AC708DDD-- From Paul.Lipton@ca.com Mon Apr 9 19:30: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 8ECFD21F86DE for ; Mon, 9 Apr 2012 19:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0rBwzRY+dZl for ; Mon, 9 Apr 2012 19:30:32 -0700 (PDT) Received: from psmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA9121F8672 for ; Mon, 9 Apr 2012 19:30:31 -0700 (PDT) Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKT4ObRmtG1cnMZWB47M3klmvsgr2XTfVj@postini.com; Mon, 09 Apr 2012 19:30:31 PDT Received: from USILMS172.ca.com (141.202.6.22) by USILMS191.ca.com (141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 22:30:30 -0400 Received: from USILMS111B.ca.com ([169.254.8.145]) by USILMS172.ca.com ([141.202.6.22]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 22:30:29 -0400 From: "Lipton, Paul C" To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AANPdrQAAD6UVAAACs4kA== Date: Tue, 10 Apr 2012 02:30:29 +0000 Message-ID: References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C37@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C37@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.6.54] Content-Type: multipart/alternative; boundary="_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F25AAusilms111bcacom_" MIME-Version: 1.0 Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:30:33 -0000 --_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F25AAusilms111bcacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Morteza. That was helpful. Any timeline at all to this, if I may as= k? Thanks again, Paul From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Monday, April 09, 2012 10:29 PM To: Lipton, Paul C; scim@ietf.org Subject: RE: Draft charter - v7 We had a BoF in Paris and are revising the proposed charter based on the di= scussions in the meeting. Once we settle on the text of the charter in the = mailing list we will ask the AD's/IESG to review and discuss it. If IESG de= cides to form a WG, then we are set and we move forward. Cheers, Morteza From: Lipton, Paul C [mailto:Paul.Lipton@ca.com] Sent: Monday, April 09, 2012 6:59 PM To: Morteza Ansari (moransar); scim@ietf.org Subject: RE: Draft charter - v7 Hi all, Could somebody please provide a brief summary of where SCIM now stands and = the proposed next steps / timeline? I think it would be very helpful to tho= se who could not attend the BoF. Thanks, Paul Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Morteza A= nsari (moransar) Sent: Monday, April 09, 2012 9:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 Hi folks, Here is the updated charter based on the discussions that took place in the= BoF meeting and some guidance from a hallway conversation with Pete after = the meeting. Please review the text and send your comments. Hopefully we c= an close this soon and hand it over to the ADs. Phil, I added a note regarding targeting extensions in the updated charter = given the email discussions. Cheers, Morteza --_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F25AAusilms111bcacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Morteza. That was helpful. Any = timeline at all to this, if I may ask?

 

Thanks again,<= /span>

Paul

 

 

From: Morteza = Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Monday, April 09, 2012 10:29 PM
To: Lipton, Paul C; scim@ietf.org
Subject: RE: Draft charter - v7

 

We had a BoF in Paris = and are revising the proposed charter based on the discussions in the meeti= ng. Once we settle on the text of the charter in the mailing list we will a= sk the AD’s/IESG to review and discuss it. If IESG decides to form a WG, then we are set and we move forward.

 

 

Cheers,

Morteza

 

 

Hi all,

 

Could somebody please provide a brief s= ummary of where SCIM now stands and the proposed next steps / timeline? I t= hink it would be very helpful to those who could not attend the BoF.

 

Thanks,=

Paul

 <= /p>

Paul Lipton

CA Technologies

VP, Industry Standards an= d Open Source

Member, CA Council for Te= chnical Excellence

Office Phone:= +1 609 583-9718

Mobile: += 1 267 987-6887

Email: paul.lipton@ca.com

 <= /p>

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar)
Sent: Monday, April 09, 2012 9:56 PM
To: scim@ietf.org
Subject: [scim] Draft charter - v7

 

Hi folks,

 

Here is the updated charter based on the discussions= that took place in the BoF meeting and some guidance from a hallway conver= sation with Pete after the meeting.  Please review the text and send y= our comments. Hopefully we can close this soon and hand it over to the ADs.

 

Phil, I added a note regarding targeting extensions = in the updated charter given the email discussions.

 

 

Cheers,

Morteza

--_000_F54DCD4EE5A606448D414C716DC9FC4F2D4F25AAusilms111bcacom_-- From phil.hunt@oracle.com Mon Apr 9 19:38:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D6E21F872E for ; Mon, 9 Apr 2012 19:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[AWL=0.599, 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 2zgwaOFQhh-W for ; Mon, 9 Apr 2012 19:38:52 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2F521F85D9 for ; Mon, 9 Apr 2012 19:38:52 -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 q3A2coSc025613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 02:38:50 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 q3A2cnfT004368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 02:38:49 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3A2cmVo025635; Mon, 9 Apr 2012 21:38:49 -0500 Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Apr 2012 19:38:48 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C36@XMB-RCD-313.cisco.com> Date: Mon, 9 Apr 2012 19:38:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DB3C877-9C15-4E33-9504-B630F9623900@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C36@XMB-RCD-313.cisco.com> To: "Morteza Ansari (moransar)" X-Mailer: Apple Mail (2.1257) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-CT-RefId: str=0001.0A090205.4F839D3B.002D,ss=1,re=0.000,fgs=0 Cc: scim@ietf.org, Melinda Shore Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:38:53 -0000 The charter is currently very service provider oriented. In fact it = currently looks very much like a RESTful (direcotry) access protocol - = RAP. As Melinda suggests there is definitely more than just cloud = scenarios and that suggests to me that client requirements and other = provisioning concepts need to be considered in the charter. However, I do think Cloud is a key point to keep within the charter (not = necessarily the name). Unlike previous provisioning standardization = efforts, the key motivation for standardization and inter-operability = are cloud scenarios since it is MUCH MORE likely different = implementations will need to work with each other -- whereas with SPML = and other provisioning systems, it didn't really matter the = implementations inter-operated since it was likely the same = implementation. There was a similar story behind the evolution of LDAP = and why replication was never standardized. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-09, at 7:24 PM, Morteza Ansari (moransar) wrote: > Other than the working group name, there is no mention of cloud in the > charter anymore.=20 >=20 >=20 > Cheers, > Morteza >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of > Melinda Shore > Sent: Monday, April 09, 2012 7:14 PM > To: scim@ietf.org > Subject: Re: [scim] Draft charter - v7 >=20 > On 4/9/12 5:55 PM, Morteza Ansari (moransar) wrote: >> Here is the updated charter based on the discussions that took place=20= >> in the BoF meeting and some guidance from a hallway conversation with=20= >> Pete after the meeting. Please review the text and send your = comments. >> Hopefully we can close this soon and hand it over to the ADs. >=20 > I'd like to see the whole "cloud" thing go away, for several reasons: >=20 > 1) The architecture as it currently stands is actually more general = than > that, and is applicable other use cases. For example, it's now > reasonably common to provision enterprise accounts out of an ERP > application and it's often done in a batch mode through generated > LDIF or even SQL. >=20 > 2) This is really not your fault but the whole "cloud" thing has been > poisoned at the IETF and I would not to see cycles wasted dealing > with that. >=20 > I'd be happy to write up a non-cloud use case. I think there's a > compelling argument to be made that this is a more generally useful > mechanism/architecture than you may fully realize, and that it can be > leveraged without much change to what you've already got. >=20 > 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 igor.faynberg@alcatel-lucent.com Mon Apr 9 19:49: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 4DFC221F8737 for ; Mon, 9 Apr 2012 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.412 X-Spam-Level: X-Spam-Status: No, score=-7.412 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 rc-8DTe2h4qY for ; Mon, 9 Apr 2012 19:49:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD3221F8569 for ; Mon, 9 Apr 2012 19:49:16 -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 q3A2nFcR012559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Apr 2012 21:49:15 -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 q3A2nFf4016365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Apr 2012 21:49:15 -0500 Received: from [135.244.0.96] (faynberg.lra.lucent.com [135.244.0.96]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3A2n1Sk005092; Mon, 9 Apr 2012 21:49:02 -0500 (CDT) Message-ID: <4F839F9D.4080506@alcatel-lucent.com> Date: Mon, 09 Apr 2012 22:49:01 -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: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> In-Reply-To: <4F83974F.40302@gmail.com> Content-Type: multipart/alternative; boundary="------------000505060506070008080808" 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] Draft charter - v7 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, 10 Apr 2012 02:49:17 -0000 This is a multi-part message in MIME format. --------------000505060506070008080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I tend to disagree with Melinda here (I mean on the name), as I don't see any actual evidence of the cloud thing in the IETF being "poisoned." It certainly has been discussed for a long while; it is also true that previous proposals had been criticized for being too broad. But the SCIM proposal is *very focused.* We had a very constructive discussion in Paris, and the relation of the project to Cloud has been made clear; in addition, the protocol is actually being implemented, and it is known by its name. Changing it at this time means dropping continuity, which in my opinion is wrong. I think though that the decision on the name belongs to the community that has created SCIM 1.0 and then decided to bring it to us. To this end, I only state an opinion that is different from the one stated before. Igor On 4/9/2012 10:13 PM, Melinda Shore wrote: > On 4/9/12 5:55 PM, Morteza Ansari (moransar) wrote: >> Here is the updated charter based on the discussions that took place in >> the BoF meeting and some guidance from a hallway conversation with Pete >> after the meeting. Please review the text and send your comments. >> Hopefully we can close this soon and hand it over to the ADs. > > I'd like to see the whole "cloud" thing go away, for several reasons: > > 1) The architecture as it currently stands is actually more general than > that, and is applicable other use cases. For example, it's now > reasonably common to provision enterprise accounts out of an ERP > application and it's often done in a batch mode through generated > LDIF or even SQL. > > 2) This is really not your fault but the whole "cloud" thing has been > poisoned at the IETF and I would not to see cycles wasted dealing > with that. > > I'd be happy to write up a non-cloud use case. I think there's a > compelling argument to be made that this is a more generally useful > mechanism/architecture than you may fully realize, and that it can be > leveraged without much change to what you've already got. > > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------000505060506070008080808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I tend to disagree with Melinda  here (I mean on the name), as I don't see any actual evidence of the cloud thing in the IETF being "poisoned."  It certainly has been discussed for a long while; it is also true that previous proposals had been criticized for being too broad. But the SCIM proposal  is very focused.

We had a very constructive discussion in Paris, and the relation of the project to Cloud has been made clear; in addition, the protocol is actually being implemented, and it is known by its name. Changing it at this time means dropping continuity, which in my opinion is wrong.

I think though that the decision on the name belongs to the community that has created SCIM 1.0 and then decided to bring it to us.  To this end, I only state an opinion that is different from the one stated before.

Igor



On 4/9/2012 10:13 PM, Melinda Shore wrote:
On 4/9/12 5:55 PM, Morteza Ansari (moransar) wrote:
Here is the updated charter based on the discussions that took place in
the BoF meeting and some guidance from a hallway conversation with Pete
after the meeting. Please review the text and send your comments.
Hopefully we can close this soon and hand it over to the ADs.

I'd like to see the whole "cloud" thing go away, for several reasons:

1) The architecture as it currently stands is actually more general than
   that, and is applicable other use cases.  For example, it's now
   reasonably common to provision enterprise accounts out of an ERP
   application and it's often done in a batch mode through generated
   LDIF or even SQL.

2) This is really not your fault but the whole "cloud" thing has been
   poisoned at the IETF and I would not to see cycles wasted dealing
   with that.

I'd be happy to write up a non-cloud use case.  I think there's a
compelling argument to be made that this is a more generally useful
mechanism/architecture than you may fully realize, and that it can be
leveraged without much change to what you've already got.

Melinda
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------000505060506070008080808-- From melinda.shore@gmail.com Mon Apr 9 19:55: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 BC77A11E80AA for ; Mon, 9 Apr 2012 19:55:28 -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 WWv6Q2VKh5ns for ; Mon, 9 Apr 2012 19:55:28 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5526811E8074 for ; Mon, 9 Apr 2012 19:55:28 -0700 (PDT) Received: by dady13 with SMTP id y13so8307942dad.27 for ; Mon, 09 Apr 2012 19:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4buNiIuCMtBRAEAoGTWe05O6QveWbrJ0xUTjfjzRtjQ=; b=pbuyQvJ56Ozc4wLYrrdP4NKvJhLUHk8eA6t9f6F3fFDPC2IaqAiALkg+gu07f9wykQ 7vekODHUrGhpAbc8vEkqKtrbX5MNyFvHiqThdeRmngds9xCnKFrfg2vyviqvbNeL/hFp vflq/zFuvp6fbWyBtBZhTmUlq3HUC86BPw8dxrsefBdcOYhwtB/MllUmiB2P6xjLymfA D36YDSkliShrl+ct2nagIKWii3TinO7egrPdokDqWBnOvtqQhrym8BIpxVwwNK9Uj+0k kzAD7HISAPYV367ey+eys8q76yrAEGZjyO/236JonqE8LIjNvjy1Nn0mzLSb4F09LLv/ XoiQ== Received: by 10.68.194.67 with SMTP id hu3mr8516425pbc.111.1334026528105; Mon, 09 Apr 2012 19:55:28 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id ms1sm1870463pbb.38.2012.04.09.19.55.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 19:55:27 -0700 (PDT) Message-ID: <4F83A11C.9010900@gmail.com> Date: Mon, 09 Apr 2012 18:55:24 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> In-Reply-To: <4F839F9D.4080506@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 02:55:28 -0000 On 4/9/12 6:49 PM, Igor Faynberg wrote: > I tend to disagree with Melinda here (I mean on the name), as I don't > see any actual evidence of the cloud thing in the IETF being "poisoned." > It certainly has been discussed for a long while; it is also true that > previous proposals had been criticized for being too broad. But the SCIM > proposal is *very focused.* I think the strongest argument for getting rid of the cloud reference is one you didn't address, which is that there are use cases which are substantially similar architecturally to what's been proposed but take place inside an enterprise or other local-to-local environments. I'm not proposing any substantial changes to the architecture or protocols to accommodate other use cases. I'm saying that there are some already and that the current scope is narrower than it needs to be. If there's a technical argument that "scim" has no applicability to local provisioning, I think that's the argument to make. Melinda From igor.faynberg@alcatel-lucent.com Mon Apr 9 22:05: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 2C14621F87BF for ; Mon, 9 Apr 2012 22:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.249 X-Spam-Level: X-Spam-Status: No, score=-7.249 tagged_above=-999 required=5 tests=[AWL=-0.651, 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 iO4UBck3JA0e for ; Mon, 9 Apr 2012 22:05:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 49A4021F87BA for ; Mon, 9 Apr 2012 22:05:31 -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 q3A55Rlb019966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Apr 2012 00:05:27 -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 q3A55RbB000482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Apr 2012 00:05:27 -0500 Received: from [135.244.0.96] (faynberg.lra.lucent.com [135.244.0.96]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3A55QOl002234; Tue, 10 Apr 2012 00:05:27 -0500 (CDT) Message-ID: <4F83BF96.8040502@alcatel-lucent.com> Date: Tue, 10 Apr 2012 01:05:26 -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: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> In-Reply-To: <4F83A11C.9010900@gmail.com> Content-Type: multipart/alternative; boundary="------------060808020007090109090909" 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 - v7 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, 10 Apr 2012 05:05:33 -0000 This is a multi-part message in MIME format. --------------060808020007090109090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument). Since "Cloud," at least in a narrow interpretation, is about enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too. Yet, the very character of SCIM, its RESTful intention including , does point to the Cloud environment specifically. I think Phil in his previous message (which crossed with mine) implied just that. And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus. I believe you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems. I always tried to resist it. I really think that it is better to complete something and then re-charter to move one to considering larger problems. Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered. /Everything/ could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol. But then one could argue that HTTP should have been renamed into ETP... In any event, as I said, I believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps). Igor On 4/9/2012 10:55 PM, Melinda Shore wrote: > On 4/9/12 6:49 PM, Igor Faynberg wrote: >> I tend to disagree with Melinda here (I mean on the name), as I don't >> see any actual evidence of the cloud thing in the IETF being "poisoned." >> It certainly has been discussed for a long while; it is also true that >> previous proposals had been criticized for being too broad. But the SCIM >> proposal is *very focused.* > > I think the strongest argument for getting rid of the cloud reference > is one you didn't address, which is that there are use cases which are > substantially similar architecturally to what's been proposed but take > place inside an enterprise or other local-to-local environments. > > I'm not proposing any substantial changes to the architecture or > protocols to accommodate other use cases. I'm saying that there are > some already and that the current scope is narrower than it needs > to be. If there's a technical argument that "scim" has no applicability > to local provisioning, I think that's the argument to make. > > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------060808020007090109090909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument).

Since  "Cloud," at least in a narrow interpretation, is about enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too.  Yet, the very character of SCIM, its RESTful intention including , does  point to the Cloud environment specifically.   I think Phil in his previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus.   I believe  you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems.  I always tried to resist it.   I really think that it is better to complete something and then re-charter to move one to considering larger problems. 

 
Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered.  Everything could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol.  But then  one could argue that HTTP should have been renamed into ETP...

In any event, as I said, I  believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda Shore wrote:
On 4/9/12 6:49 PM, Igor Faynberg wrote:
I tend to disagree with Melinda here (I mean on the name), as I don't
see any actual evidence of the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
previous proposals had been criticized for being too broad. But the SCIM
proposal is *very focused.*

I think the strongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases which are
substantially similar architecturally to what's been proposed but take
place inside an enterprise or other local-to-local environments.

I'm not proposing any substantial changes to the architecture or
protocols to accommodate other use cases.  I'm saying that there are
some already and that the current scope is narrower than it needs
to be.  If there's a technical argument that "scim" has no applicability
to local provisioning, I think that's the argument to make.

Melinda
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------060808020007090109090909-- From michael.brenner@alcatel-lucent.com Tue Apr 10 05:57: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 49B1421F851E for ; Tue, 10 Apr 2012 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhbBcdymoeUT for ; Tue, 10 Apr 2012 05:57:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83621F8527 for ; Tue, 10 Apr 2012 05:57:23 -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 q3ACvGZ8024790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Apr 2012 07:57: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 q3ACvGSl007000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 10 Apr 2012 07:57:16 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 10 Apr 2012 07:57:16 -0500 From: "Brenner, Michael Ralf (Michael)" To: "scim@ietf.org" Date: Tue, 10 Apr 2012 07:57:15 -0500 Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0W15BUFprBUUt3TKugW40ey8gv0QAP9yPw Message-ID: <219947F0B2242843A0A1E62FDB510DC0250FFAB6FA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> In-Reply-To: <4F83BF96.8040502@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_219947F0B2242843A0A1E62FDB510DC0250FFAB6FAUSNAVSXCHMBSA_" 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 Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 12:57:27 -0000 --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB6FAUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe we are getting too hung up on the name? Let's put it this way, what's better: a generic name, that no specific doma= in identifies with, or a targeted name that at least clearly identifies a d= omain? I am inclined to go with the latter. I have been involved in too man= y grandiose crash-and-burn projects, and in most cases when it happened it = was because we were trying too hard to please everybody and kept accepting = more and more requirements. Looking back at technologies that were successful in more than 1 domain, I = tend to doubt that what made them successful in multiple domains was the se= lection of a generic name - especially in the case of technologies that are= higher layer than transport of any kind. Personally, I'd rather focus on c= reating a successful technology than making sure that it covers multiple do= mains ... when we go the latter way, the tendency is to either not optimize= for anything or to take too long to complete. My preference would be to focus on a few scenarios and optimize the technol= ogy for those. Those that have other scenario in mind should of course pay= attention and point out undesirable solutions, lack of extensibility to ot= her scenarios. Starting SIMPLE implies starting and completing sooner, and = gives a better rate of success for achieving the few stated goals. If the g= oals are sufficient to cover well 1 domain, and the technology is adopted f= or that domain, this is success. Does anybody wonder WHY after so many year= s we still do not have any reasonable level of adoption of any set of specs= related to IdM? Michael From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Igo= r Faynberg Sent: Tuesday, April 10, 2012 1:05 AM To: scim@ietf.org Subject: Re: [scim] Draft charter - v7 Yes, I agree that there are other use cases (and, yes, I agree that I did n= ot adress that argument). Since "Cloud," at least in a narrow interpretation, is about enterprise ou= tsourcing, a lot of things that relate to Cloud in general relate to enterp= rise, too. Yet, the very character of SCIM, its RESTful intention includin= g , does point to the Cloud environment specifically. I think Phil in hi= s previous message (which crossed with mine) implied just that. And while on the subject of use cases... One danger in considering all appl= icable use cases early in the game--and I do not necessarily mean the speci= fic case you brought up--is potential loss of focus. I believe you and I= share the same experience as former WG chairs: early attempts at generaliz= ation bring feature crip, backward incompatibility, and a score of other pr= oblems. I always tried to resist it. I really think that it is better to= complete something and then re-charter to move one to considering larger p= roblems. Well, just as HTTP was being standardized, its many (unfortunate) uses beyo= nd hyper-text transfer had already been considered. Everything could be tr= ansferred (and beyond firewalls, too!)--and everyone tried to transfer some= thing new, ignoring the very nature of the protocol. But then one could a= rgue that HTTP should have been renamed into ETP... In any event, as I said, I believe that the decision on changing the name = rests with the SCIM original authors; my opinion here is nothing more than = an opinion (wrong perhaps). Igor On 4/9/2012 10:55 PM, Melinda Shore wrote: On 4/9/12 6:49 PM, Igor Faynberg wrote: I tend to disagree with Melinda here (I mean on the name), as I don't see any actual evidence of the cloud thing in the IETF being "poisoned." It certainly has been discussed for a long while; it is also true that previous proposals had been criticized for being too broad. But the SCIM proposal is *very focused.* I think the strongest argument for getting rid of the cloud reference is one you didn't address, which is that there are use cases which are substantially similar architecturally to what's been proposed but take place inside an enterprise or other local-to-local environments. I'm not proposing any substantial changes to the architecture or protocols to accommodate other use cases. I'm saying that there are some already and that the current scope is narrower than it needs to be. If there's a technical argument that "scim" has no applicability to local provisioning, I think that's the argument to make. Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB6FAUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Maybe we are getting too hung up on the name?

<= p class=3DMsoNormal>Let’s put it this way, what’s better= : a generic name, that no specific domain identifies with, or a targeted na= me that at least clearly identifies a domain? I am inclined to go with the = latter. I have been involved in too many grandiose crash-and-burn projects,= and in most cases when it happened it was because we were trying too hard = to please everybody and kept accepting more and more requirements.

 

Looking back at technologies that were successful in = more than 1 domain, I tend to doubt that what made them successful in multi= ple domains was the selection of a generic name – especially in the c= ase of technologies that are higher layer than transport of any kind. Perso= nally, I’d rather focus on creating a successful technology than maki= ng sure that it covers multiple domains … when we go the latter way, = the tendency is to either not optimize for anything or to take too long to = complete.

 

My preference would be to focus on = a few scenarios and optimize the technology for those. Those that have othe= r scenario in mind should  of course pay attention and point out undes= irable solutions, lack of extensibility to other scenarios. Starting SIMPLE= implies starting and completing sooner, and gives a better rate of success= for achieving the few stated goals. If the goals are sufficient to cover w= ell 1 domain, and the technology is adopted for that domain, this is succes= s. Does anybody wonder WHY after so many years we still do not have any rea= sonable level of adoption of any set of specs related to IdM?

 

Michael

<= o:p> 

F= rom: scim-bounces@ietf.org [mailto:scim-bounces@ietf.or= g] On Behalf Of Igor Faynberg
Sent: Tuesday, April 10, 201= 2 1:05 AM
To: scim@ietf.org
Subject: Re: [scim] Draft c= harter - v7

&nbs= p;

Yes, I agree that there are other use case= s (and, yes, I agree that I did not adress that argument).

Since&nbs= p; "Cloud," at least in a narrow interpretation, is about enterpr= ise outsourcing, a lot of things that relate to Cloud in general relate to = enterprise, too.  Yet, the very character of SCIM, its RESTful intenti= on including , does  point to the Cloud environment specifically. = ;  I think Phil in his previous message (which crossed with mine) impl= ied just that.

And while on the subject of use cases... One danger i= n considering all applicable use cases early in the game--and I do not nece= ssarily mean the specific case you brought up--is potential loss of focus. =   I believe  you and I share the same experience as former WG cha= irs: early attempts at generalization bring feature crip, backward incompat= ibility, and a score of other problems.  I always tried to resist it. =   I really think that it is better to complete something and then re-c= harter to move one to considering larger problems. 

 
= Well, just as HTTP was being standardized, its many (unfortunate) uses beyo= nd hyper-text transfer had already been considered.  Everything= could be transferred (and beyond firewalls, too!)--and everyone tried to t= ransfer something new, ignoring the very nature of the protocol.  But = then  one could argue that HTTP should have been renamed into ETP...
In any event, as I said, I  believe that the decision on changin= g the name rests with the SCIM original authors; my opinion here is nothing= more than an opinion (wrong perhaps).

Igor




On 4/= 9/2012 10:55 PM, Melinda Shore wrote:

O= n 4/9/12 6:49 PM, Igor Faynberg wrote:

I tend to disagree with Melinda here (I mean on the name), as I don= 't
see any actual evidence of the cloud thing in the IETF being "p= oisoned."
It certainly has been discussed for a long while; it is = also true that
previous proposals had been criticized for being too bro= ad. But the SCIM
proposal is *very focused.*


I think the strongest argument for getting rid of the cloud r= eference
is one you didn't address, which is that there are use cases w= hich are
substantially similar architecturally to what's been proposed = but take
place inside an enterprise or other local-to-local environment= s.

I'm not proposing any substantial changes to the architecture or=
protocols to accommodate other use cases.  I'm saying that there = are
some already and that the current scope is narrower than it needs <= br>to be.  If there's a technical argument that "scim" has n= o applicability
to local provisioning, I think that's the argument to m= ake.

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

= --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB6FAUSNAVSXCHMBSA_-- From kelly.grizzle@sailpoint.com Tue Apr 10 06:40: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 8D6C921F858F for ; Tue, 10 Apr 2012 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 E0E3HwABLYrq for ; Tue, 10 Apr 2012 06:39:58 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 079F221F8582 for ; Tue, 10 Apr 2012 06:39:57 -0700 (PDT) Received: from mail111-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 13:39:56 +0000 Received: from mail111-am1 (localhost [127.0.0.1]) by mail111-am1-R.bigfish.com (Postfix) with ESMTP id BD9B618027A; Tue, 10 Apr 2012 13:39:56 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz9371I9f17Rc85fh4015I111aI62a3I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail111-am1: 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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail111-am1 (localhost.localdomain [127.0.0.1]) by mail111-am1 (MessageSwitch) id 1334065195326894_8171; Tue, 10 Apr 2012 13:39:55 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.235]) by mail111-am1.bigfish.com (Postfix) with ESMTP id 495DEC0077; Tue, 10 Apr 2012 13:39:55 +0000 (UTC) Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 13:39:54 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.2.203]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0135.002; Tue, 10 Apr 2012 13:39:44 +0000 From: Kelly Grizzle To: "Lipton, Paul C" , "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AANPdrQAAD6UVAAACs4kAAXLaRA Date: Tue, 10 Apr 2012 13:39:44 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C665916@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C37@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: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34371C665916BL2PRD0410MB351_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 13:40:00 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34371C665916BL2PRD0410MB351_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The hope is to nail down the charter in the very near term and discuss any = objections on the mailing list. Ideally a decision on the WG would happen = sometime around the beginning of June so a WG meeting can get on the schedu= le for IETF 84 at the end of July. I'm new to the IETF, but my understandi= ng is that the final charter with all issues addressed needs to be submitte= d to the ADs 3-4 weeks before the final date that we need a decision. This= gives us about a month to work through any issues. Morteza, let me know i= f I am way off here. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lip= ton, Paul C Sent: Monday, April 09, 2012 9:30 PM To: Morteza Ansari (moransar); scim@ietf.org Subject: Re: [scim] Draft charter - v7 Thanks, Morteza. That was helpful. Any timeline at all to this, if I may as= k? Thanks again, Paul From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Monday, April 09, 2012 10:29 PM To: Lipton, Paul C; scim@ietf.org Subject: RE: Draft charter - v7 We had a BoF in Paris and are revising the proposed charter based on the di= scussions in the meeting. Once we settle on the text of the charter in the = mailing list we will ask the AD's/IESG to review and discuss it. If IESG de= cides to form a WG, then we are set and we move forward. Cheers, Morteza From: Lipton, Paul C [mailto:Paul.Lipton@ca.com] Sent: Monday, April 09, 2012 6:59 PM To: Morteza Ansari (moransar); scim@ietf.org Subject: RE: Draft charter - v7 Hi all, Could somebody please provide a brief summary of where SCIM now stands and = the proposed next steps / timeline? I think it would be very helpful to tho= se who could not attend the BoF. Thanks, Paul Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Morteza A= nsari (moransar) Sent: Monday, April 09, 2012 9:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 Hi folks, Here is the updated charter based on the discussions that took place in the= BoF meeting and some guidance from a hallway conversation with Pete after = the meeting. Please review the text and send your comments. Hopefully we c= an close this soon and hand it over to the ADs. Phil, I added a note regarding targeting extensions in the updated charter = given the email discussions. Cheers, Morteza --_000_56C3C758F9D6534CA3778EAA1E0C34371C665916BL2PRD0410MB351_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The hope is to nail do= wn the charter in the very near term and discuss any objections on the mail= ing list.  Ideally a decision on the WG would happen sometime around t= he beginning of June so a WG meeting can get on the schedule for IETF 84 at the end of July.  I’m new to= the IETF, but my understanding is that the final charter with all issues a= ddressed needs to be submitted to the ADs 3-4 weeks before the final date t= hat we need a decision.  This gives us about a month to work through any issues.  Morteza, let me know if I am way= off here.

 

--Kelly

 

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lipton, Paul C
Sent: Monday, April 09, 2012 9:30 PM
To: Morteza Ansari (moransar); scim@ietf.org
Subject: Re: [scim] Draft charter - v7

 

Thanks, Morteza. That was helpful. Any = timeline at all to this, if I may ask?

 

Thanks again,<= /span>

Paul

 

 

From: Morteza = Ansari (moransar) [mailto:moransar@ci= sco.com]
Sent: Monday, April 09, 2012 10:29 PM
To: Lipton, Paul C; scim@ietf.org
Subject: RE: Draft charter - v7

 

We had a BoF in Paris = and are revising the proposed charter based on the discussions in the meeti= ng. Once we settle on the text of the charter in the mailing list we will a= sk the AD’s/IESG to review and discuss it. If IESG decides to form a WG, then we are set and we move forward.

 

 

Cheers,

Morteza

 

 

Hi all,

 

Could somebody please provide a brief s= ummary of where SCIM now stands and the proposed next steps / timeline? I t= hink it would be very helpful to those who could not attend the BoF.

 

Thanks,=

Paul

 <= /p>

Paul Lipton

CA Technologies

VP, Industry Standards an= d Open Source

Member, CA Council for Te= chnical Excellence

Office Phone:= +1 609 583-9718

Mobile: += 1 267 987-6887

Email: paul.lipton@ca.com

 <= /p>

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar)
Sent: Monday, April 09, 2012 9:56 PM
To: scim@ietf.org
Subject: [scim] Draft charter - v7

 

Hi folks,

 

Here is the updated charter based on the discussions= that took place in the BoF meeting and some guidance from a hallway conver= sation with Pete after the meeting.  Please review the text and send y= our comments. Hopefully we can close this soon and hand it over to the ADs.

 

Phil, I added a note regarding targeting extensions = in the updated charter given the email discussions.

 

 

Cheers,

Morteza

--_000_56C3C758F9D6534CA3778EAA1E0C34371C665916BL2PRD0410MB351_-- From phil.hunt@oracle.com Tue Apr 10 07: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 9A06821F8685 for ; Tue, 10 Apr 2012 07:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.422 X-Spam-Level: X-Spam-Status: No, score=-9.422 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 X3B3MPypWxf4 for ; Tue, 10 Apr 2012 07:41:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A4AE121F8683 for ; Tue, 10 Apr 2012 07:41:28 -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 q3AEfNPF020557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 14:41:24 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 q3AEfN2o000492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 14:41:23 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 q3AEfMAP006681; Tue, 10 Apr 2012 09:41:22 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Apr 2012 07:41:22 -0700 References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> In-Reply-To: <4F83BF96.8040502@alcatel-lucent.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-531BD86C-5E89-453C-9063-0BFF381E9B7F Message-Id: X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Tue, 10 Apr 2012 07:41:53 -0700 To: "igor.faynberg@alcatel-lucent.com" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090202.4F844694.0127,ss=1,re=0.000,fgs=0 Cc: "scim@ietf.org" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 14:41:29 -0000 --Apple-Mail-531BD86C-5E89-453C-9063-0BFF381E9B7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think if SCIM only handles case of enterprise outsourcing, there will end u= p being a succeeding solution that covers all cases. Phil On 2012-04-09, at 22:05, Igor Faynberg wr= ote: > Yes, I agree that there are other use cases (and, yes, I agree that I did n= ot adress that argument). >=20 > Since "Cloud," at least in a narrow interpretation, is about enterprise o= utsourcing, a lot of things that relate to Cloud in general relate to en= terprise, too. Yet, the very character of SCIM, its RESTful intention inclu= ding , does point to the Cloud environment specifically. I think Phil in h= is previous message (which crossed with mine) implied just that. >=20 > And while on the subject of use cases... One danger in considering all app= licable use cases early in the game--and I do not necessarily mean the speci= fic case you brought up--is potential loss of focus. I believe you and I s= hare the same experience as former WG chairs: early attempts at generalizati= on bring feature crip, backward incompatibility, and a score of other proble= ms. I always tried to resist it. I really think that it is better to comp= lete something and then re-charter to move one to considering larger problem= s. =20 >=20 > =20 > Well, just as HTTP was being standardized, its many (unfortunate) uses bey= ond hyper-text transfer had already been considered. Everything could be tr= ansferred (and beyond firewalls, too!)--and everyone tried to transfer somet= hing new, ignoring the very nature of the protocol. But then one could arg= ue that HTTP should have been renamed into ETP... >=20 > In any event, as I said, I believe that the decision on changing the name= rests with the SCIM original authors; my opinion here is nothing more than a= n opinion (wrong perhaps). >=20 > Igor >=20 >=20 >=20 >=20 > On 4/9/2012 10:55 PM, Melinda Shore wrote: >>=20 >> On 4/9/12 6:49 PM, Igor Faynberg wrote:=20 >>> I tend to disagree with Melinda here (I mean on the name), as I don't=20= >>> see any actual evidence of the cloud thing in the IETF being "poisoned."= =20 >>> It certainly has been discussed for a long while; it is also tru= e that=20 >>> previous proposals had been criticized for being too broad. But the SCIM= =20 >>> proposal is *very focused.*=20 >>=20 >> I think the strongest argument for getting rid of the cloud reference=20 >> is one you didn't address, which is that there are use cases which are=20= >> substantially similar architecturally to what's been proposed but take=20= >> place inside an enterprise or other local-to-local environments.=20 >>=20 >> I'm not proposing any substantial changes to the architecture or=20 >> protocols to accommodate other use cases. I'm saying that there are=20 >> some already and that the current scope is narrower than it needs=20 >> to be. If there's a technical argument that "scim" has no applicability=20= >> to local provisioning, I think that's the argument to make.=20 >>=20 >> Melinda=20 >> _______________________________________________=20 >> scim mailing list=20 >> scim@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/scim=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-531BD86C-5E89-453C-9063-0BFF381E9B7F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I think if SCIM only handles case of enterprise outsourcing, there will end up being a succeeding solution that covers all cases.

Phil

On 2012-04-09, at 22:05, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:

Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument).

Since  "Cloud," at least in a narrow interpretation, is about enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too.  Yet, the very character of SCIM, its RESTful intention including , does  point to the Cloud environment specifically.   I think Phil in his previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus.   I believe  you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems.  I always tried to resist it.   I really think that it is better to complete something and then re-charter to move one to considering larger problems. 

 
Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered.  Everything could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol.  But then  one could argue that HTTP should have been renamed into ETP...

In any event, as I said, I  believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda Shore wrote:
On 4/9/12 6:49 PM, Igor Faynberg wrote:
I tend to disagree with Melinda here (I mean on the name), as I don't
see any actual evidence of the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
previous proposals had been criticized for being too broad. But the SCIM
proposal is *very focused.*

I think the strongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases which are
substantially similar architecturally to what's been proposed but take
place inside an enterprise or other local-to-local environments.

I'm not proposing any substantial changes to the architecture or
protocols to accommodate other use cases.  I'm saying that there are
some already and that the current scope is narrower than it needs
to be.  If there's a technical argument that "scim" has no applicability
to local provisioning, I think that's the argument to make.

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
--Apple-Mail-531BD86C-5E89-453C-9063-0BFF381E9B7F-- From stpeter@stpeter.im Tue Apr 10 08:07: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 C74A211E8105 for ; Tue, 10 Apr 2012 08:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 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 jS2y5c41bmUf for ; Tue, 10 Apr 2012 08:07:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1327111E80FA for ; Tue, 10 Apr 2012 08:07:07 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 986D94005B; Tue, 10 Apr 2012 09:20:54 -0600 (MDT) Message-ID: <4F8447D7.4050201@stpeter.im> Date: Tue, 10 Apr 2012 08:46:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eliot Lear References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> <4F834369.1000705@cisco.com> In-Reply-To: <4F834369.1000705@cisco.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Melinda Shore , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 15:07:08 -0000 On 4/9/12 2:15 PM, Eliot Lear wrote: > What Melinda and Phil said. From an IETF perspective the procedure is > *normally* that WG control is asserted at the point of adoption of WG > drafts. That having been said, if the drafts are mentioned in the > charter and the charter is approved, they should be relatively stable > during that period, IMHO. True. There might be a period during which the authors are updating both sets of documents, but hopefully the diffs are small. However, I see no harm in discussing these 1.0-specific bug fixes on the old list and keeping this list focused on chartering and related topics. If and when the WG gets formed, folks would expect all discussions to happen here. Peter -- Peter Saint-Andre https://stpeter.im/ From mphmmr@gmail.com Tue Apr 10 09:14: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 CA18A11E80CB for ; Tue, 10 Apr 2012 09:14:05 -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 X60lUGQQqFGk for ; Tue, 10 Apr 2012 09:14:04 -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 DA18D11E80BE for ; Tue, 10 Apr 2012 09:13:51 -0700 (PDT) Received: by lagj5 with SMTP id j5so3212437lag.31 for ; Tue, 10 Apr 2012 09:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iofVtotFExlpz2wYwTy92zKvegwZcKE/00VybX2BAvA=; b=XtNkOCOE+EoXl9Np1ba05rcObH7w2+BjSw9L4byOubOVzN+OCgRy6uJr5ySXI0RewA JqORKncl9OjSlIFwP4U8k7mP+W46bE48Bw95S/e5SY03wNp8q5+b26bx4kHL7Qfhx8w/ rarpLDLWUdrBCSTyi5seOaChmXxKZjFrteHAIFjv7nyDxJpSUHpJVaYxMSvF7oAy5yra DpLGXKe5v0Cy+M2oNgPDikcUwir9+8ja/IDJRMNnBP4Bl0xRYyfsHgJEkbErkaFffj8W c0CxAUAwiofFFq24++QgIYhitL3rdZMCbaRDG5LZzIxEcDnKhIZII5rJqTd5Ix6k344Y WXHg== MIME-Version: 1.0 Received: by 10.112.37.200 with SMTP id a8mr1525876lbk.23.1334074430814; Tue, 10 Apr 2012 09:13:50 -0700 (PDT) Received: by 10.112.85.129 with HTTP; Tue, 10 Apr 2012 09:13:50 -0700 (PDT) In-Reply-To: References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> Date: Tue, 10 Apr 2012 12:13:50 -0400 Message-ID: From: Michael Hammer To: Phil Hunt Content-Type: multipart/alternative; boundary=e0cb4efe2ed08d7c1104bd5568a2 Cc: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 16:14:05 -0000 --e0cb4efe2ed08d7c1104bd5568a2 Content-Type: text/plain; charset=ISO-8859-1 My understanding is that private Clouds are in Enterprises, so don't see the Cloud moniker limiting anyone. What it does do though is to give a hint that if you don't have interoperability, then you fall short of a key goal. How about less much ado about the name and get on with the work. Mike On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt wrote: > I think if SCIM only handles case of enterprise outsourcing, there will > end up being a succeeding solution that covers all cases. > > Phil > > On 2012-04-09, at 22:05, Igor Faynberg > wrote: > > Yes, I agree that there are other use cases (and, yes, I agree that I did > not adress that argument). > > Since "Cloud," at least in a narrow interpretation, is about enterprise > outsourcing, a lot of things that relate to Cloud in general relate to > enterprise, too. Yet, the very character of SCIM, its RESTful intention > including , does point to the Cloud environment specifically. I think > Phil in his previous message (which crossed with mine) implied just that. > > And while on the subject of use cases... One danger in considering all > applicable use cases early in the game--and I do not necessarily mean the > specific case you brought up--is potential loss of focus. I believe you > and I share the same experience as former WG chairs: early attempts at > generalization bring feature crip, backward incompatibility, and a score of > other problems. I always tried to resist it. I really think that it is > better to complete something and then re-charter to move one to considering > larger problems. > > > Well, just as HTTP was being standardized, its many (unfortunate) uses > beyond hyper-text transfer had already been considered. *Everything*could be transferred (and beyond firewalls, too!)--and everyone tried to > transfer something new, ignoring the very nature of the protocol. But > then one could argue that HTTP should have been renamed into ETP... > > In any event, as I said, I believe that the decision on changing the name > rests with the SCIM original authors; my opinion here is nothing more than > an opinion (wrong perhaps). > > Igor > > > > > On 4/9/2012 10:55 PM, Melinda Shore wrote: > > On 4/9/12 6:49 PM, Igor Faynberg wrote: > > I tend to disagree with Melinda here (I mean on the name), as I don't > see any actual evidence of the cloud thing in the IETF being "poisoned." > It certainly has been discussed for a long while; it is also true that > previous proposals had been criticized for being too broad. But the SCIM > proposal is *very focused.* > > > I think the strongest argument for getting rid of the cloud reference > is one you didn't address, which is that there are use cases which are > substantially similar architecturally to what's been proposed but take > place inside an enterprise or other local-to-local environments. > > I'm not proposing any substantial changes to the architecture or > protocols to accommodate other use cases. I'm saying that there are > some already and that the current scope is narrower than it needs > to be. If there's a technical argument that "scim" has no applicability > to local provisioning, I think that's the argument to make. > > 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 > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --e0cb4efe2ed08d7c1104bd5568a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My understanding is that private Clouds are in Enterprises, so don't se= e the Cloud moniker limiting anyone.
What it does do though is to give = a hint that if you don't have interoperability, then you fall short of = a key goal.
How about less much ado about the name and get on with the work.
=

Mike


On Tu= e, Apr 10, 2012 at 10:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I think if SCI= M only handles case of enterprise outsourcing, there will end up being a su= cceeding solution that covers all cases.

Phil

On 2012-04-09, at 22:05, Igor Faynberg= <= igor.faynberg@alcatel-lucent.com> wrote:

=20 =20 =20 =20 =20 Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument).

Since=A0 "Cloud," at least in a narrow interpretation, is abo= ut enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too.=A0 Yet, the very character of SCIM, its RESTful intention including , does=A0 point to the Cloud environment specifically.=A0=A0 I think Phil in his previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus. =A0 I believe=A0 you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems.=A0 I always tried to resist it. =A0 I really think that it is better to complete something and then re-charter to move one to considering larger problems.=A0

=A0
Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered.=A0 Ever= ything could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol.=A0 But then=A0 one could argue that HTTP should have been renamed into ETP...

In any event, as I said, I=A0 believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda Shore wrote:
On 4/9/12 6:49 PM, Igor Faynberg wrote:
I tend to disagree with Melinda here (I mean on the name), as I don't
see any actual evidence of the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
previous proposals had been criticized for being too broad. But the SCIM
proposal is *very focused.*

I think the strongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases whic= h are
substantially similar architecturally to what's been proposed but take
place inside an enterprise or other local-to-local environments.

I'm not proposing any substantial changes to the architecture or
protocols to accommodate other use cases.=A0 I'm saying that ther= e are
some already and that the current scope is narrower than it needs
to be.=A0 If there's a technical argument that "scim" h= as no applicability
to local provisioning, I think that's the argument to make.

Melinda
_______________________________________________
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

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


--e0cb4efe2ed08d7c1104bd5568a2-- From michael.brenner@alcatel-lucent.com Tue Apr 10 09:21: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 0DD5911E8113 for ; Tue, 10 Apr 2012 09:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.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 bwypf5c7SB2r for ; Tue, 10 Apr 2012 09:21:26 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E7CCC11E80EC for ; Tue, 10 Apr 2012 09:21:25 -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 q3AGLOKP019440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 11:21:24 -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 q3AGLOdo023298 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Apr 2012 11:21:24 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 10 Apr 2012 11:21:24 -0500 From: "Brenner, Michael Ralf (Michael)" To: Michael Hammer , Phil Hunt Date: Tue, 10 Apr 2012 11:21:22 -0500 Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0XNRXcaQGE4m69RHqM2lKze1Ot9QAANqBw Message-ID: <219947F0B2242843A0A1E62FDB510DC0250FFAB8B9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> In-Reply-To: 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_219947F0B2242843A0A1E62FDB510DC0250FFAB8B9USNAVSXCHMBSA_" 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: "Faynberg, Igor \(Igor\)" , "scim@ietf.org" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 16:21:28 -0000 --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB8B9USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Tuesday, April 10, 2012 12:14 PM To: Phil Hunt Cc: Faynberg, Igor (Igor); scim@ietf.org Subject: Re: [scim] Draft charter - v7 My understanding is that private Clouds are in Enterprises, so don't see th= e Cloud moniker limiting anyone. What it does do though is to give a hint that if you don't have interoperab= ility, then you fall short of a key goal. How about less much ado about the name and get on with the work. Mike On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt > wrote: I think if SCIM only handles case of enterprise outsourcing, there will end= up being a succeeding solution that covers all cases. Phil On 2012-04-09, at 22:05, Igor Faynberg > wrote: Yes, I agree that there are other use cases (and, yes, I agree that I did n= ot adress that argument). Since "Cloud," at least in a narrow interpretation, is about enterprise ou= tsourcing, a lot of things that relate to Cloud in general relate to enterp= rise, too. Yet, the very character of SCIM, its RESTful intention includin= g , does point to the Cloud environment specifically. I think Phil in hi= s previous message (which crossed with mine) implied just that. And while on the subject of use cases... One danger in considering all appl= icable use cases early in the game--and I do not necessarily mean the speci= fic case you brought up--is potential loss of focus. I believe you and I= share the same experience as former WG chairs: early attempts at generaliz= ation bring feature crip, backward incompatibility, and a score of other pr= oblems. I always tried to resist it. I really think that it is better to= complete something and then re-charter to move one to considering larger p= roblems. Well, just as HTTP was being standardized, its many (unfortunate) uses beyo= nd hyper-text transfer had already been considered. Everything could be tr= ansferred (and beyond firewalls, too!)--and everyone tried to transfer some= thing new, ignoring the very nature of the protocol. But then one could a= rgue that HTTP should have been renamed into ETP... In any event, as I said, I believe that the decision on changing the name = rests with the SCIM original authors; my opinion here is nothing more than = an opinion (wrong perhaps). Igor On 4/9/2012 10:55 PM, Melinda Shore wrote: On 4/9/12 6:49 PM, Igor Faynberg wrote: I tend to disagree with Melinda here (I mean on the name), as I don't see any actual evidence of the cloud thing in the IETF being "poisoned." It certainly has been discussed for a long while; it is also true that previous proposals had been criticized for being too broad. But the SCIM proposal is *very focused.* I think the strongest argument for getting rid of the cloud reference is one you didn't address, which is that there are use cases which are substantially similar architecturally to what's been proposed but take place inside an enterprise or other local-to-local environments. I'm not proposing any substantial changes to the architecture or protocols to accommodate other use cases. I'm saying that there are some already and that the current scope is narrower than it needs to be. If there's a technical argument that "scim" has no applicability to local provisioning, I think that's the argument to make. 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 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB8B9USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ie= tf.org] On Behalf Of Michael Hammer
Sent: Tuesday, April 1= 0, 2012 12:14 PM
To: Phil Hunt
Cc: Faynberg, Igor (Igor= ); scim@ietf.org
Subject: Re: [scim] Draft charter - v7

 

My understanding is that private Clouds are in Enterprises, so don't = see the Cloud moniker limiting anyone.

What it does do though is to give a hint that if you don't have interop= erability, then you fall short of a key goal.

How about less much ado about the name and get on with the= work.

 

<= /div>

Mike

 

On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I think if SCIM only handles case of enterpris= e outsourcing, there will end up being a succeeding solution that covers al= l cases.


Phil


On 2012-04-09, at 22:05, Igor Fay= nberg <igor.faynberg@alcatel-lucent.com> wrote:

Yes, I agree that there are other use cases (and, yes, I agree that= I did not adress that argument).

Since  "Cloud," at = least in a narrow interpretation, is about enterprise outsourcing, a lot of= things that relate to Cloud in general relate to enterprise, too.  Ye= t, the very character of SCIM, its RESTful intention including , does = point to the Cloud environment specifically.   I think Phil in h= is previous message (which crossed with mine) implied just that.

And= while on the subject of use cases... One danger in considering all applica= ble use cases early in the game--and I do not necessarily mean the specific= case you brought up--is potential loss of focus.   I believe  yo= u and I share the same experience as former WG chairs: early attempts at ge= neralization bring feature crip, backward incompatibility, and a score of o= ther problems.  I always tried to resist it.   I really think tha= t it is better to complete something and then re-charter to move one to con= sidering larger problems. 

 
Well, just as HTTP was be= ing standardized, its many (unfortunate) uses beyond hyper-text transfer ha= d already been considered.  Everything could be transferred (an= d beyond firewalls, too!)--and everyone tried to transfer something new, ig= noring the very nature of the protocol.  But then  one could argu= e that HTTP should have been renamed into ETP...

In any event, as I = said, I  believe that the decision on changing the name rests with the= SCIM original authors; my opinion here is nothing more than an opinion (wr= ong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda = Shore wrote:

On 4/9/12 6:49 PM, Igor Fa= ynberg wrote:

I tend to disagre= e with Melinda here (I mean on the name), as I don't
see any actual evi= dence of the cloud thing in the IETF being "poisoned."
It cer= tainly has been discussed for a long while; it is also true that
previo= us proposals had been criticized for being too broad. But the SCIM
prop= osal is *very focused.*


I think the= strongest argument for getting rid of the cloud reference
is one you d= idn't address, which is that there are use cases which are
substantiall= y similar architecturally to what's been proposed but take
place inside= an enterprise or other local-to-local environments.

I'm not propos= ing any substantial changes to the architecture or
protocols to accommo= date other use cases.  I'm saying that there are
some already and = that the current scope is narrower than it needs
to be.  If there'= s a technical argument that "scim" has no applicability
to lo= cal provisioning, I think that's the argument to make.

Melinda
= _______________________________________________
scim mailing list
<= a href=3D"mailto:scim@ietf.org" target=3D"_blank">scim@ietf.org
https= ://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailin= g list
scim@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/scim


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

 

= --_000_219947F0B2242843A0A1E62FDB510DC0250FFAB8B9USNAVSXCHMBSA_-- From ggolovinsky@qualys.com Tue Apr 10 09:22: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 BDE6D11E80F0 for ; Tue, 10 Apr 2012 09:22:20 -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 jEyYeoE03azE for ; Tue, 10 Apr 2012 09:22:19 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2318611E80EC for ; Tue, 10 Apr 2012 09:22:19 -0700 (PDT) Received: by qaea16 with SMTP id a16so117758qae.10 for ; Tue, 10 Apr 2012 09:22:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=5nY3aE6OcFn8b9zOLl6c3ljePIkRRdBMI5XmP0Rte8M=; b=Q2idFE14YGZTmd+HZmQasBJm/9F3h8dBjcZBAur2JqIsiyTAWRckobQ/meDEfvt38X ImQiczK8pWPpUsM3/KgC7g/QLYbdPdqHk6yZDsztN42NbjgOZVUtNtilAqCPeGlN5KWu 1ZKsKLukQCI5953q3AqjKhA9iMHd1WlZNK6rN2yWTxs4pj7GOUkGpeokz5hCtJR1anOG zxyDgO8HtC3DdTKwfOINgCRSSOFkzlrktfX7MbmpBJ4GsX3YCpjCfYaw+YYNMHDthFwe bjjwDIlsQw3iasue6FG31420vTh6goO4rklvz+Oo8yD6tf9v4vLsZymxOAdDReToeQit 6aNA== Received: by 10.224.95.205 with SMTP id e13mr15340427qan.30.1334074938613; Tue, 10 Apr 2012 09:22:18 -0700 (PDT) From: Gene Golovinsky References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> <219947F0B2242843A0A1E62FDB510DC0250FFAB8B9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <219947F0B2242843A0A1E62FDB510DC0250FFAB8B9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXNUyzb2PNHvU38ap+vewV4Mw5YAJM1IKJAximbkYB4mQRzgGmols1AoVJlxcCLVl7+AJnxsvwlf+6MaA= Date: Tue, 10 Apr 2012 09:22:17 -0700 Message-ID: <25a235f74bde0b45d67b813f4458b0bd@mail.gmail.com> To: "Brenner, Michael Ralf (Michael)" , Michael Hammer , Phil Hunt Content-Type: multipart/alternative; boundary=20cf3074b2f8d1dfa804bd558638 X-Gm-Message-State: ALoCoQnWj6ujKgtrqWF0YhFfqwWI9KcprVf7Fk8LUDMfYIa2xjOz2VQ7YRWO/+rUGcl6iRJSmHGW Cc: "Faynberg, Igor \(Igor\)" , scim@ietf.org Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 16:22:20 -0000 --20cf3074b2f8d1dfa804bd558638 Content-Type: text/plain; charset=ISO-8859-1 +1 *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf Of *Brenner, Michael Ralf (Michael) *Sent:* Tuesday, April 10, 2012 09:21 AM *To:* Michael Hammer; Phil Hunt *Cc:* Faynberg, Igor (Igor); scim@ietf.org *Subject:* Re: [scim] Draft charter - v7 +1 *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, April 10, 2012 12:14 PM *To:* Phil Hunt *Cc:* Faynberg, Igor (Igor); scim@ietf.org *Subject:* Re: [scim] Draft charter - v7 My understanding is that private Clouds are in Enterprises, so don't see the Cloud moniker limiting anyone. What it does do though is to give a hint that if you don't have interoperability, then you fall short of a key goal. How about less much ado about the name and get on with the work. Mike On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt wrote: I think if SCIM only handles case of enterprise outsourcing, there will end up being a succeeding solution that covers all cases. Phil On 2012-04-09, at 22:05, Igor Faynberg wrote: Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument). Since "Cloud," at least in a narrow interpretation, is about enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too. Yet, the very character of SCIM, its RESTful intention including , does point to the Cloud environment specifically. I think Phil in his previous message (which crossed with mine) implied just that. And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus. I believe you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems. I always tried to resist it. I really think that it is better to complete something and then re-charter to move one to considering larger problems. Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered. *Everything* could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol. But then one could argue that HTTP should have been renamed into ETP... In any event, as I said, I believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps). Igor On 4/9/2012 10:55 PM, Melinda Shore wrote: On 4/9/12 6:49 PM, Igor Faynberg wrote: I tend to disagree with Melinda here (I mean on the name), as I don't see any actual evidence of the cloud thing in the IETF being "poisoned." It certainly has been discussed for a long while; it is also true that previous proposals had been criticized for being too broad. But the SCIM proposal is *very focused.* I think the strongest argument for getting rid of the cloud reference is one you didn't address, which is that there are use cases which are substantially similar architecturally to what's been proposed but take place inside an enterprise or other local-to-local environments. I'm not proposing any substantial changes to the architecture or protocols to accommodate other use cases. I'm saying that there are some already and that the current scope is narrower than it needs to be. If there's a technical argument that "scim" has no applicability to local provisioning, I think that's the argument to make. 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 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --20cf3074b2f8d1dfa804bd558638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1=

=A0

=A0

From: scim-bounces@ietf.org [m= ailto:scim-bounces@ietf.org] <= b>On Behalf Of Brenner, Michael Ralf (Michael)
Sent: Tuesday, April 10, 2012 09:21 AM
To: Michael Hammer;= Phil Hunt
Cc: Faynberg, Igor (Igor); scim@ietf.org
Subject: Re: [scim] Draft charter - v7

=A0

+1

=A0

=A0

My understanding is th= at private Clouds are in Enterprises, so don't see the Cloud moniker li= miting anyone.

What it does do though is to = give a hint that if you don't have interoperability, then you fall shor= t of a key goal.

How about less much ado about the name an= d get on with the work.

=A0

<= div>

Mike

=A0

On Tue, Apr 10, 2012 at 10:41 AM, Phil H= unt <phil.hunt@oracle.com>= ; wrote:

I think if SCIM only handles c= ase of enterprise outsourcing, there will end up being a succeeding solutio= n that covers all cases.


Phil


On 2012-04-09, at 22:05, Igor Faynberg <igor.faynberg@alcatel-luc= ent.com> wrote:

Yes, I agree that there are other use cases (and, yes, I = agree that I did not adress that argument).

Since=A0 "Cloud,&qu= ot; at least in a narrow interpretation, is about enterprise outsourcing, a= lot of things that relate to Cloud in general relate to enterprise, too.= =A0 Yet, the very character of SCIM, its RESTful intention including , does= =A0 point to the Cloud environment specifically.=A0=A0 I think Phil in his = previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all = applicable use cases early in the game--and I do not necessarily mean the s= pecific case you brought up--is potential loss of focus. =A0 I believe=A0 y= ou and I share the same experience as former WG chairs: early attempts at g= eneralization bring feature crip, backward incompatibility, and a score of = other problems.=A0 I always tried to resist it. =A0 I really think that it = is better to complete something and then re-charter to move one to consider= ing larger problems.=A0

=A0
Well, just as HTTP was being standardized, its many (unfortunate= ) uses beyond hyper-text transfer had already been considered.=A0 Everyt= hing could be transferred (and beyond firewalls, too!)--and everyone tr= ied to transfer something new, ignoring the very nature of the protocol.=A0= But then=A0 one could argue that HTTP should have been renamed into ETP...=

In any event, as I said, I=A0 believe that the decision on changing the= name rests with the SCIM original authors; my opinion here is nothing more= than an opinion (wrong perhaps).

Igor




On 4/9/201= 2 10:55 PM, Melinda Shore wrote:

On 4/9/12 6:49 PM, Ig= or Faynberg wrote:

I tend to disagree with Melin= da here (I mean on the name), as I don't
see any actual evidence of= the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
= previous proposals had been criticized for being too broad. But the SCIM proposal is *very focused.*


I think the st= rongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases which are =
substantially similar architecturally to what's been proposed but t= ake
place inside an enterprise or other local-to-local environments.
I'm not proposing any substantial changes to the architecture or protocols to accommodate other use cases.=A0 I'm saying that there ar= e
some already and that the current scope is narrower than it needs to be.=A0 If there's a technical argument that "scim" has no = applicability
to local provisioning, I think that's the argument to= make.

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

=

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


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

=A0

--20cf3074b2f8d1dfa804bd558638-- From phil.hunt@oracle.com Tue Apr 10 09: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 0A83611E8113 for ; Tue, 10 Apr 2012 09:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.385 X-Spam-Level: X-Spam-Status: No, score=-9.385 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 cJqIfuzboJrB for ; Tue, 10 Apr 2012 09:22:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id AAB1111E8115 for ; Tue, 10 Apr 2012 09:22:37 -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 q3AGMN3m026495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 16:22:24 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 q3AGMMkI002154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 16:22:23 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3AGMMVJ000470; Tue, 10 Apr 2012 11:22:22 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Apr 2012 09:22:22 -0700 References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6582F641-9BA7-4D89-9686-CBAAAE433A2A Message-Id: <1A8FD6E5-83C8-4B2E-9C1C-6DD0B4BFCDF2@oracle.com> X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Tue, 10 Apr 2012 09:22:57 -0700 To: Michael Hammer X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4F845E40.0081,ss=1,re=-2.300,fgs=0 Cc: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 16:22:39 -0000 --Apple-Mail-6582F641-9BA7-4D89-9686-CBAAAE433A2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I haven't commented about name - and have no opinion.=20 My issue is whether SCIM is to be a provisioning protocol or restful dap whi= ch can be used by provisioning systems. =20 Phil On 2012-04-10, at 9:13, Michael Hammer wrote: > My understanding is that private Clouds are in Enterprises, so don't see t= he Cloud moniker limiting anyone. > What it does do though is to give a hint that if you don't have interopera= bility, then you fall short of a key goal. > How about less much ado about the name and get on with the work. >=20 > Mike >=20 >=20 > On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt wrote: > I think if SCIM only handles case of enterprise outsourcing, there will en= d up being a succeeding solution that covers all cases. >=20 > Phil >=20 > On 2012-04-09, at 22:05, Igor Faynberg w= rote: >=20 >> Yes, I agree that there are other use cases (and, yes, I agree that I did= not adress that argument). >>=20 >> Since "Cloud," at least in a narrow interpretation, is about enterprise o= utsourcing, a lot of things that relate to Cloud in general relate to enterp= rise, too. Yet, the very character of SCIM, its RESTful intention including= , does point to the Cloud environment specifically. I think Phil in his p= revious message (which crossed with mine) implied just that. >>=20 >> And while on the subject of use cases... One danger in considering al= l applicable use cases early in the game--and I do not necessarily mean t= he specific case you brought up--is potential loss of focus. I believe yo= u and I share the same experience as former WG chairs: early attempts at gen= eralization bring feature crip, backward incompatibility, and a score of oth= er problems. I always tried to resist it. I really think that it is bette= r to complete something and then re-charter to move one to considering large= r problems. =20 >>=20 >> =20 >> Well, just as HTTP was being standardized, its many (unfortunate) uses be= yond hyper-text transfer had already been considered. Everything could be t= ransferred (and beyond firewalls, too!)--and everyone tried to transfer some= thing new, ignoring the very nature of the protocol. But then one could ar= gue that HTTP should have been renamed into ETP... >>=20 >> In any event, as I said, I believe that the decision on changing the nam= e rests with the SCIM original authors; my opinion here is nothing more than= an opinion (wrong perhaps). >>=20 >> Igor >>=20 >>=20 >>=20 >>=20 >> On 4/9/2012 10:55 PM, Melinda Shore wrote: >>>=20 >>> On 4/9/12 6:49 PM, Igor Faynberg wrote:=20 >>>> I tend to disagree with Melinda here (I mean on the name), as I don't=20= >>>> see any actual evidence of the cloud thing in the IETF being "poisoned.= "=20 >>>> It certainly has been discussed for a long while; it is also true that=20= >>>> previous proposals had been criticized for being too broad. But the SCI= M=20 >>>> proposal is *very focused.*=20 >>>=20 >>> I think the strongest argument for getting rid of the cloud reference=20= >>> is one you didn't address, which is that there are use cases which = are=20 >>> substantially similar architecturally to what's been proposed but take=20= >>> place inside an enterprise or other local-to-local environments. =20= >>>=20 >>> I'm not proposing any substantial changes to the architecture or=20 >>> protocols to accommodate other use cases. I'm saying that there are=20 >>> some already and that the current scope is narrower than it needs=20 >>> to be. If there's a technical argument that "scim" has no applicability= =20 >>> to local provisioning, I think that's the argument to make.=20 >>>=20 >>> Melinda=20 >>> _______________________________________________=20 >>> scim mailing list=20 >>> scim@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/scim=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-6582F641-9BA7-4D89-9686-CBAAAE433A2A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I haven't commented about name - and have no opinion. 

My issue is whether SCIM is to be a provisioning protocol or restful dap which can be used by provisioning systems.  

Phil

On 2012-04-10, at 9:13, Michael Hammer <mphmmr@gmail.com> wrote:

My understanding is that private Clouds are in Enterprises, so don't see the Cloud moniker limiting anyone.
What it does do though is to give a hint that if you don't have interoperability, then you fall short of a key goal.
How about less much ado about the name and get on with the work.

Mike


On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I think if SCIM only handles case of enterprise outsourcing, there will end up being a succeeding solution that covers all cases.

Phil

On 2012-04-09, at 22:05, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:

Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument).

Since  "Cloud," at least in a narrow interpretation, is about enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too.  Yet, the very character of SCIM, its RESTful intention including , does  point to the Cloud environment specifically.   I think Phil in his previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus.   I believe  you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems.  I always tried to resist it.   I really think that it is better to complete something and then re-charter to move one to considering larger problems. 

 
Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered.  Everything could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol.  But then  one could argue that HTTP should have been renamed into ETP...

In any event, as I said, I  believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda Shore wrote:
On 4/9/12 6:49 PM, Igor Faynberg wrote:
I tend to disagree with Melinda here (I mean on the name), as I don't
see any actual evidence of the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
previous proposals had been criticized for being too broad. But the SCIM
proposal is *very focused.*

I think the strongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases which are
substantially similar architecturally to what's been proposed but take
place inside an enterprise or other local-to-local environments.

I'm not proposing any substantial changes to the architecture or
protocols to accommodate other use cases.  I'm saying that there are
some already and that the current scope is narrower than it needs
to be.  If there's a technical argument that "scim" has no applicability
to local provisioning, I think that's the argument to make.

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

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


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--Apple-Mail-6582F641-9BA7-4D89-9686-CBAAAE433A2A-- From melinda.shore@gmail.com Tue Apr 10 09:56: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 82F8121F8688 for ; Tue, 10 Apr 2012 09:56: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 rbOu1CuQMeaQ for ; Tue, 10 Apr 2012 09:56:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC321F8680 for ; Tue, 10 Apr 2012 09:56:22 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so188376pbb.31 for ; Tue, 10 Apr 2012 09:56: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=20zJz/FigpBGGkJc65GqeaO1XWnDEng44SJCdKpHJO0=; b=0tanUkZwO13uvkQO90bRsDYFWs34uBsnQ5Ujeb2ifC5EdhVy/sd6wQHtvNcdwlQYYv YpV6CH3vwRWrhry9QlQVYpZ55KPq5FnohMAc/BGBoTLf9+15tqn+9Zye6PBaYWTVazsq vUVsOzNYhxPV39i9CfMUQExHLJ1jCzukrg+i4ch4MWno8AHY618lHvi0SD1EJ3ORh3nC pZDh4AH0sQ7omKW0/yXkFVAjQG3er/dPBkYDK7F/T727yIgJcqqHQlYYckzCVc4EDQS8 MYA07XnVmJNmwySbu1PCTyJM9uiTKNRSQCt5kLXxHa5kDDAB1nZKacQ65hTQmVW2TgMC sSMA== Received: by 10.68.211.36 with SMTP id mz4mr18088444pbc.150.1334076981861; Tue, 10 Apr 2012 09:56:21 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id d6sm333361pbi.23.2012.04.10.09.56.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 09:56:20 -0700 (PDT) Message-ID: <4F846631.9010508@gmail.com> Date: Tue, 10 Apr 2012 08:56:17 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 16:56:22 -0000 On 4/10/12 8:13 AM, Michael Hammer wrote: > My understanding is that private Clouds are in Enterprises, Now I *truly* regret having said anything. My primary concern is that the design not be overly constraining. I chaired a working group that made some poor decisions and ended up overgeneralizing the result so I'm certainly sensitive to the question of making something overly broad. However, what I'm saying here is that what's already written down covers more use cases than you think, including the *common* use case of provisioning local accounts out of an ERP, and my concern is with protecting that. [Do people really think there aren't RESTful services running inside large enterprises?] Melinda From hasini@wso2.com Tue Apr 10 14:26: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 9E13911E8103 for ; Tue, 10 Apr 2012 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVjzCyJI3jAX for ; Tue, 10 Apr 2012 14:26:20 -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 42BDB11E809D for ; Tue, 10 Apr 2012 14:26:20 -0700 (PDT) Received: by yhkk25 with SMTP id k25so199911yhk.31 for ; Tue, 10 Apr 2012 14:26: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HEfFN2WbkeXdQW2ezT5PSUrGyil+rjS2w7+uEdGTk3I=; b=AWmhkV2qlPRVIFRR/9TLQ95UF6Mjp2MH8m8HNhE0gf58WslXX7KkbfI/v7HJOEH61y rda4jnUNh1TAN9X7xVx5MRPeHrBX+4JAph8/toABvo1szInhA4ho4BfWbHnlZLnXUMHw KX4GU6MG+80GCRt+RYx82lY7J3bESczuKzFZt/yEF90FVuoTl0hVOqeNj4ZazFOlFtpu GNxf9xir6qLY3fiY00eqd3YCJkFi6OZOktSb8VWwaUBqxHtiXPlIeaI2uKK8lvq7mVJU 5rtJHYFSAlYuyU37kLVtUc2v2DO9ICBw7dyWmC1953xyvJ8KoSDfKxqXL6x9qJO2taRj Sm2w== MIME-Version: 1.0 Received: by 10.60.0.226 with SMTP id 2mr18219809oeh.18.1334093179536; Tue, 10 Apr 2012 14:26:19 -0700 (PDT) Received: by 10.182.186.102 with HTTP; Tue, 10 Apr 2012 14:26:19 -0700 (PDT) In-Reply-To: <1A8FD6E5-83C8-4B2E-9C1C-6DD0B4BFCDF2@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <4F83974F.40302@gmail.com> <4F839F9D.4080506@alcatel-lucent.com> <4F83A11C.9010900@gmail.com> <4F83BF96.8040502@alcatel-lucent.com> <1A8FD6E5-83C8-4B2E-9C1C-6DD0B4BFCDF2@oracle.com> Date: Wed, 11 Apr 2012 02:56:19 +0530 Message-ID: From: Hasini Gunasinghe To: Phil Hunt Content-Type: multipart/alternative; boundary=e89a8fb1fbc610432c04bd59c6e3 X-Gm-Message-State: ALoCoQlgcSKB8hDUNj8DhfmWGKsYQrz0D7r5lZ3wYUSIqiu5djU57Ehn3rzT2C8JZ3cE6sHn8LDU Cc: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" , Michael Hammer Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2012 21:26:21 -0000 --e89a8fb1fbc610432c04bd59c6e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 9:52 PM, Phil Hunt wrote: > I haven't commented about name - and have no opinion. > > My issue is whether SCIM is to be a provisioning protocol or restful dap > which can be used by provisioning systems. > SCIM is a provisioning protocol which defines a RESTful API - for user/identity management operations - that is exposed by the SCIM service provider and consumed by the SCIM consumer. Both SCIM service provider and SCIM consumer can be parts of an identity provisioning system. This is my understanding on SCIM - in the point of view of one who implements it in an identity management solution. > > > Phil > > On 2012-04-10, at 9:13, Michael Hammer wrote: > > My understanding is that private Clouds are in Enterprises, so don't see > the Cloud moniker limiting anyone. > > +1. Usage of SCIM is not limited only to enterprise - public cloud provisioning use cases. IMHO, It can be used as the standard protocol in any identity provisioning use case as long as both parties understand SCIM. Thanks, Hasini. > What it does do though is to give a hint that if you don't have > interoperability, then you fall short of a key goal. > How about less much ado about the name and get on with the work. > > Mike > > > On Tue, Apr 10, 2012 at 10:41 AM, Phil Hunt wrote: > >> I think if SCIM only handles case of enterprise outsourcing, there will >> end up being a succeeding solution that covers all cases. >> >> Phil >> >> On 2012-04-09, at 22:05, Igor Faynberg >> wrote: >> >> Yes, I agree that there are other use cases (and, yes, I agree that I did >> not adress that argument). >> >> Since "Cloud," at least in a narrow interpretation, is about enterprise >> outsourcing, a lot of things that relate to Cloud in general relate to >> enterprise, too. Yet, the very character of SCIM, its RESTful intention >> including , does point to the Cloud environment specifically. I think >> Phil in his previous message (which crossed with mine) implied just that. >> >> And while on the subject of use cases... One danger in considering all >> applicable use cases early in the game--and I do not necessarily mean the >> specific case you brought up--is potential loss of focus. I believe you >> and I share the same experience as former WG chairs: early attempts at >> generalization bring feature crip, backward incompatibility, and a score of >> other problems. I always tried to resist it. I really think that it is >> better to complete something and then re-charter to move one to considering >> larger problems. >> >> >> Well, just as HTTP was being standardized, its many (unfortunate) uses >> beyond hyper-text transfer had already been considered. *Everything*could be transferred (and beyond firewalls, too!)--and everyone tried to >> transfer something new, ignoring the very nature of the protocol. But >> then one could argue that HTTP should have been renamed into ETP... >> >> In any event, as I said, I believe that the decision on changing the >> name rests with the SCIM original authors; my opinion here is nothing more >> than an opinion (wrong perhaps). >> >> Igor >> >> >> >> >> On 4/9/2012 10:55 PM, Melinda Shore wrote: >> >> On 4/9/12 6:49 PM, Igor Faynberg wrote: >> >> I tend to disagree with Melinda here (I mean on the name), as I don't >> see any actual evidence of the cloud thing in the IETF being "poisoned." >> It certainly has been discussed for a long while; it is also true that >> previous proposals had been criticized for being too broad. But the SCIM >> proposal is *very focused.* >> >> >> I think the strongest argument for getting rid of the cloud reference >> is one you didn't address, which is that there are use cases which are >> substantially similar architecturally to what's been proposed but take >> place inside an enterprise or other local-to-local environments. >> >> I'm not proposing any substantial changes to the architecture or >> protocols to accommodate other use cases. I'm saying that there are >> some already and that the current scope is narrower than it needs >> to be. If there's a technical argument that "scim" has no applicability >> to local provisioning, I think that's the argument to make. >> >> 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 >> >> >> _______________________________________________ >> 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 > > --e89a8fb1fbc610432c04bd59c6e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 9:52 PM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
I haven't commented about name - and have= no opinion.=A0

My issue is whether SCIM is to be = a provisioning protocol or restful dap which can be used by provisioning sy= stems.

SCIM is a provisioning protocol which defines a= RESTful API - for user/identity management operations - that is exposed by= the SCIM service provider and consumed by the SCIM consumer. Both SCIM ser= vice provider and SCIM consumer can be parts of an identity provisioning sy= stem.

This is my understanding on SCIM - in the point of view of one who impl= ements it in an identity management solution.
=A0

Phil

On 2012-04-10, at 9:13, Michael Hammer= <mphmmr@gmail.com= > wrote:

My understanding is tha= t private Clouds are in Enterprises, so don't see the Cloud moniker lim= iting anyone.
+1. Usa= ge of SCIM is not limited only to enterprise - public cloud provisioning us= e cases. IMHO, It can be used as the standard protocol in any identity prov= isioning use case as long as both parties understand SCIM.

Thanks,
Hasini.
What it does do though is to give a hint that if you don't ha= ve interoperability, then you fall short of a key goal.
How about less much ado about the name and get on with the work.
=

Mike


On Tu= e, Apr 10, 2012 at 10:41 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I think if SCI= M only handles case of enterprise outsourcing, there will end up being a su= cceeding solution that covers all cases.

Phil

On 2012-04-09, at 22:05, Igor Faynberg <igor.faynberg@alcatel-lucent.c= om> wrote:

=20 =20 =20 =20 =20 Yes, I agree that there are other use cases (and, yes, I agree that I did not adress that argument).

Since=A0 "Cloud," at least in a narrow interpretation, is abo= ut enterprise outsourcing, a lot of things that relate to Cloud in general relate to enterprise, too.=A0 Yet, the very character of SCIM, its RESTful intention including , does=A0 point to the Cloud environment specifically.=A0=A0 I think Phil in his previous message (which crossed with mine) implied just that.

And while on the subject of use cases... One danger in considering all applicable use cases early in the game--and I do not necessarily mean the specific case you brought up--is potential loss of focus. =A0 I believe=A0 you and I share the same experience as former WG chairs: early attempts at generalization bring feature crip, backward incompatibility, and a score of other problems.=A0 I always tried to resist it. =A0 I really think that it is better to complete something and then re-charter to move one to considering larger problems.=A0

=A0
Well, just as HTTP was being standardized, its many (unfortunate) uses beyond hyper-text transfer had already been considered.=A0 Ever= ything could be transferred (and beyond firewalls, too!)--and everyone tried to transfer something new, ignoring the very nature of the protocol.=A0 But then=A0 one could argue that HTTP should have been renamed into ETP...

In any event, as I said, I=A0 believe that the decision on changing the name rests with the SCIM original authors; my opinion here is nothing more than an opinion (wrong perhaps).

Igor




On 4/9/2012 10:55 PM, Melinda Shore wrote:
On 4/9/12 6:49 PM, Igor Faynberg wrote:
I tend to disagree with Melinda here (I mean on the name), as I don't
see any actual evidence of the cloud thing in the IETF being "poisoned."
It certainly has been discussed for a long while; it is also true that
previous proposals had been criticized for being too broad. But the SCIM
proposal is *very focused.*

I think the strongest argument for getting rid of the cloud reference
is one you didn't address, which is that there are use cases whic= h are
substantially similar architecturally to what's been proposed but take
place inside an enterprise or other local-to-local environments.

I'm not proposing any substantial changes to the architecture or
protocols to accommodate other use cases.=A0 I'm saying that ther= e are
some already and that the current scope is narrower than it needs
to be.=A0 If there's a technical argument that "scim" h= as no applicability
to local provisioning, I think that's the argument to make.

Melinda
_______________________________________________
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

_______________________________________________<= br> 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

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


--e89a8fb1fbc610432c04bd59c6e3-- From hasini@wso2.com Tue Apr 10 21:48: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 A127C21F85BB for ; Tue, 10 Apr 2012 21:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3EII0Q8XZDa for ; Tue, 10 Apr 2012 21:48:46 -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 6E73B21F85B6 for ; Tue, 10 Apr 2012 21:48:46 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so823834obb.31 for ; Tue, 10 Apr 2012 21:48:46 -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=62hV8E//tZ2ufyD89bOOYBU3ESVeWKwFWM3TG1RBvc0=; b=V1SI1aEmTEQDZxMqzy9BenefNIgvyzCO9XkYjW3v65WL2+Uv4PI1MkEP8XNEluTRLe FXN3zBWcdgU9tca+ve8uRaGuaQbQ3MzQgAUGTF7hdr2nQvn4d2b7QEEH+PjX8AAZO1B0 aXUSpXJXVKPhkiD2hEMcERQvP44YTvf08/T8+sV11NNL076bc2z1l2bWFulpv6UDnphT Rx8HC9hudISagcGIse4oL2peasQLyGDinOX1FtgoA8BhtKNlArQnLjRkvz01cyFWP1LB DbXcc9OxLTeBCSp1c7RZW982/FFUUvUdWTAFIV42uZ445Wa7cBUYjx1R712UvzVP2tuC t3AA== MIME-Version: 1.0 Received: by 10.182.114.70 with SMTP id je6mr20034213obb.30.1334119725796; Tue, 10 Apr 2012 21:48:45 -0700 (PDT) Received: by 10.182.158.33 with HTTP; Tue, 10 Apr 2012 21:48:45 -0700 (PDT) In-Reply-To: <4F8447D7.4050201@stpeter.im> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> <4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im> Date: Wed, 11 Apr 2012 10:18:45 +0530 Message-ID: From: Hasini Gunasinghe To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=f46d0444746b580d4004bd5ff48c X-Gm-Message-State: ALoCoQnOfHcai7daiT+1y9K0HlkHDifFCl0HAHm+y/jRNMyawG45TIDAhwt3s3/SgybQyYj50YZv Cc: "scim@ietf.org" , Melinda Shore , Eliot Lear , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2012 04:48:48 -0000 --f46d0444746b580d4004bd5ff48c Content-Type: text/plain; charset=ISO-8859-1 Hi all, May I know what the conclusion of this discussion is? I have few suggestions to make for the improvement of couple of points in the spec, based on the experience at the SCIM interop event. I'd prefer to discuss them on ietf mailing list itself, since IMO - it will be easy to track the discussions on the changes made to the spec after SCIM 1.0 is submitted to IETF. Having said that, I would like to bring your attention regarding an issue tracker as in [1] . I am new to IETF and I guess it is created only after the WG is formed at IETF. If that is the case, it will be easier to continue reporting/fixing issues related to the spec in the Cloud-Drectory WG since an issue tracker [2] has been maintained there already. [1] http://tools.ietf.org/wg/trackers [2] http://code.google.com/p/scim/issues/list Thanks, Hasini. On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre wrote: > On 4/9/12 2:15 PM, Eliot Lear wrote: > > What Melinda and Phil said. From an IETF perspective the procedure is > > *normally* that WG control is asserted at the point of adoption of WG > > drafts. That having been said, if the drafts are mentioned in the > > charter and the charter is approved, they should be relatively stable > > during that period, IMHO. > > True. There might be a period during which the authors are updating both > sets of documents, but hopefully the diffs are small. However, I see no > harm in discussing these 1.0-specific bug fixes on the old list and > keeping this list focused on chartering and related topics. If and when > the WG gets formed, folks would expect all discussions to happen here. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --f46d0444746b580d4004bd5ff48c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

May I know what the conclusion of this discussion is?
I h= ave few suggestions to make for the improvement of couple of points in the = spec, based on the experience at the SCIM interop event.

I'd pre= fer to discuss them on ietf mailing list itself, since IMO - it will be eas= y to track the discussions on the changes made to the spec after SCIM 1.0 i= s submitted to IETF.

Having said that, I would like to bring your attention regarding an iss= ue tracker as in [1] . I am new to IETF and I guess it is created only aft= er the WG is formed at IETF. If that is the case, it will be easier to cont= inue reporting/fixing issues related to the spec in the Cloud-Drectory WG s= ince an issue tracker [2] has been maintained there already.

[1] htt= p://tools.ietf.org/wg/trackers
[2] http://code.google.com/p/scim/issues= /list

Thanks,
Hasini.


On Tue, Apr 10= , 2012 at 8:16 PM, Peter Saint-Andre <stpeter@stpeter.im> w= rote:
On 4/9/12 2:15 PM, Eliot Lear wrote:
> What Melinda and Phil said. =A0From an IETF perspective the procedure = is
> *normally* that WG control is asserted at the point of adoption = of WG
> drafts. =A0That having been said, if the drafts are mentioned in = the
> charter and the charter is approved, they should be relatively stable<= br> > during that period, IMHO.

True. There might be a period during which the authors are updating b= oth
sets of documents, but hopefully the diffs are small. However, I see no
harm in discussing these 1.0-specific bug fixes on the old list and
keeping this list focused on chartering and related topics. If and when
the WG gets formed, folks would expect all discussions to happen here.

Peter

--
Peter Saint-Andre
https://stpeter.im/


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

--f46d0444746b580d4004bd5ff48c-- From stpeter@stpeter.im Wed Apr 11 09:14:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0880011E8074 for ; Wed, 11 Apr 2012 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 kDdpA9PuZ7+e for ; Wed, 11 Apr 2012 09:14:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7417321F855A for ; Wed, 11 Apr 2012 09:14:06 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 300E040075; Wed, 11 Apr 2012 10:27:57 -0600 (MDT) Message-ID: <4F85A6FF.80006@stpeter.im> Date: Wed, 11 Apr 2012 09:45:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hasini Gunasinghe References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> <4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Melinda Shore , Eliot Lear , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2012 16:14:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the interim, I think it would be best to keep discussing SCIM 1.0 on the existing cloud-directory list and to keep using the issue tracker at code.google.com. If and when a working group is formed at the IETF, folks can transition tracking and discussion to IETF venues. Peter On 4/10/12 10:48 PM, Hasini Gunasinghe wrote: > Hi all, > > May I know what the conclusion of this discussion is? I have few > suggestions to make for the improvement of couple of points in the > spec, based on the experience at the SCIM interop event. > > I'd prefer to discuss them on ietf mailing list itself, since IMO - > it will be easy to track the discussions on the changes made to the > spec after SCIM 1.0 is submitted to IETF. > > Having said that, I would like to bring your attention regarding > an issue tracker as in [1] . I am new to IETF and I guess it is > created only after the WG is formed at IETF. If that is the case, > it will be easier to continue reporting/fixing issues related to > the spec in the Cloud-Drectory WG since an issue tracker [2] has > been maintained there already. > > [1] http://tools.ietf.org/wg/trackers [2] > http://code.google.com/p/scim/issues/list > > Thanks, Hasini. > > > On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre > > wrote: > > On 4/9/12 2:15 PM, Eliot Lear wrote: >> What Melinda and Phil said. From an IETF perspective the >> procedure is *normally* that WG control is asserted at the point >> of adoption of WG drafts. That having been said, if the drafts >> are mentioned in the charter and the charter is approved, they >> should be relatively stable during that period, IMHO. > > True. There might be a period during which the authors are updating > both sets of documents, but hopefully the diffs are small. However, > I see no harm in discussing these 1.0-specific bug fixes on the old > list and keeping this list focused on chartering and related > topics. If and when the WG gets formed, folks would expect all > discussions to happen here. > > Peter > > -- Peter Saint-Andre https://stpeter.im/ > > > _______________________________________________ scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Fpv8ACgkQNL8k5A2w/vx6MACeOJUKUoh4ZU0EbR/qXoTeg5Nu 0o8AoJxHJzSQJLVzrFm7VyB9v6DXw9U8 =Gu2K -----END PGP SIGNATURE----- From kelly.grizzle@sailpoint.com Wed Apr 11 10:55: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 9E67A11E808D for ; Wed, 11 Apr 2012 10:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 5MatGbh8PnY7 for ; Wed, 11 Apr 2012 10:55:00 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 255E011E8089 for ; Wed, 11 Apr 2012 10:54:59 -0700 (PDT) Received: from mail43-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 17:54:58 +0000 Received: from mail43-am1 (localhost [127.0.0.1]) by mail43-am1-R.bigfish.com (Postfix) with ESMTP id 8D5313A022E; Wed, 11 Apr 2012 17:54:58 +0000 (UTC) X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail43-am1: 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=BL2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail43-am1 (localhost.localdomain [127.0.0.1]) by mail43-am1 (MessageSwitch) id 1334166896542969_29218; Wed, 11 Apr 2012 17:54:56 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.234]) by mail43-am1.bigfish.com (Postfix) with ESMTP id 782A1180067; Wed, 11 Apr 2012 17:54:56 +0000 (UTC) Received: from BL2PRD0410HT005.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 17:54:55 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.2.203]) by BL2PRD0410HT005.namprd04.prod.outlook.com ([10.255.99.40]) with mapi id 14.16.0143.004; Wed, 11 Apr 2012 17:54:53 +0000 From: Kelly Grizzle To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1ABg+a/Q Date: Wed, 11 Apr 2012 17:54:53 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C666141@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.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: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34371C666141BL2PRD0410MB351_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2012 17:55:01 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34371C666141BL2PRD0410MB351_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks great, Morteza! I found one extraneous comma: This group will consider, the operational experience gathered from the exis= ting work... ^ Here Other than that I wouldn't change a thing. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mor= teza Ansari (moransar) Sent: Monday, April 09, 2012 8:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 Hi folks, Here is the updated charter based on the discussions that took place in the= BoF meeting and some guidance from a hallway conversation with Pete after = the meeting. Please review the text and send your comments. Hopefully we c= an close this soon and hand it over to the ADs. Phil, I added a note regarding targeting extensions in the updated charter = given the email discussions. Cheers, Morteza --_000_56C3C758F9D6534CA3778EAA1E0C34371C666141BL2PRD0410MB351_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks great, Morteza!&= nbsp; I found one extraneous comma:

 

This group will consider, the operational ex= perience gathered from the existing work...

       &n= bsp;            = ;    ^ Here

 

Other than that I woul= dn’t change a thing.

 

--Kelly

 

 

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, April 09, 2012 8:56 PM
To: scim@ietf.org
Subject: [scim] Draft charter - v7

 

Hi folks,

 

Here is the updated charter based on the discussions= that took place in the BoF meeting and some guidance from a hallway conver= sation with Pete after the meeting.  Please review the text and send y= our comments. Hopefully we can close this soon and hand it over to the ADs.

 

Phil, I added a note regarding targeting extensions = in the updated charter given the email discussions.

 

 

Cheers,

Morteza

--_000_56C3C758F9D6534CA3778EAA1E0C34371C666141BL2PRD0410MB351_-- From stpeter@stpeter.im Wed Apr 11 16:10:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055D11E8105 for ; Wed, 11 Apr 2012 16:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 PpyQsWB5eGsy for ; Wed, 11 Apr 2012 16:10:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 436F811E8102 for ; Wed, 11 Apr 2012 16:09:59 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C73D40058; Wed, 11 Apr 2012 17:23:51 -0600 (MDT) Message-ID: <4F860F46.9010208@stpeter.im> Date: Wed, 11 Apr 2012 17:09:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hasini Gunasinghe References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> <4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im> <4F85A6FF.80006@stpeter.im> In-Reply-To: <4F85A6FF.80006@stpeter.im> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Melinda Shore , Eliot Lear , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2012 23:10:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems that I did not make it clear, on this list, that I sent this message with no hats on. Ever since the end of my term during IETF 83, I am no longer serving in the role of an Area Director at the IETF, so everything I have said since then was strictly as an individual. On 4/11/12 9:45 AM, Peter Saint-Andre wrote: > In the interim, I think it would be best to keep discussing SCIM > 1.0 on the existing cloud-directory list and to keep using the > issue tracker at code.google.com. If and when a working group is > formed at the IETF, folks can transition tracking and discussion to > IETF venues. > > Peter > > On 4/10/12 10:48 PM, Hasini Gunasinghe wrote: >> Hi all, > >> May I know what the conclusion of this discussion is? I have few >> suggestions to make for the improvement of couple of points in >> the spec, based on the experience at the SCIM interop event. > >> I'd prefer to discuss them on ietf mailing list itself, since IMO >> - it will be easy to track the discussions on the changes made to >> the spec after SCIM 1.0 is submitted to IETF. > >> Having said that, I would like to bring your attention regarding >> an issue tracker as in [1] . I am new to IETF and I guess it is >> created only after the WG is formed at IETF. If that is the >> case, it will be easier to continue reporting/fixing issues >> related to the spec in the Cloud-Drectory WG since an issue >> tracker [2] has been maintained there already. > >> [1] http://tools.ietf.org/wg/trackers [2] >> http://code.google.com/p/scim/issues/list > >> Thanks, Hasini. > > >> On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre >> > wrote: > >> On 4/9/12 2:15 PM, Eliot Lear wrote: >>> What Melinda and Phil said. From an IETF perspective the >>> procedure is *normally* that WG control is asserted at the >>> point of adoption of WG drafts. That having been said, if the >>> drafts are mentioned in the charter and the charter is >>> approved, they should be relatively stable during that period, >>> IMHO. > >> True. There might be a period during which the authors are >> updating both sets of documents, but hopefully the diffs are >> small. However, I see no harm in discussing these 1.0-specific >> bug fixes on the old list and keeping this list focused on >> chartering and related topics. If and when the WG gets formed, >> folks would expect all discussions to happen here. > >> Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+GD0YACgkQNL8k5A2w/vxuiACgtPnddpWjOsOkqE2Z7Nowmy9g K+QAn1NRDzz1Z7ZMbemqobIHSNwKz0Ur =JuQB -----END PGP SIGNATURE----- From phil.hunt@oracle.com Wed Apr 11 16:10: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 4403B11E810C for ; Wed, 11 Apr 2012 16:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 W4BV1NlrXwR3 for ; Wed, 11 Apr 2012 16:10:17 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF211E8105 for ; Wed, 11 Apr 2012 16:10:17 -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 q3BNAEHU001970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 23:10:14 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3BNADiv003330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 23:10:13 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3BNADBO007200; Wed, 11 Apr 2012 18:10:13 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Apr 2012 16:10:12 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4F85A6FF.80006@stpeter.im> Date: Wed, 11 Apr 2012 16:10:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com> <4F833D26.4000105@gmail.com> <69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com> <4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im> <4F85A6FF.80006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-CT-RefId: str=0001.0A090205.4F860F57.004A,ss=1,re=0.000,fgs=0 Cc: Hasini Gunasinghe , Melinda Shore , Eliot Lear , "scim@ietf.org" Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2012 23:10:18 -0000 -1 I don't believe the current draft needs to be perfect in order to agree = upon a charter. It only needs to be in good shape for last call -- and = we are a long way off from that! I'd be worried about trying to keep the IETF and Google group specs in = sync. Why attempt that? There is also the note well concerns previously mentioned. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-11, at 8:45 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In the interim, I think it would be best to keep discussing SCIM 1.0 > on the existing cloud-directory list and to keep using the issue > tracker at code.google.com. If and when a working group is formed at > the IETF, folks can transition tracking and discussion to IETF venues. >=20 > Peter >=20 > On 4/10/12 10:48 PM, Hasini Gunasinghe wrote: >> Hi all, >>=20 >> May I know what the conclusion of this discussion is? I have few >> suggestions to make for the improvement of couple of points in the >> spec, based on the experience at the SCIM interop event. >>=20 >> I'd prefer to discuss them on ietf mailing list itself, since IMO - >> it will be easy to track the discussions on the changes made to the >> spec after SCIM 1.0 is submitted to IETF. >>=20 >> Having said that, I would like to bring your attention regarding >> an issue tracker as in [1] . I am new to IETF and I guess it is >> created only after the WG is formed at IETF. If that is the case, >> it will be easier to continue reporting/fixing issues related to >> the spec in the Cloud-Drectory WG since an issue tracker [2] has >> been maintained there already. >>=20 >> [1] http://tools.ietf.org/wg/trackers [2] >> http://code.google.com/p/scim/issues/list >>=20 >> Thanks, Hasini. >>=20 >>=20 >> On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre >> > wrote: >>=20 >> On 4/9/12 2:15 PM, Eliot Lear wrote: >>> What Melinda and Phil said. =46rom an IETF perspective the >>> procedure is *normally* that WG control is asserted at the point >>> of adoption of WG drafts. That having been said, if the drafts >>> are mentioned in the charter and the charter is approved, they >>> should be relatively stable during that period, IMHO. >>=20 >> True. There might be a period during which the authors are updating >> both sets of documents, but hopefully the diffs are small. However, >> I see no harm in discussing these 1.0-specific bug fixes on the old >> list and keeping this list focused on chartering and related >> topics. If and when the WG gets formed, folks would expect all >> discussions to happen here. >>=20 >> Peter >>=20 >> -- Peter Saint-Andre https://stpeter.im/ >>=20 >>=20 >> _______________________________________________ scim mailing list=20 >> scim@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/scim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk+Fpv8ACgkQNL8k5A2w/vx6MACeOJUKUoh4ZU0EbR/qXoTeg5Nu > 0o8AoJxHJzSQJLVzrFm7VyB9v6DXw9U8 > =3DGu2K > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From moransar@cisco.com Wed Apr 11 21:44: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 4ACDF11E80CE for ; Wed, 11 Apr 2012 21:44:01 -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 SQhKX60F1cXH for ; Wed, 11 Apr 2012 21:44:00 -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 1A65911E80B5 for ; Wed, 11 Apr 2012 21:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=4513; q=dns/txt; s=iport; t=1334205840; x=1335415440; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=x0tqTz17wFp7Uzup8k28ZzQp1/qBkkH7h4//ur/dcPQ=; b=hcp5K77Fu0dI3MfxEANh8/gncqaTTKmBbsgJTw9lh/bAj3+i6Ig8+JTd YmG6aM5JEQp4J60fqehljbDCjY181Q0Ql5hcfIc9+ulFxwMgkuBqWlSdM 5mZCohwLGAeTXY4wAVOREgnQ0DseOcmn+PP6/AFdTfJOpBKEzVObfyTj/ A=; X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208";a="73818399" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 12 Apr 2012 04:43:59 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3C4hxFU012716; Thu, 12 Apr 2012 04:43:59 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); Wed, 11 Apr 2012 23:43:59 -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, 11 Apr 2012 23:43:58 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4AF@XMB-RCD-313.cisco.com> In-Reply-To: <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Question for ADs: bug fixes to 1.0 spec? Thread-Index: Ac0YOEUZotu2aCfGSdO/Zeszl917SwALgvOQ References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com><4F833D26.4000105@gmail.com><69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com><4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im><4F85A6FF.80006@stpeter.im> <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> From: "Morteza Ansari (moransar)" To: "Phil Hunt" , "Peter Saint-Andre" X-OriginalArrivalTime: 12 Apr 2012 04:43:59.0361 (UTC) FILETIME=[E05E2710:01CD1866] Cc: Hasini Gunasinghe , Melinda Shore , Eliot Lear , scim@ietf.org Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 04:44:01 -0000 This is not about having a perfect starting point. It is about fixing the bugs in the 1.0 spec quickly (within weeks not months/years) to solve some of the interoperability issues discovered while testing 1.0 spec. This will result in a better starting point for IETF WG, but is independent of it. For the record I don't have a strong opinion which is why I brought the question up, but it seems it is easier to continue with existing model and communication mechanisms to wrap up these open issues while we are exploring ideas for 1.next under IETF umbrella and trying to get a WG formed. Cheers, Morteza -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, April 11, 2012 4:10 PM To: Peter Saint-Andre Cc: Hasini Gunasinghe; Melinda Shore; Eliot Lear; scim@ietf.org Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? -1 I don't believe the current draft needs to be perfect in order to agree upon a charter. It only needs to be in good shape for last call -- and we are a long way off from that! I'd be worried about trying to keep the IETF and Google group specs in sync. Why attempt that? There is also the note well concerns previously mentioned. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-11, at 8:45 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In the interim, I think it would be best to keep discussing SCIM 1.0=20 > on the existing cloud-directory list and to keep using the issue=20 > tracker at code.google.com. If and when a working group is formed at=20 > the IETF, folks can transition tracking and discussion to IETF venues. >=20 > Peter >=20 > On 4/10/12 10:48 PM, Hasini Gunasinghe wrote: >> Hi all, >>=20 >> May I know what the conclusion of this discussion is? I have few=20 >> suggestions to make for the improvement of couple of points in the=20 >> spec, based on the experience at the SCIM interop event. >>=20 >> I'd prefer to discuss them on ietf mailing list itself, since IMO -=20 >> it will be easy to track the discussions on the changes made to the=20 >> spec after SCIM 1.0 is submitted to IETF. >>=20 >> Having said that, I would like to bring your attention regarding an=20 >> issue tracker as in [1] . I am new to IETF and I guess it is created=20 >> only after the WG is formed at IETF. If that is the case, it will be=20 >> easier to continue reporting/fixing issues related to the spec in the >> Cloud-Drectory WG since an issue tracker [2] has been maintained=20 >> there already. >>=20 >> [1] http://tools.ietf.org/wg/trackers [2]=20 >> http://code.google.com/p/scim/issues/list >>=20 >> Thanks, Hasini. >>=20 >>=20 >> On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre=20 >> > wrote: >>=20 >> On 4/9/12 2:15 PM, Eliot Lear wrote: >>> What Melinda and Phil said. From an IETF perspective the procedure=20 >>> is *normally* that WG control is asserted at the point of adoption=20 >>> of WG drafts. That having been said, if the drafts are mentioned in >>> the charter and the charter is approved, they should be relatively=20 >>> stable during that period, IMHO. >>=20 >> True. There might be a period during which the authors are updating=20 >> both sets of documents, but hopefully the diffs are small. However, I >> see no harm in discussing these 1.0-specific bug fixes on the old=20 >> list and keeping this list focused on chartering and related topics.=20 >> If and when the WG gets formed, folks would expect all discussions to >> happen here. >>=20 >> Peter >>=20 >> -- Peter Saint-Andre https://stpeter.im/ >>=20 >>=20 >> _______________________________________________ scim mailing list=20 >> scim@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/scim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk+Fpv8ACgkQNL8k5A2w/vx6MACeOJUKUoh4ZU0EbR/qXoTeg5Nu > 0o8AoJxHJzSQJLVzrFm7VyB9v6DXw9U8 > =3DGu2K > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From moransar@cisco.com Wed Apr 11 22:10:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B855821F852C for ; Wed, 11 Apr 2012 22:10:49 -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 9sv6fdWdtRj9 for ; Wed, 11 Apr 2012 22:10:47 -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 63CD421F852B for ; Wed, 11 Apr 2012 22:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=10964; q=dns/txt; s=iport; t=1334207447; x=1335417047; h=mime-version:subject:date:message-id:from:to; bh=7UQ8gd5kBPWiyQmF4dSUya8THST9Kn3owIjwQ4mqhNg=; b=DdPt2e8uIvO7X1d8m0/ZdvrdWVE+JuFj+b15jk5uL2+JlZeYU7NyQ+uu JUs9rP79juD7Xk7dRpMHa+aOxU8cZtStncz/+BOOOtfzZocM2xZ7MBGvG A3q5L162nRnos18a+PYhGWR4Gc5fIL2oWP9iVDkAF6jdpl2v+kAaO4spk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABNjhk+tJXG8/2dsb2JhbAA7CYJGtx+BB4IJAQEBBBIBCREDWwEIEQQBAQsGFwEHRQkJAQQTCBqHbJk3gSigC4smhXBjBIham1+BaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208,217";a="74003600" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 12 Apr 2012 05:10:47 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q3C5AkoR017115 for ; Thu, 12 Apr 2012 05:10:46 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); Thu, 12 Apr 2012 00:10:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD186A.9E38BB18" Date: Thu, 12 Apr 2012 00:10:45 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AB309bw From: "Morteza Ansari (moransar)" To: X-OriginalArrivalTime: 12 Apr 2012 05:10:46.0391 (UTC) FILETIME=[9E3B7870:01CD186A] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 05:10:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD186A.9E38BB18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lots of interesting discussions on the thread. I am trying to figure out what edits I should make to the latest charter to address concerns/issues raised. Summarizing the thread it seems there were two major points discussed. =20 Name of the protocol/WG I personally think there is significant value in the existing implementations of 1.0 and traction the whole effort has had and renaming it would be a poor decision. With that said, it sounds like most folks either don't care or interested in keeping the name the same. If someone strongly objects to this or has concerns please raise it. =20 Actual scope of work There were a lot of discussions on whether SCIM is solving a cloud use case or addressing enterprise provisioning case as well. The problem I am having is that the discussion is mainly around high level semantics of cloud vs. enterprise. =20 Melinda, I fully agree that overgeneralizing the problem is just as bad as boiling the ocean, however we need to come up with specific use cases that we think should be included in the charter and problem statement. The charter actually says: =20 "The Simple Cloud Identity Management (SCIM) specification will be designed to simplify user identity management in services and applications by defining standard protocols and schemas for creating, reading/searching, modifying, and deleting user identities and identity-related objects across administrative domains." =20 Note that it says "services" and "applications". In my view enterprise identity provisioning use cases fall under the application part of this statement. Does anyone have a specific use case that you think should be addressed by SCIM that given the current charter wording is excluded? =20 =20 Cheers, Morteza =20 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Monday, April 09, 2012 6:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 =20 Hi folks, =20 Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting. Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs. =20 Phil, I added a note regarding targeting extensions in the updated charter given the email discussions. =20 =20 Cheers, Morteza ------_=_NextPart_001_01CD186A.9E38BB18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lots of interesting discussions on the thread. I = am trying to figure out what edits I should make to the latest charter = to address concerns/issues raised.  Summarizing the thread it seems = there were two major points discussed.

 

Name of the = protocol/WG

I personally think there is significant value in = the existing implementations of 1.0 and traction the whole effort has = had and renaming it would be a poor decision.  With that said, it = sounds like most folks either don’t care or interested in keeping = the name the same. If someone strongly objects to this or has concerns = please raise it.

 

Actual scope of = work

There were a lot of = discussions on whether SCIM is solving a cloud use case or addressing = enterprise provisioning case as well.  The problem I am having is = that the discussion is mainly around high level semantics of cloud vs. = enterprise.

 

Melinda, I fully agree = that overgeneralizing the problem is just as bad as boiling the ocean, = however we need to come up with specific use cases that we think should = be included in the charter and problem statement. The charter actually = says:

 

“The Simple Cloud = Identity Management (SCIM) specification will be designed to simplify = user identity management in services and applications by defining = standard protocols and schemas for creating, reading/searching, = modifying, and deleting user identities and identity-related objects = across administrative domains.”

 

Note that it says = “services” and “applications”.  In my view = enterprise identity provisioning use cases fall under the application = part of this statement. Does anyone have a specific use case that you = think should be addressed by SCIM that given the current charter wording = is excluded?

 

 

Cheers,

Morteza

 

From:= = scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of = Morteza Ansari (moransar)
Sent: Monday, April 09, 2012 = 6:56 PM
To: scim@ietf.org
Subject: [scim] Draft = charter - v7

 

Hi = folks,

 

Here is the updated charter based on the discussions = that took place in the BoF meeting and some guidance from a hallway = conversation with Pete after the meeting.  Please review the text = and send your comments. Hopefully we can close this soon and hand it = over to the ADs.

 

Phil, I = added a note regarding targeting extensions in the updated charter given = the email discussions.

 

 

Cheers,

Morteza

------_=_NextPart_001_01CD186A.9E38BB18-- From moransar@cisco.com Wed Apr 11 22:11: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 C93F921F852D for ; Wed, 11 Apr 2012 22:11:26 -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 HvOcKnwGMuYy for ; Wed, 11 Apr 2012 22:11:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B57E821F852C for ; Wed, 11 Apr 2012 22:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=7606; q=dns/txt; s=iport; t=1334207484; x=1335417084; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=uu/RmF25d4J3kX9XC9sXJlC3DHfkYCZmmHuAHTP/MFc=; b=eMp1ZKnHjLJxUgXb8cPmxPReffLZenrL3n/vS36X44YSqso2QcUoCVC4 n2qUZXwbF+MoNlAomG99FolozQkeLTt3orACuNthf44UZ1dyMdeKFBdzq aM6ym6/rmyCRqSjrBHC7CpsaHk4zNgDUTNjGntaJEoFETY6gOmH2eaZfp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGpjhk+tJV2Z/2dsb2JhbABEgka3H4EHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHbJpfoAuRFmMEiFqbX4FpgwWBPg X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208,217";a="74051228" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 12 Apr 2012 05:11:16 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3C5BGD4006383; Thu, 12 Apr 2012 05:11:16 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, 12 Apr 2012 00:11:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD186A.AFE871CD" Date: Thu, 12 Apr 2012 00:11:15 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C5@XMB-RCD-313.cisco.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C666141@BL2PRD0410MB351.namprd04.prod.outlook.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1ABg+a/QABefcEA= References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C5C2C@XMB-RCD-313.cisco.com> <56C3C758F9D6534CA3778EAA1E0C34371C666141@BL2PRD0410MB351.namprd04.prod.outlook.com> From: "Morteza Ansari (moransar)" To: "Kelly Grizzle" , X-OriginalArrivalTime: 12 Apr 2012 05:11:16.0319 (UTC) FILETIME=[B0121EF0:01CD186A] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 05:11:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD186A.AFE871CD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Kelly, I fixed this. =20 =20 Cheers, Morteza =20 From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 Sent: Wednesday, April 11, 2012 10:55 AM To: Morteza Ansari (moransar); scim@ietf.org Subject: RE: Draft charter - v7 =20 Looks great, Morteza! I found one extraneous comma: =20 This group will consider, the operational experience gathered from the existing work... ^ Here =20 Other than that I wouldn't change a thing. =20 --Kelly =20 =20 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Monday, April 09, 2012 8:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 =20 Hi folks, =20 Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting. Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs. =20 Phil, I added a note regarding targeting extensions in the updated charter given the email discussions. =20 =20 Cheers, Morteza ------_=_NextPart_001_01CD186A.AFE871CD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Kelly, I fixed = this.

 

 

Cheers,

Morteza

 

From:= = Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: = Wednesday, April 11, 2012 10:55 AM
To: Morteza Ansari = (moransar); scim@ietf.org
Subject: RE: Draft charter - = v7

 

Looks great, Morteza!  I found one = extraneous comma:

 

This group will consider, the operational experience = gathered from the existing work...

         = ;            =    ^ Here

 

Other than that I = wouldn’t change a thing.

 

--Kelly

 

 

From:= = scim-bounces@ietf.org [mailto:scim-bounces@ietf.= org] On Behalf Of Morteza Ansari (moransar)
Sent: = Monday, April 09, 2012 8:56 PM
To: scim@ietf.org
Subject: = [scim] Draft charter - v7

 

Hi = folks,

 

Here is the updated charter based on the discussions = that took place in the BoF meeting and some guidance from a hallway = conversation with Pete after the meeting.  Please review the text = and send your comments. Hopefully we can close this soon and hand it = over to the ADs.

 

Phil, I = added a note regarding targeting extensions in the updated charter given = the email discussions.

 

 

Cheers,

Morteza

------_=_NextPart_001_01CD186A.AFE871CD-- From moransar@cisco.com Wed Apr 11 22:12: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 2123D21F854D for ; Wed, 11 Apr 2012 22:12: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 0zeiYyf0xg2f for ; Wed, 11 Apr 2012 22:12:29 -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 D3A5721F852C for ; Wed, 11 Apr 2012 22:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11259; q=dns/txt; s=iport; t=1334207546; x=1335417146; h=mime-version:subject:date:message-id:from:to; bh=cp1nj69uQUrJWIin7UL1ja0Dpx9pc4whWKUDJpFhhuU=; b=fRqmNiQEggrKqzWIGee1T+6mEoPdP3Tp6hsDbiW0NbGYxq+oepLlp2aV KxgtraZaxvDxCgaHUgxgElq7wscOtiZU2M4XO98eHvwY5AaqdgieOcNbb va3Dv25PUjb+2s+B5YkMh7DUd1tgSx852nPpjGwj66o0By9gc2vYxn3Mi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOljhk+tJXG+/2dsb2JhbAA7CYJGtx+BB4IJAQEBBBIBCREDWwEIEQQBAQsGFwEHRQkJAQQTCBqHbJk3gSigC4smhXBjBIham1+BaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,408,1330905600"; d="scan'208,217";a="71016491" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Apr 2012 05:12:26 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3C5CP6m020542 for ; Thu, 12 Apr 2012 05:12:26 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, 12 Apr 2012 00:12:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD186A.D9808F1B" Date: Thu, 12 Apr 2012 00:12:25 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C7@XMB-RCD-313.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AB309bwAADKo3A= From: "Morteza Ansari (moransar)" To: X-OriginalArrivalTime: 12 Apr 2012 05:12:25.0930 (UTC) FILETIME=[D98FEAA0:01CD186A] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 05:12:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD186A.D9808F1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, if I missed any other comments beyond these two please let me know. =20 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Wednesday, April 11, 2012 10:11 PM To: scim@ietf.org Subject: Re: [scim] Draft charter - v7 =20 Lots of interesting discussions on the thread. I am trying to figure out what edits I should make to the latest charter to address concerns/issues raised. Summarizing the thread it seems there were two major points discussed. =20 Name of the protocol/WG I personally think there is significant value in the existing implementations of 1.0 and traction the whole effort has had and renaming it would be a poor decision. With that said, it sounds like most folks either don't care or interested in keeping the name the same. If someone strongly objects to this or has concerns please raise it. =20 Actual scope of work There were a lot of discussions on whether SCIM is solving a cloud use case or addressing enterprise provisioning case as well. The problem I am having is that the discussion is mainly around high level semantics of cloud vs. enterprise. =20 Melinda, I fully agree that overgeneralizing the problem is just as bad as boiling the ocean, however we need to come up with specific use cases that we think should be included in the charter and problem statement. The charter actually says: =20 "The Simple Cloud Identity Management (SCIM) specification will be designed to simplify user identity management in services and applications by defining standard protocols and schemas for creating, reading/searching, modifying, and deleting user identities and identity-related objects across administrative domains." =20 Note that it says "services" and "applications". In my view enterprise identity provisioning use cases fall under the application part of this statement. Does anyone have a specific use case that you think should be addressed by SCIM that given the current charter wording is excluded? =20 =20 Cheers, Morteza =20 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Monday, April 09, 2012 6:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 =20 Hi folks, =20 Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting. Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs. =20 Phil, I added a note regarding targeting extensions in the updated charter given the email discussions. =20 =20 Cheers, Morteza ------_=_NextPart_001_01CD186A.D9808F1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also, if I missed any other comments beyond = these two please let me know.

 

From:= = scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of = Morteza Ansari (moransar)
Sent: Wednesday, April 11, 2012 = 10:11 PM
To: scim@ietf.org
Subject: Re: [scim] Draft = charter - v7

 

Lots of interesting discussions on the thread. I = am trying to figure out what edits I should make to the latest charter = to address concerns/issues raised.  Summarizing the thread it seems = there were two major points discussed.

 

Name of the = protocol/WG

I personally think there is significant value in = the existing implementations of 1.0 and traction the whole effort has = had and renaming it would be a poor decision.  With that said, it = sounds like most folks either don’t care or interested in keeping = the name the same. If someone strongly objects to this or has concerns = please raise it.

 

Actual scope of = work

There were a lot of = discussions on whether SCIM is solving a cloud use case or addressing = enterprise provisioning case as well.  The problem I am having is = that the discussion is mainly around high level semantics of cloud vs. = enterprise.

 

Melinda, I fully agree = that overgeneralizing the problem is just as bad as boiling the ocean, = however we need to come up with specific use cases that we think should = be included in the charter and problem statement. The charter actually = says:

 

“The Simple Cloud = Identity Management (SCIM) specification will be designed to simplify = user identity management in services and applications by defining = standard protocols and schemas for creating, reading/searching, = modifying, and deleting user identities and identity-related objects = across administrative domains.”

 

Note that it says = “services” and “applications”.  In my view = enterprise identity provisioning use cases fall under the application = part of this statement. Does anyone have a specific use case that you = think should be addressed by SCIM that given the current charter wording = is excluded?

 

 

Cheers,

Morteza

 

From:= = scim-bounces@ietf.org [mailto:scim-bounces@ietf.= org] On Behalf Of Morteza Ansari (moransar)
Sent: = Monday, April 09, 2012 6:56 PM
To: scim@ietf.org
Subject: = [scim] Draft charter - v7

 

Hi = folks,

 

Here is the updated charter based on the discussions = that took place in the BoF meeting and some guidance from a hallway = conversation with Pete after the meeting.  Please review the text = and send your comments. Hopefully we can close this soon and hand it = over to the ADs.

 

Phil, I = added a note regarding targeting extensions in the updated charter given = the email discussions.

 

 

Cheers,

Morteza

------_=_NextPart_001_01CD186A.D9808F1B-- From melinda.shore@gmail.com Wed Apr 11 22:30: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 4239421F84B4 for ; Wed, 11 Apr 2012 22:30: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=[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 q3vbI9gQwL7J for ; Wed, 11 Apr 2012 22:30:25 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id B287621F84B2 for ; Wed, 11 Apr 2012 22:30:25 -0700 (PDT) Received: by dady13 with SMTP id y13so2791149dad.27 for ; Wed, 11 Apr 2012 22:30:25 -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=a49ha5dizKu5F8KGDruT7Ti9JnPIWz2SnDge1Ed3v/8=; b=c8F6Y6oeMwMkpt5Iu/Qceskv6IYBvs9R/L9XZtXnb4AGZTDKljf+J1sAhmKPz+JRxm 33ofebo9OhWUtAKtb1IKib+5ouH2SdlJ4PTt+plhYMbrntCnU6q2ISVDMS4hw+wzdOCF WGj41VMZWgV9lPkfP3zoEFXdKCmqm1XLDaXA4xLgv8eVL1GLLLS0/w+Rf1UrEk35CIww hG28CYUS+GvJ1kHTV9M0e5DplaxZ98E4njDZvIEWVaA+o7LA9IKv4fLF4sUK2tpox2zo 9i9jhLE/rWSxYZ3Swr/gqd8BUF7YRRRLvIONbkWPLytfFMfEEF030nwXk9MlBaMSQRm0 HtkA== Received: by 10.68.218.137 with SMTP id pg9mr355245pbc.26.1334208625453; Wed, 11 Apr 2012 22:30:25 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id pv10sm1888013pbc.4.2012.04.11.22.30.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 22:30:24 -0700 (PDT) Message-ID: <4F86686D.8010609@gmail.com> Date: Wed, 11 Apr 2012 21:30:21 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 05:30:26 -0000 On 4/11/12 9:10 PM, Morteza Ansari (moransar) wrote: > Note that it says “services” and “applications”. In my view enterprise > identity provisioning use cases fall under the application part of this > statement. Does anyone have a specific use case that you think should be > addressed by SCIM that given the current charter wording is excluded? Actually, I think the issue may be more around "across adminmistrative domains," although 1) I think that can be addressed in the security considerations (and eventually mechanisms), and 2) implementers are going to do what they're going to do, anyway, and being fussy about anything other than protocol details tends to have a poor return on investment, as tempting as it is. Melinda From wmills@yahoo-inc.com Wed Apr 11 22:59: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 4A72021F85C4 for ; Wed, 11 Apr 2012 22:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.041 X-Spam-Level: X-Spam-Status: No, score=-17.041 tagged_above=-999 required=5 tests=[AWL=0.557, 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 a-nE1dlf4m1V for ; Wed, 11 Apr 2012 22:59:24 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id 8D24221F85C3 for ; Wed, 11 Apr 2012 22:59:23 -0700 (PDT) Received: from [98.139.212.145] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 12 Apr 2012 05:59:22 -0000 Received: from [98.139.212.229] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 12 Apr 2012 05:59:22 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 12 Apr 2012 05:59:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 797065.94475.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 73710 invoked by uid 60001); 12 Apr 2012 05:59:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334210362; bh=Sux0oUnoSUdYtbz7x65TCcZAzsh5WimWkeIKkUBhumA=; 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=Qtz/hwHoGMYFYrRLxVWeeOybXvNiQ87QnWNOJvNgGYajJwMynq5RlroVDgL10MFEMbfVnGbcHW8dbSQpdXWkKKx8MRZ/tqPMmwArmkVl5BG0DFpeIbNbahS2aLXUCnhAEatdohz4srKXx2n43aybr+/hbD4JycOPkeZdrqSle+Y= 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=SkYxD83lMdLP60zozstSMj6Nt3bEdnmx8kBvrhkb7nfFdvRRftTOdMHryRPamriqtu/HHetwgFBn/JzarB22aIRvOYEb46rHONOF8i5MOyhOyN839VCo2YYIw25nmpWWtd9A6Pwj+mS8LBZlWVmnnZrKmt2z4iYyLqpI0MpgVpA=; X-YMail-OSG: fveyTV4VM1n4O5W2rk6HJNxxD1byPg4QvIUQ_ZhhBNAyNYH S70eaWgcT1IH6enMyL_2wwc4bwtzc9_Oj66dfM1hi1rwpfOyZMZt0eHg968_ FjaM5MyRI9a.Npr4CcmIE0W8IXgif249z9m.yZNf392x3zBHnphSnISluFqy kkKmer7oJ43XMyU3V6HIBkGzAzm0.tI7RUII6iY1zlOHyPWSDl8RxeaDUmdP ySqCqJ_KTBwRfOhJnr8eCAuwMbfUsMn78hG1WBkaA8z5bot3n8dWSOy68LL1 40_a8mNtUdTWpZhE7Hnq8d7guLK2eQkWu_tu8RQk39ayZyc8Erwo0o06XAqF TX6jco97ejOXzG7jtmSxmhMKsZs4uayLPxahgUrDtzEZlflaJcth0WVLxiRR kPvRDVwfhQGEsKtsteBPMK_rG9eUBVqhv0nGibJLWFQPbkOmNh76piAQe640 NpAZzNUI3XbRJsYnBFeHk2RJHrZ3GJuLijQ69tAZKrshXlCPWPR_MyITsjAZ huf1ZUs7eYdfzMcsINPEC7w4hAsbCq9DjO1ln1WuVwndVvhgForH9ryjV232 ZMlbPJRs0Jza64o5dfoCa87Ek3gGy1TDAinZGeRg7NOwWKw3dgrfGK5L2xAV hBIUSlXlgkQZlHsD55XEtzJIPT1ChpoEIfQ-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Wed, 11 Apr 2012 22:59:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com><4F833D26.4000105@gmail.com><69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com><4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im><4F85A6FF.80006@stpeter.im> <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4AF@XMB-RCD-313.cisco.com> Message-ID: <1334210362.42401.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Wed, 11 Apr 2012 22:59:22 -0700 (PDT) From: William Mills To: "Morteza Ansari \(moransar\)" , Phil Hunt , Peter Saint-Andre In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4AF@XMB-RCD-313.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-825434795-1334210362=:42401" Cc: Hasini Gunasinghe , Melinda Shore , Eliot Lear , "scim@ietf.org" Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? 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: Thu, 12 Apr 2012 05:59:25 -0000 ---1395015409-825434795-1334210362=:42401 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable As someone mostly on the sidelines here, there doesn't seem to be a reason = to stop work on a draft as long as any perceived churn there doesn't make a= bunch of noise in the chartering process/decision.=A0 Anything that's maki= ng the initial proposal more solid and workable seems like a good thing.=A0= I had 4 drafts of my ID done before Kitten adopted it, this seems comparab= le.=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From: Mo= rteza Ansari (moransar) =0A>To: Phil Hunt ; Peter Saint-Andre =0A>Cc: Hasini Gunasinghe= ; Melinda Shore ; Eliot Lear ; scim@ietf.org =0A>Sent: Wednesday, April 11, 2012 9:43 PM=0A= >Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec?=0A> =0A>This = is not about having a perfect starting point. It is about fixing=0A>the bug= s in the 1.0 spec quickly (within weeks not months/years) to=0A>solve some = of the interoperability issues discovered while testing 1.0=0A>spec. This w= ill result in a better starting point for IETF WG, but is=0A>independent of= it.=0A>=0A>For the record I don't have a strong opinion which is why I bro= ught the=0A>question up, but it seems it is easier to continue with existin= g model=0A>and communication mechanisms to wrap up these open issues while = we are=0A>exploring ideas for 1.next under IETF umbrella and trying to get = a WG=0A>formed.=0A>=0A>=0A>Cheers,=0A>Morteza=0A>=0A>-----Original Message-= ----=0A>From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behal= f Of=0A>Phil Hunt=0A>Sent: Wednesday, April 11, 2012 4:10 PM=0A>To: Peter S= aint-Andre=0A>Cc: Hasini Gunasinghe; Melinda Shore; Eliot Lear; scim@ietf.o= rg=0A>Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec?=0A>=0A>-= 1=0A>=0A>I don't believe the current draft needs to be perfect in order to = agree=0A>upon a charter.=A0 It only needs to be in good shape for last call= -- and=0A>we are a long way off from that!=0A>=0A>I'd be worried about try= ing to keep the IETF and Google group specs in=0A>sync. Why attempt that?= =0A>=0A>There is also the note well concerns previously mentioned.=0A>=0A>P= hil=0A>=0A>@independentid=0A>www.independentid.com=0A>phil.hunt@oracle.com= =0A>=0A>=0A>=0A>=0A>=0A>On 2012-04-11, at 8:45 AM, Peter Saint-Andre wrote:= =0A>=0A>> -----BEGIN PGP SIGNED MESSAGE-----=0A>> Hash: SHA1=0A>> =0A>> In = the interim, I think it would be best to keep discussing SCIM 1.0 =0A>> on = the existing cloud-directory list and to keep using the issue =0A>> tracker= at code.google.com. If and when a working group is formed at =0A>> the IET= F, folks can transition tracking and discussion to IETF venues.=0A>> =0A>> = Peter=0A>> =0A>> On 4/10/12 10:48 PM, Hasini Gunasinghe wrote:=0A>>> Hi all= ,=0A>>> =0A>>> May I know what the conclusion of this discussion is? I have= few =0A>>> suggestions to make for the improvement of couple of points in = the =0A>>> spec, based on the experience at the SCIM interop event.=0A>>> = =0A>>> I'd prefer to discuss them on ietf mailing list itself, since IMO - = =0A>>> it will be easy to track the discussions on the changes made to the = =0A>>> spec after SCIM 1.0 is submitted to IETF.=0A>>> =0A>>> Having said t= hat, I would like to bring your attention regarding an =0A>>> issue tracker= as in [1] . I am new to IETF and I guess it is created =0A>>> only after t= he WG is formed at IETF. If that is the case, it will be =0A>>> easier to c= ontinue reporting/fixing issues related to the spec in the=0A>=0A>>> Cloud-= Drectory WG since an issue tracker [2] has been maintained =0A>>> there alr= eady.=0A>>> =0A>>> [1] http://tools.ietf.org/wg/trackers [2] =0A>>> http://= code.google.com/p/scim/issues/list=0A>>> =0A>>> Thanks, Hasini.=0A>>> =0A>>= > =0A>>> On Tue, Apr 10, 2012 at 8:16 PM, Peter Saint-Andre =0A>>> > wrote:=0A>>> =0A>>> On 4/9/12 2:15= PM, Eliot Lear wrote:=0A>>>> What Melinda and Phil said.=A0 From an IETF p= erspective the procedure =0A>>>> is *normally* that WG control is asserted = at the point of adoption =0A>>>> of WG drafts.=A0 That having been said, if= the drafts are mentioned in=0A>=0A>>>> the charter and the charter is appr= oved, they should be relatively =0A>>>> stable during that period, IMHO.=0A= >>> =0A>>> True. There might be a period during which the authors are updat= ing =0A>>> both sets of documents, but hopefully the diffs are small. Howev= er, I=0A>=0A>>> see no harm in discussing these 1.0-specific bug fixes on t= he old =0A>>> list and keeping this list focused on chartering and related = topics. =0A>>> If and when the WG gets formed, folks would expect all discu= ssions to=0A>=0A>>> happen here.=0A>>> =0A>>> Peter=0A>>> =0A>>> -- Peter S= aint-Andre https://stpeter.im/=0A>>> =0A>>> =0A>>> ________________________= _______________________ scim mailing list =0A>>> scim@ietf.org =0A>>> https://www.ietf.org/mailman/listinfo/scim=0A>> -----BEGI= N PGP SIGNATURE-----=0A>> Version: GnuPG v1.4.8 (Darwin)=0A>> Comment: Usin= g GnuPG with Mozilla - http://enigmail.mozdev.org/=0A>> =0A>> iEYEARECAAYFA= k+Fpv8ACgkQNL8k5A2w/vx6MACeOJUKUoh4ZU0EbR/qXoTeg5Nu=0A>> 0o8AoJxHJzSQJLVzrF= m7VyB9v6DXw9U8=0A>> =3DGu2K=0A>> -----END PGP SIGNATURE-----=0A>> _________= ______________________________________=0A>> scim mailing list=0A>> scim@iet= f.org=0A>> https://www.ietf.org/mailman/listinfo/scim=0A>=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.iet= f.org/mailman/listinfo/scim=0A>=0A>=0A> ---1395015409-825434795-1334210362=:42401 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
As someone mostly on the sidelines here, there doesn't seem to be a reaso= n to stop work on a draft as long as any perceived churn there doesn't make= a bunch of noise in the chartering process/decision.  Anything that's= making the initial proposal more solid and workable seems like a good thin= g.  I had 4 drafts of my ID done before Kitten adopted it, this seems = comparable.

-bill

<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
=20 From: Morteza Ansari (mora= nsar) <moransar@cisco.com>
= To: Phil Hunt <phil.hunt@oracle.com>; Peter Saint-Andre &l= t;stpeter@stpeter.im>
Cc: Hasini Gunasinghe <hasini@wso2.com>; Melinda Shore <melinda= .shore@gmail.com>; Eliot Lear <lear@cisco.com>; scim@ietf.org
= Sent: Wednesday, April 11= , 2012 9:43 PM
Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec?
=0AThis is not about having a perfect starting point. It is about fixing<= br>the bugs in the 1.0 spec quickly (within weeks not months/years) to
s= olve some of the interoperability issues discovered while testing 1.0
sp= ec. This will result in a better starting point for IETF WG, but is
inde= pendent of it.

For the record I don't have a strong opinion which is= why I brought the
question up, but it seems it is easier to continue wi= th existing model
and communication mechanisms to wrap up these open iss= ues while we are
exploring ideas for 1.next under IETF umbrella and tryi= ng to get a WG
formed.


Cheers,
Morteza

-----Origina= l Message-----
From: scim-bounces@ietf.org [mailto:sci= m-bounces@ietf.org] On Behalf Of
Phil Hunt
Sent: Wednesday, April= 11, 2012 4:10 PM
To: Peter Saint-Andre
Cc: Hasini Gunasinghe; Melinda Sh= ore; Eliot Lear; scim@ietf.org
Subject: Re: [scim] Question for ADs: bug fixe= s to 1.0 spec?

-1

I don't believe the current draft needs to = be perfect in order to agree
upon a charter.  It only needs to be i= n good shape for last call -- and
we are a long way off from that!
I'd be worried about trying to keep the IETF and Google group specs insync. Why attempt that?

There is also the note well concerns previo= usly mentioned.

Phil

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





On 2012-04-11, at 8:45 AM, Pete= r Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the interim, I think it would be best to ke= ep discussing SCIM 1.0
> on the existing cloud-directory list and to= keep using the issue
> tracker at code.google.com. If and when a working group is for= med at
> the IETF, folks can transition tracking and discussion to I= ETF venues.
>
> Peter
>
> On 4/10/12 10:48 PM, Ha= sini Gunasinghe wrote:
>> Hi all,
>>
>> May I k= now what the conclusion of this discussion is? I have few
>> sugg= estions to make for the improvement of couple of points in the
>>= spec, based on the experience at the SCIM interop event.
>>
&= gt;> I'd prefer to discuss them on ietf mailing list itself, since IMO -=
>> it will be easy to track the discussions on the changes made = to the
>> spec after SCIM 1.0 is submitted to IETF.
>>
>> Having said that, I would like to bring you= r attention regarding an
>> issue tracker as in [1] . I am new to= IETF and I guess it is created
>> only after the WG is formed at= IETF. If that is the case, it will be
>> easier to continue repo= rting/fixing issues related to the spec in the

>> Cloud-Drecto= ry WG since an issue tracker [2] has been maintained
>> there alr= eady.
>>
>> [1] http://tools.ietf.org/wg/trackers [2] >> http://code.google.com/p/scim/issues/list
>>
>&= gt; Thanks, Hasini.
>>
>>
>> On Tue, Apr 10, 2= 012 at 8:16 PM, Peter Saint-Andre
>> <stpeter@stpeter.im = <mailto:stpeter@stpeter.im>> wrote:>>
>> On 4/9/12 2:15 PM, Eliot Lear wrote:
>>>= ; What Melinda and Phil said.  From an IETF perspective the procedure =
>>> is *normally* that WG control is asserted at the point of = adoption
>>> of WG drafts.  That having been said, if the= drafts are mentioned in

>>> the charter and the charter is= approved, they should be relatively
>>> stable during that pe= riod, IMHO.
>>
>> True. There might be a period during w= hich the authors are updating
>> both sets of documents, but hope= fully the diffs are small. However, I

>> see no harm in discus= sing these 1.0-specific bug fixes on the old
>> list and keeping = this list focused on chartering and related topics.
>> If and whe= n the WG gets formed, folks would expect all discussions to

>> happen here.
>>
>> Peter
>>=
>> -- Peter Saint-Andre https://stpeter.im/
>>
>>
>> _= ______________________________________________ scim mailing list
>&g= t; scim@i= etf.org <mailto:scim@ietf.org>
>> https://www.ietf.org/mailman= /listinfo/scim
> -----BEGIN PGP SIGNATURE-----
> Version: G= nuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://eni= gmail.mozdev.org/
>
> iEYEARECAAYFAk+Fpv8ACgkQNL8k5A2w/vx6MACe= OJUKUoh4ZU0EbR/qXoTeg5Nu
> 0o8AoJxHJzSQJLVzrFm7VyB9v6DXw9U8
> = =3DGu2K
> -----END PGP SIGNATURE-----
> _______________________________________________
> scim mailing list<= br>> s= cim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
_______________________________________________
scim mailing list
<= a ymailto=3D"mailto:scim@ietf.org" href=3D"mailto:scim@ietf.org">scim@ietf.= org
https://www.ietf.org/mailman/listinfo/scim
________________= _______________________________
scim mailing list
scim@ietf.org
https://w= ww.ietf.org/mailman/listinfo/scim


---1395015409-825434795-1334210362=:42401-- From moransar@cisco.com Wed Apr 11 23:06: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 DD19721F85C5 for ; Wed, 11 Apr 2012 23:06: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=[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 u+hYzqNpqukx for ; Wed, 11 Apr 2012 23:06: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 D066F21F85A0 for ; Wed, 11 Apr 2012 23:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=1464; q=dns/txt; s=iport; t=1334210800; x=1335420400; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1zUA6qJcclGwmSPSUhPNNgJh9LSmcsVEVykTZS8Oeg4=; b=iBu1HFetJOZidBTcAxDEwI1Z1d4TNOtEFvxBjUSsQZGQsKfgVMFWuSZ3 WTCfuaGVFzz3sgY9pHr2uUcgxGr1I16VqlrjjaSD2KjdMWYrSZV0Q5uMv Tb07uXEiusKxSkSByIv4XafBq8PtbuWZhmj1CtWjuir4hQ11ZEwfQMntu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI5whk+tJV2Y/2dsb2JhbAA7CblmgQeCCQEBAQMBAQEBDwEdCjQQBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah2cFC5pPoAUEiyaFcGMEiFqbX4FpgwU X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="74046738" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Apr 2012 06:06:39 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3C66dek004266; Thu, 12 Apr 2012 06:06:39 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, 12 Apr 2012 01:06:39 -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, 12 Apr 2012 01:06:38 -0500 Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com> In-Reply-To: <4F86686D.8010609@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0YbWiUdO8BlCU5Q127kdvTzwTotgAA/BKA References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F86686D.8010609@gmail.com> From: "Morteza Ansari (moransar)" To: "Melinda Shore" , X-OriginalArrivalTime: 12 Apr 2012 06:06:39.0174 (UTC) FILETIME=[6CA58E60:01CD1872] Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 06:06:41 -0000 "across administration domain" typically exists within an enterprise. There are many layers of identity data and typically they are managed using different policies and control points. So a notion of administrative boundary is part of the enterprise provisioning problem space as well between enterprise and service providers. Cheers, Morteza =20 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, April 11, 2012 10:30 PM To: scim@ietf.org Subject: Re: [scim] Draft charter - v7 On 4/11/12 9:10 PM, Morteza Ansari (moransar) wrote: > Note that it says "services" and "applications". In my view enterprise > identity provisioning use cases fall under the application part of=20 > this statement. Does anyone have a specific use case that you think=20 > should be addressed by SCIM that given the current charter wording is excluded? Actually, I think the issue may be more around "across adminmistrative domains," although 1) I think that can be addressed in the security considerations (and eventually mechanisms), and 2) implementers are going to do what they're going to do, anyway, and being fussy about anything other than protocol details tends to have a poor return on investment, as tempting as it is. Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Wed Apr 11 23:16: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 B038F21F85AF for ; Wed, 11 Apr 2012 23:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69GVcvKAJh5x for ; Wed, 11 Apr 2012 23:16:57 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 270A821F85AA for ; Wed, 11 Apr 2012 23:16:57 -0700 (PDT) Received: by dady13 with SMTP id y13so2841313dad.27 for ; Wed, 11 Apr 2012 23:16:57 -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=E01u6FQzMHbbxYMzvNmZfCbuvkpNZAI4kD7Zyel8Cgw=; b=CdJ7dZoKahc5JZFObGcrNHOIl/IT6UVLliwlWzic+4pgt2B7gyD71xGz9CRcn4LwiR J/8APjhA5sUk3ibemfGgSkPN4+s5SfV+Yz67/LugkUwfBRdPGth3IxdizM/6NHNmVUWE YxiPS1RTSNQcLGwwqb2NZqOaANdP8bsF966gfmdkLA4sSM5144MwPtPHHqjC6MnSOr+r 5toioJv4vAtC1bUqh7X9CgnNLEzjvrj6pKSnie33sr9cjf0L34pklgGQVjqCOs1oKhtI FKr4jUQ1Rpz4hIIHl+cTA7ZNCkE4HGaLRhoYKjmXngCE5YEc814lQppqW+HO/ptBwn0s LEXw== Received: by 10.68.235.106 with SMTP id ul10mr614243pbc.144.1334211416956; Wed, 11 Apr 2012 23:16:56 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id or6sm4772378pbc.43.2012.04.11.23.16.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 23:16:56 -0700 (PDT) Message-ID: <4F867354.3080908@gmail.com> Date: Wed, 11 Apr 2012 22:16:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Morteza Ansari (moransar)" References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F86686D.8010609@gmail.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 06:16:57 -0000 On 4/11/12 10:06 PM, Morteza Ansari (moransar) wrote: > "across administration domain" typically exists within an enterprise. > There are many layers of identity data and typically they are managed > using different policies and control points. So a notion of > administrative boundary is part of the enterprise provisioning problem > space as well between enterprise and service providers. I'm certainly aware of this but in conversation it seems as if it's so common to point out that there are administrative boundaries within an enterprise that there's an assumption that nobody knows this, which is either an odd thing or a thing to keep in mind when writing documents. At any rate there can be issues around trust that are somewhat different within an enterprise than across entirely unrelated organizations, in terms of the ability to make assumptions about trust anchors, etc. As I said I'm not sure this needs to be much of an issue outside of the security discussion. Melinda From jjaimon@jjaimon.net Wed Apr 11 23:19: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 35E9A21F84A7 for ; Wed, 11 Apr 2012 23:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.458 X-Spam-Level: X-Spam-Status: No, score=0.458 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.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 hP8zwW73Z-He for ; Wed, 11 Apr 2012 23:19:55 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 881F821F84A6 for ; Wed, 11 Apr 2012 23:19:55 -0700 (PDT) Received: (qmail 27867 invoked by uid 0); 12 Apr 2012 06:19:52 -0000 Received: from unknown (HELO box442.bluehost.com) (69.89.31.242) by cpoproxy3.bluehost.com with SMTP; 12 Apr 2012 06:19:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jjaimon.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:Reply-To:From:Date:Message-ID; bh=Dwz8He8B/E2PRxtfJtMGc61fmT7vVw3x1d0FFpuEFVU=; b=FbJRUjc2+XDe4uDpCJN3VBJR2mNl0OZrgnk+Vf08CR708NUMC+MB3HuicPxDW9FALRqxY14+Fq1/HiB3lh4NMHyx9BW2cngiVmCVgzksJBO9p5oUpXgnmWm2oh4bmsOr; Received: from ecoprobe-dmz.gns.novell.com ([192.31.114.252] helo=Jaimons-Macbook.local) by box442.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SIDNn-0002Hd-Sj; Thu, 12 Apr 2012 00:19:52 -0600 Message-ID: <4F867403.7000207@jjaimon.net> Date: Thu, 12 Apr 2012 11:49:47 +0530 From: Jaimon Jose User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Morteza Ansari (moransar)" References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C7@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C7@XMB-RCD-313.cisco.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {3105:box442.bluehost.com:jjaimonn:jjaimon.net} {sentby:smtp auth 192.31.114.252 authed with jjaimon+jjaimon.net} Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scim@ietf.org List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 06:19:56 -0000 I'm joining the discussion a little late. I searched through the threads and decided to shoot this mail since I didn't find a satisfactory answer for rationale behind the current charter. Please pardon me if the same has been debated earlier. The core of the WG seems to be to "design ......by defining standard protocols and schemas for creating, reading/searching, modifying and deleting user identities and identity-related objects across administrative domains." I also noticed that the charter specifically called out that "defining new authentication and policy/authorization schemes" is considered outside the scope. However, I"m wondering if the IDM as a domain is moving towards consolidation of identity services with a number of identity providers (social identity providers like google, facebook etc.) in addition to enterprise identities, isn't it better to address how services or applications can consume identities rather than expecting identities to be provisioned for each of those services. All that an application/service would require is the 4 A's (attributes, authentication, authorization and audit) of identities. This way we will move away from the notion of "identity provisioning" to identifying ways and means to "securely" consume identities across enterprise, private and public cloud entities. As a side effect, enterprise identities will be safe within their premise. Sorry if I'm way off track :-) Regards --jaimon Morteza Ansari (moransar) wrote, On 12-04-2012 10:42 AM: > Also, if I missed any other comments beyond these two please let me know. From stpeter@stpeter.im Thu Apr 12 06:07: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 C8D7021F862F for ; Thu, 12 Apr 2012 06:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 AF1CoqTqmJzO for ; Thu, 12 Apr 2012 06:07:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8721F8549 for ; Thu, 12 Apr 2012 06:07:42 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B68BE40058; Thu, 12 Apr 2012 07:21:35 -0600 (MDT) Message-ID: <4F86D39C.6010509@stpeter.im> Date: Thu, 12 Apr 2012 07:07:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: William Mills References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com><4F833D26.4000105@gmail.com><69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com><4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im><4F85A6FF.80006@stpeter.im> <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4AF@XMB-RCD-313.cisco.com> <1334210362.42401.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1334210362.42401.YahooMailNeo@web31809.mail.mud.yahoo.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eliot Lear , Melinda Shore , "scim@ietf.org" , Hasini Gunasinghe , "Morteza Ansari \(moransar\)" , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 13:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 11:59 PM, William Mills wrote: > As someone mostly on the sidelines here, there doesn't seem to be > a reason to stop work on a draft as long as any perceived churn > there doesn't make a bunch of noise in the chartering > process/decision. Anything that's making the initial proposal more > solid and workable seems like a good thing. I had 4 drafts of my > ID done before Kitten adopted it, this seems comparable. What's slightly different here is that if a working group is not formed, I'd expect folks here to continue their work on the old list. However, it's possible that folks would instead seek to work at the IETF via individual submissions, not a working group. As one data point, during formation of the OAuth WG, work and discussion about OAuth 1.0 continued on their old list, not the IETF list. That changed once the WG was formed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+G05wACgkQNL8k5A2w/vxrpQCdGe4ImI/2N1aJ0g7HGA+ry1Xx YpUAnAqSbRYFA9iwDBeA5ghDGGru6yQJ =mK0S -----END PGP SIGNATURE----- From kelly.grizzle@sailpoint.com Thu Apr 12 06:18: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 0388E21F863F for ; Thu, 12 Apr 2012 06:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 S9om+1KmXfiN for ; Thu, 12 Apr 2012 06:18:05 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9684721F8642 for ; Thu, 12 Apr 2012 06:18:04 -0700 (PDT) Received: from mail104-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 13:18:02 +0000 Received: from mail104-am1 (localhost [127.0.0.1]) by mail104-am1-R.bigfish.com (Postfix) with ESMTP id C98954C0605; Thu, 12 Apr 2012 13:18:02 +0000 (UTC) X-SpamScore: -38 X-BigFish: PS-38(zzbb2dI154cP9371I542M98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail104-am1: 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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1334236680151735_25572; Thu, 12 Apr 2012 13:18:00 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.240]) by mail104-am1.bigfish.com (Postfix) with ESMTP id 1573880091; Thu, 12 Apr 2012 13:18:00 +0000 (UTC) Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 13:17:57 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.53]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 13:17:48 +0000 From: Kelly Grizzle To: Peter Saint-Andre , William Mills Thread-Topic: [scim] Question for ADs: bug fixes to 1.0 spec? Thread-Index: Ac0WIUy/DpNjdjCLSS++ldRwNy27xAAaH6AAAAC91wAAADEHgAAmzpqAAB1nxYAAFuvIgAAPi82AAAuoQQAAAqIhAAAO9U0AAABNelA= Date: Thu, 12 Apr 2012 13:17:47 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C670EBF@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE010C581B@XMB-RCD-313.cisco.com><4F833D26.4000105@gmail.com><69AA81A6-55DF-4426-8F44-A18299050B23@oracle.com><4F834369.1000705@cisco.com> <4F8447D7.4050201@stpeter.im><4F85A6FF.80006@stpeter.im> <2D2C91D3-B2E7-40D8-AA7D-D31064E5C2D8@oracle.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4AF@XMB-RCD-313.cisco.com> <1334210362.42401.YahooMailNeo@web31809.mail.mud.yahoo.com> <4F86D39C.6010509@stpeter.im> In-Reply-To: <4F86D39C.6010509@stpeter.im> 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: Eliot Lear , Melinda Shore , "scim@ietf.org" , Hasini Gunasinghe , "Morteza Ansari \(moransar\)" , Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 13:18:06 -0000 Thanks for your input (even with hat off), Peter. I think these are all go= od reasons to keep the short-term SCIM 1.0 bug fixes on the old list and th= e charter/WG discussions here. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Thursday, April 12, 2012 8:08 AM To: William Mills Cc: Eliot Lear; Melinda Shore; scim@ietf.org; Hasini Gunasinghe; Morteza An= sari (moransar); Phil Hunt Subject: Re: [scim] Question for ADs: bug fixes to 1.0 spec? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 11:59 PM, William Mills wrote: > As someone mostly on the sidelines here, there doesn't seem to be a=20 > reason to stop work on a draft as long as any perceived churn there=20 > doesn't make a bunch of noise in the chartering process/decision.=20 > Anything that's making the initial proposal more solid and workable=20 > seems like a good thing. I had 4 drafts of my ID done before Kitten=20 > adopted it, this seems comparable. What's slightly different here is that if a working group is not formed, I'= d expect folks here to continue their work on the old list. However, it's possible that folks would instead seek to work at the IETF vi= a individual submissions, not a working group. As one data point, during formation of the OAuth WG, work and discussion ab= out OAuth 1.0 continued on their old list, not the IETF list. That changed = once the WG was formed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+G05wACgkQNL8k5A2w/vxrpQCdGe4ImI/2N1aJ0g7HGA+ry1Xx YpUAnAqSbRYFA9iwDBeA5ghDGGru6yQJ =3DmK0S -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From barryleiba.mailing.lists@gmail.com Thu Apr 12 07:34: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 CB2CE21F8647 for ; Thu, 12 Apr 2012 07:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=0.240, 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 IIaH92bA1-mG for ; Thu, 12 Apr 2012 07:34:27 -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 C4C9921F8604 for ; Thu, 12 Apr 2012 07:34:27 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1221280yhk.31 for ; Thu, 12 Apr 2012 07:34:27 -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 :content-transfer-encoding; bh=bDzq4+wD22F01hs2G828fp2M3VHDebZt6B96bGRFmuE=; b=Tma7C4IHYO8N3OAnijpG1zJIu09IEkQGjLigFCCaaw8B/1mcLrCgA5QEA4B0OvktII vp+fPpK7Uqgaw9vk1Av3CR8gnHM4d2jkplIL306O1Wl7Z+IVIWdmNew6iHP13kwkQID+ /2zc58ptiKY14ao4wKrPNp5wdJJA098K2vQ1JFjYgl5GTyDRPy41HCS1ICxwlUAY9Q2Q YyzLFLWXRqY/Uqb2XVS0DSmwogS9rERfhWlHZO5IiNzYEacxQ4P3y3SwHJRUkTCNxiBu jPprxSYa5RUUxB5TWVU3fSYZTfEyDu3egCEQeyEJthDiorLpXe/n3Lx5Uk6XrKX9KgaZ Y1Mw== MIME-Version: 1.0 Received: by 10.236.78.201 with SMTP id g49mr2306221yhe.33.1334241267441; Thu, 12 Apr 2012 07:34:27 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Thu, 12 Apr 2012 07:34:27 -0700 (PDT) In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> Date: Thu, 12 Apr 2012 10:34:27 -0400 X-Google-Sender-Auth: UnY0GTIVZODLSZupxTFUSdHzu-g Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 14:34:28 -0000 > Name of the protocol/WG > > I personally think there is significant value in the existing > implementations of 1.0 and traction the whole effort has had and renaming= it > would be a poor decision.=A0 With that said, it sounds like most folks ei= ther > don=92t care or interested in keeping the name the same. If someone stron= gly > objects to this or has concerns please raise it. Let me stick my oar in as an AD. 1. Wasting a lot of time worrying about the name is... wasting a lot of time. It's really counter-productive to let such a silly thing turn into a rat hole. 2. That said, naming is marketing. 2a. For whatever it's worth, and however much we may not like it, Melinda's note that the term "cloud" has developed some level of toxicity around parts of the IETF, and in the IESG in particular, is true. That's a result of other, repeated, poorly focused efforts, and it's made many people think that anything called "cloud" is poorly focused and to be regarded with a lot of suspicion. I don't think it's a good idea to start your proposal with that baggage. 2b. I agree with the comments that say this isn't specific to what we've usually called "cloud" services. It goes beyond that, and that's another reason I urge you to take "cloud" out of the name. Now, you can certainly say that enterprise is cloud, data center is cloud, is cloud, but I note that that supports the concerns of those who think that "cloud" is just a too-broad term that eventually swallows up everything [compare: http://www.imdb.com/title/tt0051418/ ]. I really don't think you want to have to fight that battle. 3. I don't think "identity management" is the right term here either. ID management is also a very large sandwich, which has several bites taken out of it so far (OpenID, AbFab, OAuth, and SAML are all pieces of it). This is another *piece* of ID management, and it's best to label it as a piece, not as an attempt at swallowing the whole sandwich. What you're proposing isn't so much "cloud identity management" as it is identity provisioning within and across administrative domains. A name that gets that point across will server you better than a heels-dug insistence on keeping a name you've come to love, though I do understand the desire to keep that. None of this is any official pronouncement from the IESG... just the opinion of one AD who will be part of the charter approval process (and one who might wind up being the responsible AD for the WG, if it's chartered in the App Area). Barry From prvs=442da75c2=Mark.Diodati@gartner.com Thu Apr 12 13:02: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 4CFC421F86B4 for ; Thu, 12 Apr 2012 13:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Xy+C-dVWo0m8 for ; Thu, 12 Apr 2012 13:02:25 -0700 (PDT) Received: from zinc-main.gartner.com (zinc-main.gartner.com [207.140.148.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2B32D21F846B for ; Thu, 12 Apr 2012 13:02:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOgzh08KQCMD/2dsb2JhbAA8CYJGuDeCCQEBBXkQAgEIEQQBAQsdBzIUCQgCBA4NwiaLKwiFaGMEqQmBXA X-IronPort-AV: E=Sophos;i="4.75,411,1330923600"; d="scan'208,217";a="78915136" From: "Diodati,Mark" To: "Morteza Ansari (moransar)" Thread-Topic: [scim] Draft charter - v7 Thread-Index: AQHNGGqkisIaKYwZm0WTrjUYgrWU0JaXmWtQ Date: Thu, 12 Apr 2012 19:59:56 +0000 References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.129] Content-Type: multipart/alternative; boundary="_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60B88235Dwhistlerentgart_" MIME-Version: 1.0 Message-Id: <20120412200225.2B32D21F846B@ietfa.amsl.com> Cc: "scim@ietf.org" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 20:02:28 -0000 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60B88235Dwhistlerentgart_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Morteza - nice work. I cannot think of any additional use cases that are as= sociated with enterprise provisioning. All- As for the discussion over the word "cloud", our enterprise clients are beg= inning to use it to describe their on-premises environment. If SCIM is renamed, it will negatively impact its success. Also, +1 on Mort= eza's assessment of the 1.0 value proposition; we are already seeing produc= ts adopt it. What message is sent to adopters if we change the name? The charter statement is long enough; I think that it could be reduced. But= more details are not appropriate-the statement is beginning to lose cohere= nce and look SPML-y (which is to say "kitchen sink"). The extended focus on language minimally appears to be distracting, maximal= ly may have negative consequences for adoption. Apologies in advance; I mean no offense. Mark From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Thursday, April 12, 2012 12:11 AM To: scim@ietf.org Subject: Re: [scim] Draft charter - v7 Lots of interesting discussions on the thread. I am trying to figure out wh= at edits I should make to the latest charter to address concerns/issues rai= sed. Summarizing the thread it seems there were two major points discussed= . Name of the protocol/WG I personally think there is significant value in the existing implementatio= ns of 1.0 and traction the whole effort has had and renaming it would be a = poor decision. With that said, it sounds like most folks either don't care= or interested in keeping the name the same. If someone strongly objects to= this or has concerns please raise it. Actual scope of work There were a lot of discussions on whether SCIM is solving a cloud use case= or addressing enterprise provisioning case as well. The problem I am havi= ng is that the discussion is mainly around high level semantics of cloud vs= . enterprise. Melinda, I fully agree that overgeneralizing the problem is just as bad as = boiling the ocean, however we need to come up with specific use cases that = we think should be included in the charter and problem statement. The chart= er actually says: "The Simple Cloud Identity Management (SCIM) specification will be designed= to simplify user identity management in services and applications by defin= ing standard protocols and schemas for creating, reading/searching, modifyi= ng, and deleting user identities and identity-related objects across admini= strative domains." Note that it says "services" and "applications". In my view enterprise ide= ntity provisioning use cases fall under the application part of this statem= ent. Does anyone have a specific use case that you think should be addresse= d by SCIM that given the current charter wording is excluded? Cheers, Morteza From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Morteza A= nsari (moransar) Sent: Monday, April 09, 2012 6:56 PM To: scim@ietf.org Subject: [scim] Draft charter - v7 Hi folks, Here is the updated charter based on the discussions that took place in the= BoF meeting and some guidance from a hallway conversation with Pete after = the meeting. Please review the text and send your comments. Hopefully we c= an close this soon and hand it over to the ADs. Phil, I added a note regarding targeting extensions in the updated charter = given the email discussions. Cheers, Morteza ________________________________ This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute,= or otherwise use this message or its attachments. Please notify the sender= immediately by return e-mail and permanently delete this message and any a= ttachments. Gartner makes no warranty that this e-mail is error or virus fr= ee. --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60B88235Dwhistlerentgart_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Morteza - nice work. I= cannot think of any additional use cases that are associated with enterpri= se provisioning.

 

All-

 

As for the discussion = over the word “cloud”, our enterprise clients are beginning to = use it to describe their on-premises environment.

 

If SCIM is renamed, it= will negatively impact its success. Also, +1 on Morteza’s assess= ment of the 1.0 value proposition; we are already seeing products adopt it.= What message is sent to adopters if we change the name?

 

The charter statement = is long enough; I think that it could be reduced. But more details are not = appropriate—the statement is beginning to lose coherence and look SPM= L-y (which is to say “kitchen sink”).

 

The extended focus on = language minimally appears to be distracting, maximally may have negative c= onsequences for adoption.

 

Apologies in advance; = I mean no offense.

 

Mark

 

From: Mortez= a Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Thursday, April 12, 2012 12:11 AM
To: scim@ietf.org
Subject: Re: [scim] Draft charter - v7

 

Lots of interesting di= scussions on the thread. I am trying to figure out what edits I should make= to the latest charter to address concerns/issues raised.  Summarizing= the thread it seems there were two major points discussed.

 

Name of the protoco= l/WG

I personally think the= re is significant value in the existing implementations of 1.0 and traction= the whole effort has had and renaming it would be a poor decision.  W= ith that said, it sounds like most folks either don’t care or interested in keeping the name the same. If som= eone strongly objects to this or has concerns please raise it.

 

Actual scope of wor= k

There were a lot of di= scussions on whether SCIM is solving a cloud use case or addressing enterpr= ise provisioning case as well.  The problem I am having is that the di= scussion is mainly around high level semantics of cloud vs. enterprise.

 

Melinda, I fully agree= that overgeneralizing the problem is just as bad as boiling the ocean, how= ever we need to come up with specific use cases that we think should be inc= luded in the charter and problem statement. The charter actually says:

 

“The Simple Clou= d Identity Management (SCIM) specification will be designed to simplify use= r identity management in services and applications by defining standard pro= tocols and schemas for creating, reading/searching, modifying, and deleting user identities and identity-related objects acros= s administrative domains.”

 

Note that it says R= 20;services” and “applications”.  In my view enterpr= ise identity provisioning use cases fall under the application part of this= statement. Does anyone have a specific use case that you think should be addressed by SCIM that given the current charter wording is excluded?

 

 

Cheers,

Morteza

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar)
Sent: Monday, April 09, 2012 6:56 PM
To: scim@ietf.org
Subject: [scim] Draft charter - v7

 

Hi folks,

 

Here is the updated charter based on the discussions= that took place in the BoF meeting and some guidance from a hallway conver= sation with Pete after the meeting.  Please review the text and send y= our comments. Hopefully we can close this soon and hand it over to the ADs.

 

Phil, I added a note regarding targeting extensions = in the updated charter given the email discussions.

 

 

Cheers,

Morteza



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.
 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60B88235Dwhistlerentgart_-- From lear@cisco.com Thu Apr 12 13:05:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57321F86B8 for ; Thu, 12 Apr 2012 13:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.55 X-Spam-Level: X-Spam-Status: No, score=-110.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 19xwE9e0imqW for ; Thu, 12 Apr 2012 13:05:12 -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 03F9521F86B7 for ; Thu, 12 Apr 2012 13:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2991; q=dns/txt; s=iport; t=1334261112; x=1335470712; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DbhHKTEz5YvfjKPdlCmys4Czq6FwIxbZQ2HZwYCfouw=; b=mB2rr9D1plYvFBad505CdxEoDlLP1x4DvD4+ayugXBd8lHglI9cQAHhl B2eXgWcSHnJuc8/69lrEQ7DLFnycffiHM0FHoSdtL7J+FmsVDmaDLBd78 FXGlvoAyQh2CZ49dCWMCpRTzTRIEseB9vBi0tSH2dIDq1TGa+Q1R8RNVS A=; X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="134999648" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2012 20:05:11 +0000 Received: from dhcp-10-61-97-207.cisco.com (dhcp-10-61-97-207.cisco.com [10.61.97.207]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3CK5Anm026309; Thu, 12 Apr 2012 20:05:10 GMT Message-ID: <4F873572.9060205@cisco.com> Date: Thu, 12 Apr 2012 22:05:06 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 12 Apr 2012 20:05:13 -0000 Barry, First, putting aside the name for a moment (we'll come back to that) what do you think of the REST of the charter (pun intended)? Eliot On 4/12/12 4:34 PM, Barry Leiba wrote: >> Name of the protocol/WG >> >> I personally think there is significant value in the existing >> implementations of 1.0 and traction the whole effort has had and renaming it >> would be a poor decision. With that said, it sounds like most folks either >> don’t care or interested in keeping the name the same. If someone strongly >> objects to this or has concerns please raise it. > Let me stick my oar in as an AD. > > 1. Wasting a lot of time worrying about the name is... wasting a lot > of time. It's really counter-productive to let such a silly thing > turn into a rat hole. > > 2. That said, naming is marketing. > > 2a. For whatever it's worth, and however much we may not like it, > Melinda's note that the term "cloud" has developed some level of > toxicity around parts of the IETF, and in the IESG in particular, is > true. That's a result of other, repeated, poorly focused efforts, and > it's made many people think that anything called "cloud" is poorly > focused and to be regarded with a lot of suspicion. I don't think > it's a good idea to start your proposal with that baggage. > > 2b. I agree with the comments that say this isn't specific to what > we've usually called "cloud" services. It goes beyond that, and > that's another reason I urge you to take "cloud" out of the name. > Now, you can certainly say that enterprise is cloud, data center is > cloud, is cloud, but I note that that supports the concerns > of those who think that "cloud" is just a too-broad term that > eventually swallows up everything [compare: > http://www.imdb.com/title/tt0051418/ ]. I really don't think you want > to have to fight that battle. > > 3. I don't think "identity management" is the right term here either. > ID management is also a very large sandwich, which has several bites > taken out of it so far (OpenID, AbFab, OAuth, and SAML are all pieces > of it). This is another *piece* of ID management, and it's best to > label it as a piece, not as an attempt at swallowing the whole > sandwich. What you're proposing isn't so much "cloud identity > management" as it is identity provisioning within and across > administrative domains. A name that gets that point across will > server you better than a heels-dug insistence on keeping a name you've > come to love, though I do understand the desire to keep that. > > None of this is any official pronouncement from the IESG... just the > opinion of one AD who will be part of the charter approval process > (and one who might wind up being the responsible AD for the WG, if > it's chartered in the App Area). > > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From barryleiba.mailing.lists@gmail.com Fri Apr 13 06:34: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 371CE21F87C9 for ; Fri, 13 Apr 2012 06:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=0.198, 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 bSaM2X0nhrkL for ; Fri, 13 Apr 2012 06:34:24 -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 63BC321F87C8 for ; Fri, 13 Apr 2012 06:34:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1807943ghb.31 for ; Fri, 13 Apr 2012 06:34: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=lEYhiXnL1x50eSerksa8WTRZwyGV4k+B+XN6yQQZjwk=; b=ojyT66CPJhWP0bfY1bTFBqjId9obMY+E2wxfXx+Wx7FQKKKG8fztqU3WIrxmX0XKxM xId0LcOdNZLshN0CI+HArdRR7qC4p2i9BEJU3uI4GsiKKAHzBUhk6GKuA3MyHaLNB5qH A7vcOyF0Bwl1NBT8XSRLXYhhIIuYNtc7kkmEDIqLO/NhdTU8A3AWcNhuSB8nwhcsvZuy +en38Z8YgZWxho3AyOHxJC8h3JEkbxUB22UaXUnT7rZ81ZNoYRCch/y4aCy1wJCdCgMc UmKzawHVQnMQ6j0/HragQZ2j8GeFEZA1EqD4wcXosa7IRFda9VHvj+yBTSamA/Fswt2U Ur/w== MIME-Version: 1.0 Received: by 10.236.190.2 with SMTP id d2mr1579547yhn.48.1334324063925; Fri, 13 Apr 2012 06:34:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Fri, 13 Apr 2012 06:34:23 -0700 (PDT) In-Reply-To: <4F873572.9060205@cisco.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> Date: Fri, 13 Apr 2012 09:34:23 -0400 X-Google-Sender-Auth: GKgAqJDzn1E-WMQF0Ndrf6yeCAQ Message-ID: From: Barry Leiba To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 13 Apr 2012 13:34:25 -0000 > First, putting aside the name for a moment (we'll come back to that) > what do you think of the REST of the charter (pun intended)? A fair question. I had wanted to wait for the next iteration, since I know that Morteza has updates to make, based on comments. But yes, here are my thoughts. * I do think the charter is well thought out and well scoped, in general. * I am still concerned about the need to develop a new *protocol*, rather than using or adapting existing protocols with new, standardized schemas and uses. It's often the case that an applicability statement on an existing protocol can do the job, and I'd like to see that seriously considered *within the IETF context*. * That said, something built on REST might, indeed, be the right thing. At the risk of repeating: it's hard to know that without a real analysis. And as I said in Paris, it's hard to do an objective analysis when you already have the answer you want. I'm not sure how to fix that, but I think we need to try. * I worry that there's no consideration in the charter for security aspects of this, other than to specifically *exclude* work on authentication and authorization. It's probably good not to spin up new mechanisms for these, but I'd like the charter to say something about how the system *will* address issues of authentication, authorization, access control, privacy, and integrity. * The milestones are of course very fuzzy at this point, as they should be. So I'll stick this in just as an early warning: having five documents in active development in the working group at once is probably not the best approach. I'm less interested in milestones for adoption of drafts than I am about ones for completion of drafts, and I expect WG chairs to make sure that the work gets started at an appropriate time to have a good hope of meeting the completion milestones. WGs too often set up too many things going on at once, and then have trouble coordinating them. Be aware of that. Back to the name just for a moment, since Mark said something I have to respond to, which I think is an important point beyond rat-holing on the name: > If SCIM is renamed, it will negatively impact its success. Really? OK, I know naming is marketing, and marketing is important. I also know that this is a statement of one person's opinion, not necessarily a point of consensus. But I suggest that if that's really the case, there's a significant problem here. If what comes out of this is a useful, well designed, and important solution, it will be adopted, regardless of the name. If it *is* useful, well designed, and important, and its name alone gets in the way of adoption, then I think we have more problems than a standards working group can solve, and I'm very much concerned. You have an established group *outside* the IETF that's been working on this. That's a beautiful thing; we like that. What you're trying to do now is get people *within* the IETF to come work with you, to finish and solidify it. Your marketing focus has shifted: you now want to market to the IETF, to make sure you get the right people involved. > we are already seeing products adopt it. What message is sent to adopters > if we change the name? We send the message that we thought there was a good reason to change the name. That's all. It's happened in many cases, and in none of them did it seriously bother anyone or significantly affect the success of the result. Barry From melinda.shore@gmail.com Fri Apr 13 12:26: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 97B3211E80EF for ; Fri, 13 Apr 2012 12:26:32 -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 4Z+njI6h99eh for ; Fri, 13 Apr 2012 12:26:32 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0641F11E80E0 for ; Fri, 13 Apr 2012 12:26:32 -0700 (PDT) Received: by dady13 with SMTP id y13so5970942dad.27 for ; Fri, 13 Apr 2012 12:26:31 -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 :content-type:content-transfer-encoding; bh=XN4q9ato0NWqTn8W1s1F4/VmaVwKaWDRcdi9B5KYKGk=; b=djV2ins9s4oSyAw9d+Q9vIbUWYB6wCXBMnTiV2EYcDZg4/1HwaKALUWgloGx52gTSN D+vLl3rt7n1fDMIVJzg8H8jrYrvIcFnmv9S9LeqcwnX/sC5JF16WWd1u1psbNEquZQHe tbBXKXQpO7xE/G392siiPR2C/Ivazjg9zVdqhQnfgUEiD0tIUZzQTpPZvZmWQDwDKNxU LN+/ZhBi1LMe8EdJQnBbht9VgaKrs1a/RnSfqQxiQD4ysAFmGDdWFiKRVCoafDo4QKql 3/a+YDyvF/T4cKKPrTMoHiayk3OXgZ6iKA9X0yWdq2kSDV0f/rDL8dK34ZUYwUz+j34M bi4g== Received: by 10.68.235.2 with SMTP id ui2mr7075066pbc.30.1334345191718; Fri, 13 Apr 2012 12:26:31 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id h10sm9499462pbe.12.2012.04.13.12.26.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 12:26:31 -0700 (PDT) Message-ID: <4F887DE5.6000403@gmail.com> Date: Fri, 13 Apr 2012 11:26:29 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [scim] Security considerations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 13 Apr 2012 19:26:32 -0000 I've been going through the drafts and while the security discussions aren't the worst I've seen in BOF-stage work they're pretty thin. Even saying "Use TLS" isn't going to be sufficient to address interoperability or trust issues. I haven't been able to find anything that looks like a framework or problem statement draft but that would be the place to say "Here are the security issues we'll need to address" without getting into the specific mechanisms that would be implemented to solve the security problems that have been identified. It seems that both because there are regulatory requirements in some industries for protecting PII and because, well, you really do want to do the right thing, there's going to be a need to be at least a little rigorous about both privacy issues and protecting the integrity of the data. Barry wrote "I worry that there's no consideration in the charter for security aspects of this, other than to specifically *exclude* work on authentication and authorization. It's probably good not to spin up new mechanisms for these, but I'd like the charter to say something about how the system *will* address issues of authentication, authorization, access control, privacy, and integrity." It seems to me that the "something about how" should probably be replaced with "that" or something along those lines, with the "how" reserved for the specs. Melinda From barryleiba.mailing.lists@gmail.com Fri Apr 13 14:09:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4F11E80FD for ; Fri, 13 Apr 2012 14:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.814 X-Spam-Level: X-Spam-Status: No, score=-102.814 tagged_above=-999 required=5 tests=[AWL=0.163, 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 5xWqVlt+1ewY for ; Fri, 13 Apr 2012 14:09:10 -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 7720B11E80E4 for ; Fri, 13 Apr 2012 14:09:08 -0700 (PDT) Received: by yenm5 with SMTP id m5so2141719yen.31 for ; Fri, 13 Apr 2012 14:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=76IG2t8ghW5bURmphOKNdwXs5iNEp0kWZoXMmy7v0fA=; b=IzrXpGKoRvMvQLagcvpLCPfgnF1r5z3zA0FdGgmbbyVjo1Z37k2Uwj0nqiQ9w3sHFE 97OBv90xx5VZQDsTUIJ0REKVNnFkYA4tZD8BHpjKiSwxYbTGrvN7sltXtSM9JnVoKrXC luHNv5dEbO56eSsOuUWhJ6Pi+jScWiPEpjEYdKaK1al1T1MjiUwwR6qgCQj4CnUhky7t ke4Cu3XCPvzhhdnZ3zuc5O6VtMqHNmD/NJ/+svMfP6yR533O4+0Jo5yIYNx+KX0hkSeS aFRodURiA96PxtUFUUgLAGxUpNlVNHOYXQBl+NEmS4QaTGvDqirIXCC9m0fMyvMzZ7TY tX0g== MIME-Version: 1.0 Received: by 10.236.114.169 with SMTP id c29mr3140984yhh.37.1334351348112; Fri, 13 Apr 2012 14:09:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Fri, 13 Apr 2012 14:09:08 -0700 (PDT) In-Reply-To: <4F887DE5.6000403@gmail.com> References: <4F887DE5.6000403@gmail.com> Date: Fri, 13 Apr 2012 17:09:08 -0400 X-Google-Sender-Auth: iIWpdOZ2sC90jhqWobq2MNMuDkQ Message-ID: From: Barry Leiba To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "scim@ietf.org" Subject: Re: [scim] Security considerations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 13 Apr 2012 21:09:11 -0000 > Barry wrote "I worry that there's no consideration in the charter for > security aspects of this, other than to specifically *exclude* work on > authentication and authorization. It's probably good not to spin up > new mechanisms for these, but I'd like the charter to say something > about how the system *will* address issues of authentication, > authorization, access control, privacy, and integrity." =A0It seems to me > that the "something about how" should probably be replaced with "that" > or something along those lines, with the "how" reserved for the specs. Mostly, yes... but it's very easy to put a sentence in a charter that says, "The working group will address security-related issues," and it doesn't really say much, does it? The charter won't have answers, of course, but I'd like to see that there was *some* thought put into it, and that there isn't just a sentence in there to make a few ADs smile. Barry From melinda.shore@gmail.com Fri Apr 13 14:45:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B211E8144 for ; Fri, 13 Apr 2012 14:45:13 -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 CLCqxmhywx-q for ; Fri, 13 Apr 2012 14:45:12 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5530211E8143 for ; Fri, 13 Apr 2012 14:45:12 -0700 (PDT) Received: by dady13 with SMTP id y13so6122975dad.27 for ; Fri, 13 Apr 2012 14:45:12 -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=TbDWZkNLibUN9WPxtlaPtNA6MNlAbTxpJauXWeyxMLs=; b=t5QfJ9pXmcsmUn2H7N5TnlNoM7HHUHQKxv2Kc+7HsAuSgTdr7EMzOohldzlfb6POcS JR2/vLxks4MpaIJRFDLf9QKRvBvLRs36XN4hSFLqISAKImvLYzQWQj5bO4wXF6WEIBRV zhIYdx2W9/ANs8282rSnydPWnvOavRwdOdqbKUebtF6HtBiapFjZktLo0IXJfJoIjuO+ Zdw40A+RTPicjScT41YoUbge/sLnTfMrOFnfiXvmUOO3J5YLjlAS9i6NUmyVGoTWGlJA WQcsZ7sp9psmLL/AHvrh2lTKw6wpa5+NqmBwGR3Tow+NWfNtyZiA3WocOgAkS9p0SObG G5QQ== Received: by 10.68.226.200 with SMTP id ru8mr2404816pbc.71.1334353512122; Fri, 13 Apr 2012 14:45:12 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id w10sm9768473pbk.30.2012.04.13.14.45.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 14:45:11 -0700 (PDT) Message-ID: <4F889E64.2060608@gmail.com> Date: Fri, 13 Apr 2012 13:45:08 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Barry Leiba References: <4F887DE5.6000403@gmail.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] Security considerations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 13 Apr 2012 21:45:13 -0000 On 4/13/12 1:09 PM, Barry Leiba wrote: > Mostly, yes... but it's very easy to put a sentence in a charter that > says, "The working group will address security-related issues," and it > doesn't really say much, does it? The charter won't have answers, of > course, but I'd like to see that there was *some* thought put into it, > and that there isn't just a sentence in there to make a few ADs smile. What about something along the lines of: "Given both the sensitivity of the information being conveyed in scim (or whatever) messages and the regulatory requirements around the privacy of personally identifiable information, the working group will pay particular attention to issues around authenticity and privacy, in addition to the usual requirements around security consideration." I've been involved with working groups where there was very explicit language around security in the charter, mostly to mollify the IESG, and where ultimately the working group punted, and I'll bet you have, too. In the end it comes down to the working group. As an aside I'd hate to see "Just use oauth bearer tokens" join "just use TLS" and "just use ipsec" on the heap of unthoughtful/ uninteroperable security text. Melinda From phil.hunt@oracle.com Fri Apr 13 14:57: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 D637C11E814E for ; Fri, 13 Apr 2012 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 k9LnQoh0AXBi for ; Fri, 13 Apr 2012 14:57:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 606DA11E80C4 for ; Fri, 13 Apr 2012 14:57:43 -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 q3DLvbJj021965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 21:57:38 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 q3DLvaR1026275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2012 21:57:37 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3DLvamb007858; Fri, 13 Apr 2012 16:57:36 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Apr 2012 14:57:36 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 13 Apr 2012 14:57:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> To: Barry Leiba X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090206.4F88A153.001A,ss=1,re=0.000,fgs=0 Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" , Eliot Lear Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 13 Apr 2012 21:57:45 -0000 +1=20 I agree with Barry, part of the objective of bringing SCIM to IETF is to = engage a larger community. In my opinion that broader community has yet = to join this potential WG. One of those communities is the members of = the OASIS Provisioning TC. Members elected to idle that TC pending SCIMs = move into IETF. Many of those members have yet to join this discussion = as they are unsure about whether SCIM is to be a provisioning protocol. When we talk about consensus the group is somewhat skewed towards the = perspectives of SPs and directories. The group may be making the same = mistake that OASIS SPML made -- just in reverse. --> SPML emphasized = the client role at the expense of the SP, while SCIIM emphasizes the = service API at the expense of the client. I contend we need to look at = this problem domain with *appropriate balance*.=20 The current draft looks very much like a RESTful LDAP spec with updated = schema (e.g. complex attributes) - in fact I understand that was the = original objective. Much like you can do provisioning with LDAP, you can = do provisioning with SCIM. However, from the perspective of a = provisioning "system" client, you can use LDAP (or SCIM) as a connector, = but neither LDAP nor SCIM are provisioning protocols (yet). I think the group should decide whether "provisioning" is an important = objective going forwards. If the group is prepared to entertain SCIM = being a provisioning protocol, I'm prepared to send another message = shortly detailing issues that should be more broadly considered. We can = then debate those topics on their merits. However, I have the strong = sense the consensus is SCIM should be a RESTfull Access Protocol (RAP). Let me state then, that I can support EITHER direction. The case for = SCIM/RAP is very STRONG. I've already run across several RESTful LDAP = implementations. My own organization has a few. This alone makes a = strong case for standardization. Based on supporting customers running = LDAP on the open Internet for over 10 years, there are some lessons = learned that can be applied to the spec with regards to attacks and = error handling. But that won't need charter revisions. I see these as = issues that will arise as we go through security considerations (see = Melinda's message today). Does the group wish to exclude provisioning as an objective? I will = support either direction. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-13, at 6:34 AM, Barry Leiba wrote: >> First, putting aside the name for a moment (we'll come back to that) >> what do you think of the REST of the charter (pun intended)? >=20 > A fair question. I had wanted to wait for the next iteration, since I > know that Morteza has updates to make, based on comments. But yes, > here are my thoughts. >=20 > * I do think the charter is well thought out and well scoped, in = general. >=20 > * I am still concerned about the need to develop a new *protocol*, > rather than using or adapting existing protocols with new, > standardized schemas and uses. It's often the case that an > applicability statement on an existing protocol can do the job, and > I'd like to see that seriously considered *within the IETF context*. >=20 > * That said, something built on REST might, indeed, be the right > thing. At the risk of repeating: it's hard to know that without a > real analysis. And as I said in Paris, it's hard to do an objective > analysis when you already have the answer you want. I'm not sure how > to fix that, but I think we need to try. >=20 > * I worry that there's no consideration in the charter for security > aspects of this, other than to specifically *exclude* work on > authentication and authorization. It's probably good not to spin up > new mechanisms for these, but I'd like the charter to say something > about how the system *will* address issues of authentication, > authorization, access control, privacy, and integrity. >=20 > * The milestones are of course very fuzzy at this point, as they > should be. So I'll stick this in just as an early warning: having > five documents in active development in the working group at once is > probably not the best approach. I'm less interested in milestones for > adoption of drafts than I am about ones for completion of drafts, and > I expect WG chairs to make sure that the work gets started at an > appropriate time to have a good hope of meeting the completion > milestones. WGs too often set up too many things going on at once, > and then have trouble coordinating them. Be aware of that. >=20 >=20 > Back to the name just for a moment, since Mark said something I have > to respond to, which I think is an important point beyond rat-holing > on the name: >=20 >> If SCIM is renamed, it will negatively impact its success. >=20 > Really? OK, I know naming is marketing, and marketing is important. > I also know that this is a statement of one person's opinion, not > necessarily a point of consensus. But I suggest that if that's really > the case, there's a significant problem here. >=20 > If what comes out of this is a useful, well designed, and important > solution, it will be adopted, regardless of the name. If it *is* > useful, well designed, and important, and its name alone gets in the > way of adoption, then I think we have more problems than a standards > working group can solve, and I'm very much concerned. >=20 > You have an established group *outside* the IETF that's been working > on this. That's a beautiful thing; we like that. What you're trying > to do now is get people *within* the IETF to come work with you, to > finish and solidify it. Your marketing focus has shifted: you now > want to market to the IETF, to make sure you get the right people > involved. >=20 >> we are already seeing products adopt it. What message is sent to = adopters >> if we change the name? >=20 > We send the message that we thought there was a good reason to change > the name. That's all. It's happened in many cases, and in none of > them did it seriously bother anyone or significantly affect the > success of the result. >=20 > Barry > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From jeremy@palenchar.net Fri Apr 13 18:00: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 4B0B911E8113 for ; Fri, 13 Apr 2012 18:00:28 -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 I9zKsQEPm5Q7 for ; Fri, 13 Apr 2012 18:00:27 -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 20B5211E811C for ; Fri, 13 Apr 2012 18:00:20 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2264416pbb.31 for ; Fri, 13 Apr 2012 18:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=Gi41Rknzy8DX/fJzALNVjINKee9bwEOd9qm3d9Du4Is=; b=IadkLsd899mjjI5ccbS9HnIz3tagstirlHnmkM3tcj6w83hJwIdPf3TsiaE2aMt3NX 6zMOUftdRmeg4Fa5k69eC/jFN5gZ5QHdlgZl+2nBBK457e7Z1IKeVE7SR/xLPXzuWVm0 b557P8chZRFo5/kOijysk26LKtPBacC9FFFcdAIxwG9x+ma8WgXS9pNARNRPPLo79K0h 4p+5OVPwVsaKO+Ey2/+rF9EIdiKuUg1CWasGAZfLWEZ3KLqTivJ4wV4ZWYX10VTa7Ai3 8MFyjjOcykn4AtfrC3QGaqmAYMP9CFEBxYMMWmitnhpLTRbTFqGCP5AnLKwgQl5lOeUT VdaA== Received: by 10.68.135.226 with SMTP id pv2mr8558781pbb.148.1334365219839; Fri, 13 Apr 2012 18:00:19 -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 z7sm10157451pbk.63.2012.04.13.18.00.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 18:00:18 -0700 (PDT) From: "Jeremy Palenchar" To: "'Phil Hunt'" , "'Barry Leiba'" References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> In-Reply-To: <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> Date: Fri, 13 Apr 2012 18:02:07 -0700 Message-ID: <04af01cd19da$3854aa10$a8fdfe30$@palenchar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDGBu1qF0ZtcF3KPzO5ijA0d5dcOwHAuqrIAdTGtd0BvhxIOwEaQmP3mHQFx4A= Content-Language: en-us X-Gm-Message-State: ALoCoQlW7tXQasDirT119t8MdGLHOMUvmivFt/hhvhRZaZ8y139zCqow9xIsuQUTvD61cyS+XqIR Cc: scim@ietf.org, "'Morteza Ansari \(moransar\)'" , 'Eliot Lear' Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 14 Apr 2012 01:00:28 -0000 I vote for SCIM as an interface that allows for reads and writes. A read-only interface means that service providers would need to implement a separate interface to support writes. It would also mean that clients would need to have two channels for identity data - one for reading from a service and one for writing to the service. I don't see SCIM as a provisioning protocol, I see it as an API and core schema for a data endpoint that supports CRUD. The API allows for an endpoint to be configured in a read-only way which would result in your RAP. -Jeremy -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, April 13, 2012 2:58 PM To: Barry Leiba Cc: scim@ietf.org; Morteza Ansari (moransar); Eliot Lear Subject: Re: [scim] Draft charter - v7 +1 I agree with Barry, part of the objective of bringing SCIM to IETF is to engage a larger community. In my opinion that broader community has yet to join this potential WG. One of those communities is the members of the OASIS Provisioning TC. Members elected to idle that TC pending SCIMs move into IETF. Many of those members have yet to join this discussion as they are unsure about whether SCIM is to be a provisioning protocol. When we talk about consensus the group is somewhat skewed towards the perspectives of SPs and directories. The group may be making the same mistake that OASIS SPML made -- just in reverse. --> SPML emphasized the client role at the expense of the SP, while SCIIM emphasizes the service API at the expense of the client. I contend we need to look at this problem domain with *appropriate balance*. The current draft looks very much like a RESTful LDAP spec with updated schema (e.g. complex attributes) - in fact I understand that was the original objective. Much like you can do provisioning with LDAP, you can do provisioning with SCIM. However, from the perspective of a provisioning "system" client, you can use LDAP (or SCIM) as a connector, but neither LDAP nor SCIM are provisioning protocols (yet). I think the group should decide whether "provisioning" is an important objective going forwards. If the group is prepared to entertain SCIM being a provisioning protocol, I'm prepared to send another message shortly detailing issues that should be more broadly considered. We can then debate those topics on their merits. However, I have the strong sense the consensus is SCIM should be a RESTfull Access Protocol (RAP). Let me state then, that I can support EITHER direction. The case for SCIM/RAP is very STRONG. I've already run across several RESTful LDAP implementations. My own organization has a few. This alone makes a strong case for standardization. Based on supporting customers running LDAP on the open Internet for over 10 years, there are some lessons learned that can be applied to the spec with regards to attacks and error handling. But that won't need charter revisions. I see these as issues that will arise as we go through security considerations (see Melinda's message today). Does the group wish to exclude provisioning as an objective? I will support either direction. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-13, at 6:34 AM, Barry Leiba wrote: >> First, putting aside the name for a moment (we'll come back to that) >> what do you think of the REST of the charter (pun intended)? > > A fair question. I had wanted to wait for the next iteration, since I > know that Morteza has updates to make, based on comments. But yes, > here are my thoughts. > > * I do think the charter is well thought out and well scoped, in general. > > * I am still concerned about the need to develop a new *protocol*, > rather than using or adapting existing protocols with new, > standardized schemas and uses. It's often the case that an > applicability statement on an existing protocol can do the job, and > I'd like to see that seriously considered *within the IETF context*. > > * That said, something built on REST might, indeed, be the right > thing. At the risk of repeating: it's hard to know that without a > real analysis. And as I said in Paris, it's hard to do an objective > analysis when you already have the answer you want. I'm not sure how > to fix that, but I think we need to try. > > * I worry that there's no consideration in the charter for security > aspects of this, other than to specifically *exclude* work on > authentication and authorization. It's probably good not to spin up > new mechanisms for these, but I'd like the charter to say something > about how the system *will* address issues of authentication, > authorization, access control, privacy, and integrity. > > * The milestones are of course very fuzzy at this point, as they > should be. So I'll stick this in just as an early warning: having > five documents in active development in the working group at once is > probably not the best approach. I'm less interested in milestones for > adoption of drafts than I am about ones for completion of drafts, and > I expect WG chairs to make sure that the work gets started at an > appropriate time to have a good hope of meeting the completion > milestones. WGs too often set up too many things going on at once, > and then have trouble coordinating them. Be aware of that. > > > Back to the name just for a moment, since Mark said something I have > to respond to, which I think is an important point beyond rat-holing > on the name: > >> If SCIM is renamed, it will negatively impact its success. > > Really? OK, I know naming is marketing, and marketing is important. > I also know that this is a statement of one person's opinion, not > necessarily a point of consensus. But I suggest that if that's really > the case, there's a significant problem here. > > If what comes out of this is a useful, well designed, and important > solution, it will be adopted, regardless of the name. If it *is* > useful, well designed, and important, and its name alone gets in the > way of adoption, then I think we have more problems than a standards > working group can solve, and I'm very much concerned. > > You have an established group *outside* the IETF that's been working > on this. That's a beautiful thing; we like that. What you're trying > to do now is get people *within* the IETF to come work with you, to > finish and solidify it. Your marketing focus has shifted: you now > want to market to the IETF, to make sure you get the right people > involved. > >> we are already seeing products adopt it. What message is sent to >> adopters if we change the name? > > We send the message that we thought there was a good reason to change > the name. That's all. It's happened in many cases, and in none of > them did it seriously bother anyone or significantly affect the > success of the result. > > 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 phil.hunt@oracle.com Fri Apr 13 18:21: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 F2C8E21F86E0 for ; Fri, 13 Apr 2012 18:21:26 -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 3jk84GwoaJ4r for ; Fri, 13 Apr 2012 18:21:25 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id B9A9721F86DF for ; Fri, 13 Apr 2012 18:21:25 -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 q3E1LMFN001830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Apr 2012 01:21:23 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3E1LL9D012550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2012 01:21:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3E1LL4L007990; Fri, 13 Apr 2012 20:21:21 -0500 Received: from [25.64.209.9] (/74.198.150.137) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Apr 2012 18:19:46 -0700 MIME-Version: 1.0 Message-ID: Date: Fri, 13 Apr 2012 18:20:28 -0700 (PDT) From: Phil Hunt To: Jeremy Palenchar References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> <04af01cd19da$3854aa10$a8fdfe30$@palenchar.net> In-Reply-To: <04af01cd19da$3854aa10$a8fdfe30$@palenchar.net> X-Mailer: iPhone Mail (9B179) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090202.4F88D113.007A,ss=1,re=0.000,fgs=0 Cc: "scim@ietf.org" , Barry Leiba , "Morteza Ansari \(moransar\)" , EliotLear Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 14 Apr 2012 01:21:27 -0000 For clarification the r in rap stood for REST. :) Phil On 2012-04-13, at 18:02, Jeremy Palenchar wrote: > I vote for SCIM as an interface that allows for reads and writes. A > read-only interface means that service providers would need to implement a= > separate interface to support writes. It would also mean that clients woul= d > need to have two channels for identity data - one for reading from a servi= ce > and one for writing to the service. I don't see SCIM as a provisioning > protocol, I see it as an API and core schema for a data endpoint that > supports CRUD. The API allows for an endpoint to be configured in a > read-only way which would result in your RAP. >=20 >=20 > -Jeremy >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ph= il > Hunt > Sent: Friday, April 13, 2012 2:58 PM > To: Barry Leiba > Cc: scim@ietf.org; Morteza Ansari (moransar); Eliot Lear > Subject: Re: [scim] Draft charter - v7 >=20 > +1 >=20 > I agree with Barry, part of the objective of bringing SCIM to IETF is to > engage a larger community. In my opinion that broader community has yet to= > join this potential WG. One of those communities is the members of the OAS= IS > Provisioning TC. Members elected to idle that TC pending SCIMs move into > IETF. Many of those members have yet to join this discussion as they are > unsure about whether SCIM is to be a provisioning protocol. >=20 > When we talk about consensus the group is somewhat skewed towards the > perspectives of SPs and directories. The group may be making the same > mistake that OASIS SPML made -- just in reverse. --> SPML emphasized the > client role at the expense of the SP, while SCIIM emphasizes the service A= PI > at the expense of the client. I contend we need to look at this problem > domain with *appropriate balance*.=20 >=20 > The current draft looks very much like a RESTful LDAP spec with updated > schema (e.g. complex attributes) - in fact I understand that was the > original objective. Much like you can do provisioning with LDAP, you can d= o > provisioning with SCIM. However, from the perspective of a provisioning > "system" client, you can use LDAP (or SCIM) as a connector, but neither LD= AP > nor SCIM are provisioning protocols (yet). >=20 > I think the group should decide whether "provisioning" is an important > objective going forwards. If the group is prepared to entertain SCIM being= a > provisioning protocol, I'm prepared to send another message shortly > detailing issues that should be more broadly considered. We can then debat= e > those topics on their merits. However, I have the strong sense the > consensus is SCIM should be a RESTfull Access Protocol (RAP). >=20 > Let me state then, that I can support EITHER direction. The case for > SCIM/RAP is very STRONG. I've already run across several RESTful LDAP > implementations. My own organization has a few. This alone makes a strong > case for standardization. Based on supporting customers running LDAP on th= e > open Internet for over 10 years, there are some lessons learned that can b= e > applied to the spec with regards to attacks and error handling. But that > won't need charter revisions. I see these as issues that will arise as we g= o > through security considerations (see Melinda's message today). >=20 > Does the group wish to exclude provisioning as an objective? I will suppor= t > either direction. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-13, at 6:34 AM, Barry Leiba wrote: >=20 >>> First, putting aside the name for a moment (we'll come back to that)=20 >>> what do you think of the REST of the charter (pun intended)? >>=20 >> A fair question. I had wanted to wait for the next iteration, since I=20= >> know that Morteza has updates to make, based on comments. But yes,=20 >> here are my thoughts. >>=20 >> * I do think the charter is well thought out and well scoped, in general.= >>=20 >> * I am still concerned about the need to develop a new *protocol*,=20 >> rather than using or adapting existing protocols with new,=20 >> standardized schemas and uses. It's often the case that an=20 >> applicability statement on an existing protocol can do the job, and=20 >> I'd like to see that seriously considered *within the IETF context*. >>=20 >> * That said, something built on REST might, indeed, be the right=20 >> thing. At the risk of repeating: it's hard to know that without a=20 >> real analysis. And as I said in Paris, it's hard to do an objective=20 >> analysis when you already have the answer you want. I'm not sure how=20 >> to fix that, but I think we need to try. >>=20 >> * I worry that there's no consideration in the charter for security=20 >> aspects of this, other than to specifically *exclude* work on=20 >> authentication and authorization. It's probably good not to spin up=20 >> new mechanisms for these, but I'd like the charter to say something=20 >> about how the system *will* address issues of authentication,=20 >> authorization, access control, privacy, and integrity. >>=20 >> * The milestones are of course very fuzzy at this point, as they=20 >> should be. So I'll stick this in just as an early warning: having=20 >> five documents in active development in the working group at once is=20 >> probably not the best approach. I'm less interested in milestones for=20= >> adoption of drafts than I am about ones for completion of drafts, and=20 >> I expect WG chairs to make sure that the work gets started at an=20 >> appropriate time to have a good hope of meeting the completion=20 >> milestones. WGs too often set up too many things going on at once,=20 >> and then have trouble coordinating them. Be aware of that. >>=20 >>=20 >> Back to the name just for a moment, since Mark said something I have=20 >> to respond to, which I think is an important point beyond rat-holing=20 >> on the name: >>=20 >>> If SCIM is renamed, it will negatively impact its success. >>=20 >> Really? OK, I know naming is marketing, and marketing is important. >> I also know that this is a statement of one person's opinion, not=20 >> necessarily a point of consensus. But I suggest that if that's really=20= >> the case, there's a significant problem here. >>=20 >> If what comes out of this is a useful, well designed, and important=20 >> solution, it will be adopted, regardless of the name. If it *is*=20 >> useful, well designed, and important, and its name alone gets in the=20 >> way of adoption, then I think we have more problems than a standards=20 >> working group can solve, and I'm very much concerned. >>=20 >> You have an established group *outside* the IETF that's been working=20 >> on this. That's a beautiful thing; we like that. What you're trying=20 >> to do now is get people *within* the IETF to come work with you, to=20 >> finish and solidify it. Your marketing focus has shifted: you now=20 >> want to market to the IETF, to make sure you get the right people=20 >> involved. >>=20 >>> we are already seeing products adopt it. What message is sent to=20 >>> adopters if we change the name? >>=20 >> We send the message that we thought there was a good reason to change=20 >> the name. That's all. It's happened in many cases, and in none of=20 >> them did it seriously bother anyone or significantly affect the=20 >> success of the result. >>=20 >> Barry >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From jeremy@palenchar.net Fri Apr 13 20:20: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 1271921F86B2 for ; Fri, 13 Apr 2012 20:20:23 -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 wXiOp2bFUKgI for ; Fri, 13 Apr 2012 20:20:21 -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 8CFC021F86AF for ; Fri, 13 Apr 2012 20:20:21 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2338843pbb.31 for ; Fri, 13 Apr 2012 20:20:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=pIvw5vjVjWpux2/Qtz6LhwGEBZVCKa5ZqHilz/5Xb0M=; b=D7w9HMhFzuDge68CXS1lRkPwVixGMiyRMmv6gB7Ckrjmlyv2O+BQYezMCd4hno+jFW jA0xb51BvWH/TCqz/IlVZZlc6/+csD6ThOKoldzhUDuLh5+UKxhepvt/DLdevXtLOSyE NKf/GuQEn8jEc/d0LwlngnrPcguuJ4kSBhdqb83LwfQjq+GixDdmruIN2kNY9Ew96BE0 HOh6PlyT+Jnsjk4I9x2TplsFAesNBdG/aJyuPLw0DaIuTpxCKE1KnSz5mMsXDrL3wwWS rU7LVzF3sSk0pkNbDCjiorMQKSMrFtGhczeH6Splbr9WeDvO7sb+joTkB7DdIUJEyA1r pAvQ== Received: by 10.68.224.99 with SMTP id rb3mr9394683pbc.79.1334373621280; Fri, 13 Apr 2012 20:20:21 -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 b4sm10481798pbc.7.2012.04.13.20.20.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 20:20:20 -0700 (PDT) From: "Jeremy Palenchar" To: "'Phil Hunt'" References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> <04af01cd19da$3854aa10$a8fdfe30$@palenchar.net> In-Reply-To: Date: Fri, 13 Apr 2012 20:22:11 -0700 Message-ID: <04b001cd19ed$c85241f0$58f6c5d0$@palenchar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDGBu1qF0ZtcF3KPzO5ijA0d5dcOwHAuqrIAdTGtd0BvhxIOwEaQmP3Ap56HjAA8HXqk5hX46ng Content-Language: en-us X-Gm-Message-State: ALoCoQlsj05H5vgs+VSCa8cuLH47e7rbJEel6HktXo7NAbHvP6lKmanGqMKjn2pv3spavsq6MyeJ Cc: scim@ietf.org, 'Barry Leiba' , "'Morteza Ansari \(moransar\)'" , 'EliotLear' Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 14 Apr 2012 03:20:23 -0000 Understood, However, I understood you to be arguing against "provisioning" and to me, provisioning means creating entities, so a service that does not support provisioning would, in my mind, be read-only. Perhaps you could clarify the concept of a "provisioning protocol" which you seem to be leaning against vs. a data API and core schema which you seem to be leaning towards. -Jeremy -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Friday, April 13, 2012 6:20 PM To: Jeremy Palenchar Cc: Barry Leiba; scim@ietf.org; Morteza Ansari (moransar); EliotLear Subject: Re: [scim] Draft charter - v7 For clarification the r in rap stood for REST. :) Phil On 2012-04-13, at 18:02, Jeremy Palenchar wrote: > I vote for SCIM as an interface that allows for reads and writes. A > read-only interface means that service providers would need to > implement a separate interface to support writes. It would also mean > that clients would need to have two channels for identity data - one > for reading from a service and one for writing to the service. I don't > see SCIM as a provisioning protocol, I see it as an API and core > schema for a data endpoint that supports CRUD. The API allows for an > endpoint to be configured in a read-only way which would result in your RAP. > > > -Jeremy > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Friday, April 13, 2012 2:58 PM > To: Barry Leiba > Cc: scim@ietf.org; Morteza Ansari (moransar); Eliot Lear > Subject: Re: [scim] Draft charter - v7 > > +1 > > I agree with Barry, part of the objective of bringing SCIM to IETF is > to engage a larger community. In my opinion that broader community has > yet to join this potential WG. One of those communities is the members > of the OASIS Provisioning TC. Members elected to idle that TC pending > SCIMs move into IETF. Many of those members have yet to join this > discussion as they are unsure about whether SCIM is to be a provisioning protocol. > > When we talk about consensus the group is somewhat skewed towards the > perspectives of SPs and directories. The group may be making the same > mistake that OASIS SPML made -- just in reverse. --> SPML emphasized > the client role at the expense of the SP, while SCIIM emphasizes the > service API at the expense of the client. I contend we need to look > at this problem domain with *appropriate balance*. > > The current draft looks very much like a RESTful LDAP spec with > updated schema (e.g. complex attributes) - in fact I understand that > was the original objective. Much like you can do provisioning with > LDAP, you can do provisioning with SCIM. However, from the perspective > of a provisioning "system" client, you can use LDAP (or SCIM) as a > connector, but neither LDAP nor SCIM are provisioning protocols (yet). > > I think the group should decide whether "provisioning" is an important > objective going forwards. If the group is prepared to entertain SCIM > being a provisioning protocol, I'm prepared to send another message > shortly detailing issues that should be more broadly considered. We > can then debate those topics on their merits. However, I have the > strong sense the consensus is SCIM should be a RESTfull Access Protocol (RAP). > > Let me state then, that I can support EITHER direction. The case for > SCIM/RAP is very STRONG. I've already run across several RESTful LDAP > implementations. My own organization has a few. This alone makes a > strong case for standardization. Based on supporting customers running > LDAP on the open Internet for over 10 years, there are some lessons > learned that can be applied to the spec with regards to attacks and > error handling. But that won't need charter revisions. I see these as > issues that will arise as we go through security considerations (see Melinda's message today). > > Does the group wish to exclude provisioning as an objective? I will > support either direction. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-04-13, at 6:34 AM, Barry Leiba wrote: > >>> First, putting aside the name for a moment (we'll come back to that) >>> what do you think of the REST of the charter (pun intended)? >> >> A fair question. I had wanted to wait for the next iteration, since >> I know that Morteza has updates to make, based on comments. But yes, >> here are my thoughts. >> >> * I do think the charter is well thought out and well scoped, in general. >> >> * I am still concerned about the need to develop a new *protocol*, >> rather than using or adapting existing protocols with new, >> standardized schemas and uses. It's often the case that an >> applicability statement on an existing protocol can do the job, and >> I'd like to see that seriously considered *within the IETF context*. >> >> * That said, something built on REST might, indeed, be the right >> thing. At the risk of repeating: it's hard to know that without a >> real analysis. And as I said in Paris, it's hard to do an objective >> analysis when you already have the answer you want. I'm not sure how >> to fix that, but I think we need to try. >> >> * I worry that there's no consideration in the charter for security >> aspects of this, other than to specifically *exclude* work on >> authentication and authorization. It's probably good not to spin up >> new mechanisms for these, but I'd like the charter to say something >> about how the system *will* address issues of authentication, >> authorization, access control, privacy, and integrity. >> >> * The milestones are of course very fuzzy at this point, as they >> should be. So I'll stick this in just as an early warning: having >> five documents in active development in the working group at once is >> probably not the best approach. I'm less interested in milestones >> for adoption of drafts than I am about ones for completion of drafts, >> and I expect WG chairs to make sure that the work gets started at an >> appropriate time to have a good hope of meeting the completion >> milestones. WGs too often set up too many things going on at once, >> and then have trouble coordinating them. Be aware of that. >> >> >> Back to the name just for a moment, since Mark said something I have >> to respond to, which I think is an important point beyond rat-holing >> on the name: >> >>> If SCIM is renamed, it will negatively impact its success. >> >> Really? OK, I know naming is marketing, and marketing is important. >> I also know that this is a statement of one person's opinion, not >> necessarily a point of consensus. But I suggest that if that's >> really the case, there's a significant problem here. >> >> If what comes out of this is a useful, well designed, and important >> solution, it will be adopted, regardless of the name. If it *is* >> useful, well designed, and important, and its name alone gets in the >> way of adoption, then I think we have more problems than a standards >> working group can solve, and I'm very much concerned. >> >> You have an established group *outside* the IETF that's been working >> on this. That's a beautiful thing; we like that. What you're trying >> to do now is get people *within* the IETF to come work with you, to >> finish and solidify it. Your marketing focus has shifted: you now >> want to market to the IETF, to make sure you get the right people >> involved. >> >>> we are already seeing products adopt it. What message is sent to >>> adopters if we change the name? >> >> We send the message that we thought there was a good reason to change >> the name. That's all. It's happened in many cases, and in none of >> them did it seriously bother anyone or significantly affect the >> success of the result. >> >> 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 edreux@gmail.com Sun Apr 15 02:53:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E346F21F86F7 for ; Sun, 15 Apr 2012 02:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 lt9r0kZ09xYS for ; Sun, 15 Apr 2012 02:53:10 -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 27A4521F870A for ; Sun, 15 Apr 2012 02:53:05 -0700 (PDT) Received: by lagj5 with SMTP id j5so3529145lag.31 for ; Sun, 15 Apr 2012 02:53:05 -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; bh=60Pq2kMWchKAet8deAqgBsHyon8zDmx+MN+crosmo/s=; b=FIR8jJlH7HjamhAcPhJy1dDmHut4wvVyTOv6v77stKptNsINrL6wiguIFLp/g7wxEo MJ9KvSx5wNutoqV1gJ7g5zEKO7TQ+X9Ct+xt2LaYv6gUDeRmtWvRD9qWMUP+272A2L2v K9pS07ZmS5iSbNkRcOEOCuuAyfznc5s/ug5ef47lZuhEVQwNm5acCNanYz9LmP774M5B 5ayk+EE+HhfkqJ2F4IG5WFVBHV+EC8d+WEo/YqCjni0xUWn8zFV1+BV0eXeK81vznNzF nl1231vpUz+/7OLqNKDmVK1hj/7QncpnYaafATNEMVBhezxkg1iQtG76Q8RJOAViD1lm jeag== MIME-Version: 1.0 Received: by 10.112.9.200 with SMTP id c8mr3495192lbb.13.1334483585030; Sun, 15 Apr 2012 02:53:05 -0700 (PDT) Received: by 10.152.19.131 with HTTP; Sun, 15 Apr 2012 02:53:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 Apr 2012 11:53:04 +0200 Message-ID: From: Emmanuel Dreux To: scim@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe2a740b5a2e04bdb4ac7d X-Mailman-Approved-At: Sun, 15 Apr 2012 08:06:39 -0700 Subject: [scim] Fwd: Summary of issues with 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: Sun, 15 Apr 2012 13:59:23 -0000 --e0cb4efe2a740b5a2e04bdb4ac7d Content-Type: text/plain; charset=ISO-8859-1 Cross posting to scim@ietf.org as it's at the boarder of the discussion of what is SCIM (provisioning protocol / not provisioning protocol etc...) Here is my feedback (technical) based on our attempt to make our first implementation of SCIM. This leads us to think that in his current states SCIM cannot be reduced to the vision of a "provisioning protocol": It had strong dependancies with the target (allocation of uniqID that must never change) and might require modifications of the target in order to be able to provision the target (if we do not address that point in the spec) Therefore, we had (and still have to) to make important design decisions that are not described in the spec. Our first implementation is a blackbox system that indeed talks using REST api and indeed exchange objects on the wire using the XML/JSON defined schema. But it's also a system that maintains and allocate uniqueIdentifiers independantly of the target to be provisioned (For example we cannot rely on an Active Directory that sends us a uniqID that is subject to change if an admin makes evolution in his Active Directory infrastructure or if the user gets renamed or moved). This module of allocation of IDs (AllocID) has to provide identity translation services (what is the identity of {uniqID} in this target?). This is mandatory for groups/roles provisioning where SCIM sends you uniqIDs as groupMembership that you have to translate to CN to write to the LDAP directory. In order to no be intrusive in the target system (make modifications on it to store the uniqID), SCIM has to integrate an AllocID system and not simply be a "provisioning protocol" or or a definition of a User and Group schema in JSON and XML. This is my opinion after having tried to implement the first version of SCIM, and I submit it for discussion. ---------- Forwarded message ---------- From: Emmanuel Dreux Date: 2012/4/15 Subject: Summary of issues with SCIM To: cloud-directory@googlegroups.com Hi, here is a summary of the discussion we had at the interrop session. We're mainly using Active Directory as backend database on server side. Issue 1: Unique Identifier generation - It can't be the Active Directory ObjectGuid: --> If you make an Active Migration, this objectGuid changes, Consequence the uniqueIdentifier changes - Option: Extend Active Directory Schema and create an additional attribute to store the uniqueID (independant of AD infrastructure) --> One of our customer has 350 AD Forests. --> New customers will not accept to extend theit schema for our product - Use the DistinguishedName as unique Key. --> If I remember, this is the current option used by Trey's solution (I remember I have seen this in the server answer?) --> If a user is moved to a new OU, the DN changes. - Use the samAccountName --> If a person gets married/renamed, the samAccountName might change. - Maintain the uniqueID in a cache database out of the AD. --> This would be the better solution Issue 2: Group Synchronisation Member attributes contains the DN of users and groups membership Today we send the content of the member attribute as found in the source: we send the DN(s) of the source and make a DN translation in the target (CN=USER,OU=SOMEOU,DC=SOURCE,DC=COM => CN=USER,OU=SOMEOU,DC=Target,DC=COM) With SCIM, we will have to send the uniqueIdentifier of the object. First the source will have to make a DN to uniqID translation. Then, at the target, if we choose the last option of Issue 1, we'll have to maintain a table uniqueID/DN that we will lookup when updating group objects. When a user is moved (at the source but also at the target) , we'll have to updated this cache database as well to reflect the change of the DN. Issue 3: Async Mode (discussed in previous mail) If we refer to the discussions taking place in the IETF mailing list, SCIM cannot be "simply" seen as a provisioning protocol, as as you see, it cannot work AS IS for Active Directory provisioning and needs a complex external logic to work with AD. Conclusion : I can't imagine SCIM (as defined in the current state of the spec) as a simple provisioning protocol that could be integrated in any IAM/metadirectory platform in the form of a "simple" connector implementing the REST apis. Today, putting SCIM to provision an Active Directory/LDAP Server is challenging and requires non negligible external logic not defined in the specs. --e0cb4efe2a740b5a2e04bdb4ac7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cross posting to scim@ietf.org=A0= as it's at the boarder of the discussion of what is SCIM (provisioning = protocol / not provisioning protocol etc...)
=A0
Here is my feedback (technical) based on our attempt to make our first= implementation of SCIM.
This leads us to think that in his current states SCIM cannot be reduc= ed to the vision of a "provisioning protocol":
It had strong dependancies with the target (allocation of uniqID that = must never change) and might require modifications of the target in order t= o be able to provision the target (if we do not address that point in the s= pec)
=A0
Therefore, we had (and still have to) to make important design decisio= ns that are not described in the spec.
Our first implementation is=A0a blackbox system that indeed talks usin= g REST api and indeed exchange objects on the wire using the XML/JSON defin= ed schema.
But it's also a system=A0that maintains and allocate uniqueIdentif= iers independantly of the target to be provisioned (For example we cannot r= ely on an Active Directory that sends us=A0a uniqID that is subject to chan= ge if an admin makes evolution in his Active Directory infrastructure or if= the user gets renamed or moved).
This module of allocation of IDs (AllocID) has to provide identity tra= nslation services (what is the identity of {uniqID} in this target?). This = is mandatory for groups/roles provisioning where SCIM sends you=A0uniqIDs a= s groupMembership that you have to translate to=A0CN to write to=A0the LDAP= directory.
=A0
In order to no be intrusive in the target system (make modifications o= n it to store the uniqID), SCIM has to integrate an AllocID system and not = simply be a "provisioning protocol" or or=A0a definition of a Use= r and Group schema in JSON and XML.
=A0
This is my opinion after having tried to implement the first version o= f SCIM, and I submit it=A0for discussion.
=A0
---------- Forwarded message ----------
From:= Emmanuel Dreux <edreux@gmail.com>
Date: 2= 012/4/15
Subject: Summary of issues with SCIM
To: cloud-directory@googlegroups.com


Hi,
=A0
here is a summary of the discussion we had at the interrop session.
We're mainly using Active Directory as backend database on server = side.
=A0
Issue 1: Unique Identifier generation
- It can't be the Active Directory ObjectGuid:
=A0=A0=A0=A0=A0 --> If you make an Active Migration, this objectGui= d changes, Consequence the uniqueIdentifier changes
- Option: Extend Active Directory Schema and create an additional attr= ibute to store the uniqueID (independant of AD infrastructure)
=A0=A0=A0=A0 --> One of our customer has 350 AD Forests.
=A0=A0=A0=A0 --> New customers will not accept to extend theit sche= ma for our product
- Use the DistinguishedName as unique Key.
=A0=A0=A0=A0 --> If I remember, this is the current option used by = Trey's solution (I remember I have seen this in the server answer?)
=A0=A0=A0=A0 --> If a user is moved to a new OU, the DN changes.
-=A0 Use the samAccountName
=A0=A0=A0 --> If a person gets married/renamed, the samAccountName = might change.
- Maintain the uniqueID in a cache database out of the AD.
=A0=A0=A0=A0 --> This would be the better solution
=A0
Issue 2: Group Synchronisation
Member attributes contains the DN of users and groups membership
Today we send the content of the member attribute as found in the sour= ce: we send the DN(s) of the source and make a DN translation in the target= (CN=3DUSER,OU=3DSOMEOU,DC=3DSOURCE,DC=3DCOM =3D> CN=3DUSER,OU=3DSOMEOU,= DC=3DTarget,DC=3DCOM)
=A0
With SCIM, we will have to send the uniqueIdentifier of the object.
First the source will have to make a DN to uniqID translation.
Then, at the target, if we choose the last option of Issue 1, we'l= l have to maintain a table uniqueID/DN that we will lookup when updating gr= oup objects.
When a user is moved (at the source but also at the target) , we'l= l have to updated this cache database as well to reflect the change of the = DN.
=A0
Issue 3: Async Mode (discussed in previous mail)
=A0
If we refer to the discussions taking place in the IETF mailing list, = SCIM cannot be "simply" seen as a provisioning protocol, as as yo= u see, it cannot work AS IS for Active Directory provisioning and needs a c= omplex external logic to work with AD.
=A0
Conclusion : I can't imagine SCIM (as defined in the current state= of the spec)=A0as a simple provisioning protocol that could be integrated = in any IAM/metadirectory platform in the form of a "simple" conne= ctor implementing the REST apis.
Today, putting SCIM to provision an Active Directory/LDAP Server is ch= allenging and=A0requires non negligible external logic not defined in the s= pecs.

--e0cb4efe2a740b5a2e04bdb4ac7d-- From Tina.Tsou.Zouting@huawei.com Sun Apr 15 13:01: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 8B0FE21F87FD for ; Sun, 15 Apr 2012 13:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 cyR0xLw7qz3Q for ; Sun, 15 Apr 2012 13:01:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B0C3421F87E4 for ; Sun, 15 Apr 2012 13:01:41 -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 AEX97267; Sun, 15 Apr 2012 16:01:40 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:01:39 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:00:51 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 04:01:30 +0800 From: Tina TSOU To: Emmanuel Dreux Thread-Topic: [scim] Fwd: Summary of issues with SCIM Thread-Index: AQHNGxlnoEHIA30DqUaInVTZhprx25acTubV Date: Sun, 15 Apr 2012 20:01:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CACEED7850594F0182135C349A9E8DBDhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "scim@ietf.org" Subject: Re: [scim] Fwd: Summary of issues with 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: Sun, 15 Apr 2012 20:01:57 -0000 --_000_CACEED7850594F0182135C349A9E8DBDhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Emmanuel, IMHO, only JSON is sufficient. XML just adds head and tail to JSON. We don'= t need two sets. Sent from my iPad On Apr 15, 2012, at 8:06 AM, "Emmanuel Dreux" > wrote: Cross posting to scim@ietf.org as it's at the boarder= of the discussion of what is SCIM (provisioning protocol / not provisionin= g protocol etc...) Here is my feedback (technical) based on our attempt to make our first impl= ementation of SCIM. This leads us to think that in his current states SCIM cannot be reduced to= the vision of a "provisioning protocol": It had strong dependancies with the target (allocation of uniqID that must = never change) and might require modifications of the target in order to be = able to provision the target (if we do not address that point in the spec) Therefore, we had (and still have to) to make important design decisions th= at are not described in the spec. Our first implementation is a blackbox system that indeed talks using REST = api and indeed exchange objects on the wire using the XML/JSON defined sche= ma. But it's also a system that maintains and allocate uniqueIdentifiers indepe= ndantly of the target to be provisioned (For example we cannot rely on an A= ctive Directory that sends us a uniqID that is subject to change if an admi= n makes evolution in his Active Directory infrastructure or if the user get= s renamed or moved). This module of allocation of IDs (AllocID) has to provide identity translat= ion services (what is the identity of {uniqID} in this target?). This is ma= ndatory for groups/roles provisioning where SCIM sends you uniqIDs as group= Membership that you have to translate to CN to write to the LDAP directory. In order to no be intrusive in the target system (make modifications on it = to store the uniqID), SCIM has to integrate an AllocID system and not simpl= y be a "provisioning protocol" or or a definition of a User and Group schem= a in JSON and XML. This is my opinion after having tried to implement the first version of SCI= M, and I submit it for discussion. ---------- Forwarded message ---------- From: Emmanuel Dreux > Date: 2012/4/15 Subject: Summary of issues with SCIM To: cloud-directory@googlegroups.com Hi, here is a summary of the discussion we had at the interrop session. We're mainly using Active Directory as backend database on server side. Issue 1: Unique Identifier generation - It can't be the Active Directory ObjectGuid: --> If you make an Active Migration, this objectGuid changes, Consequ= ence the uniqueIdentifier changes - Option: Extend Active Directory Schema and create an additional attribute= to store the uniqueID (independant of AD infrastructure) --> One of our customer has 350 AD Forests. --> New customers will not accept to extend theit schema for our produ= ct - Use the DistinguishedName as unique Key. --> If I remember, this is the current option used by Trey's solution = (I remember I have seen this in the server answer?) --> If a user is moved to a new OU, the DN changes. - Use the samAccountName --> If a person gets married/renamed, the samAccountName might change. - Maintain the uniqueID in a cache database out of the AD. --> This would be the better solution Issue 2: Group Synchronisation Member attributes contains the DN of users and groups membership Today we send the content of the member attribute as found in the source: w= e send the DN(s) of the source and make a DN translation in the target (CN= =3DUSER,OU=3DSOMEOU,DC=3DSOURCE,DC=3DCOM =3D> CN=3DUSER,OU=3DSOMEOU,DC=3DTa= rget,DC=3DCOM) With SCIM, we will have to send the uniqueIdentifier of the object. First the source will have to make a DN to uniqID translation. Then, at the target, if we choose the last option of Issue 1, we'll have to= maintain a table uniqueID/DN that we will lookup when updating group objec= ts. When a user is moved (at the source but also at the target) , we'll have to= updated this cache database as well to reflect the change of the DN. Issue 3: Async Mode (discussed in previous mail) If we refer to the discussions taking place in the IETF mailing list, SCIM = cannot be "simply" seen as a provisioning protocol, as as you see, it canno= t work AS IS for Active Directory provisioning and needs a complex external= logic to work with AD. Conclusion : I can't imagine SCIM (as defined in the current state of the s= pec) as a simple provisioning protocol that could be integrated in any IAM/= metadirectory platform in the form of a "simple" connector implementing the= REST apis. Today, putting SCIM to provision an Active Directory/LDAP Server is challen= ging and requires non negligible external logic not defined in the specs. --_000_CACEED7850594F0182135C349A9E8DBDhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Emmanuel,
IMHO, only JSON is sufficient. XML just adds head and tail to JSON. We= don't need two sets.

Sent from my iPad

On Apr 15, 2012, at 8:06 AM, "Emmanuel Dreux" <edreux@gmail.com> wrote:

Cross posting to scim@ietf.org&nb= sp;as it's at the boarder of the discussion of what is SCIM (provisioning p= rotocol / not provisioning protocol etc...)
 
Here is my feedback (technical) based on our attempt to make our first= implementation of SCIM.
This leads us to think that in his current states SCIM cannot be reduc= ed to the vision of a "provisioning protocol":
It had strong dependancies with the target (allocation of uniqID that = must never change) and might require modifications of the target in order t= o be able to provision the target (if we do not address that point in the s= pec)
 
Therefore, we had (and still have to) to make important design decisio= ns that are not described in the spec.
Our first implementation is a blackbox system that indeed talks u= sing REST api and indeed exchange objects on the wire using the XML/JSON de= fined schema.
But it's also a system that maintains and allocate uniqueIdentifi= ers independantly of the target to be provisioned (For example we cannot re= ly on an Active Directory that sends us a uniqID that is subject to ch= ange if an admin makes evolution in his Active Directory infrastructure or if the user gets renamed or moved).
This module of allocation of IDs (AllocID) has to provide identity tra= nslation services (what is the identity of {uniqID} in this target?). This = is mandatory for groups/roles provisioning where SCIM sends you uniqID= s as groupMembership that you have to translate to CN to write to the LDAP directory.
 
In order to no be intrusive in the target system (make modifications o= n it to store the uniqID), SCIM has to integrate an AllocID system and not = simply be a "provisioning protocol" or or a definition of a = User and Group schema in JSON and XML.
 
This is my opinion after having tried to implement the first version o= f SCIM, and I submit it for discussion.
 
---------- Forwarded message ----------
From: Emmanuel Dreux &l= t;edreux@gmail.com>
Date: 2012/4/15
Subject: Summary of issues with SCIM
To: cloud-directory@goo= glegroups.com


Hi,
 
here is a summary of the discussion we had at the interrop session.
We're mainly using Active Directory as backend database on server side= .
 
Issue 1: Unique Identifier generation
- It can't be the Active Directory ObjectGuid:
      --> If you make an Active Migration,= this objectGuid changes, Consequence the uniqueIdentifier changes
- Option: Extend Active Directory Schema and create an additional attr= ibute to store the uniqueID (independant of AD infrastructure)
     --> One of our customer has 350 AD Forests= .
     --> New customers will not accept to exten= d theit schema for our product
- Use the DistinguishedName as unique Key.
     --> If I remember, this is the current opt= ion used by Trey's solution (I remember I have seen this in the server answ= er?)
     --> If a user is moved to a new OU, the DN= changes.
-  Use the samAccountName
    --> If a person gets married/renamed, the samAcc= ountName might change.
- Maintain the uniqueID in a cache database out of the AD.
     --> This would be the better solution
 
Issue 2: Group Synchronisation
Member attributes contains the DN of users and groups membership
Today we send the content of the member attribute as found in the sour= ce: we send the DN(s) of the source and make a DN translation in the target= (CN=3DUSER,OU=3DSOMEOU,DC=3DSOURCE,DC=3DCOM =3D> CN=3DUSER,OU=3DSOMEOU,= DC=3DTarget,DC=3DCOM)
 
With SCIM, we will have to send the uniqueIdentifier of the object.
First the source will have to make a DN to uniqID translation.
Then, at the target, if we choose the last option of Issue 1, we'll ha= ve to maintain a table uniqueID/DN that we will lookup when updating group = objects.
When a user is moved (at the source but also at the target) , we'll ha= ve to updated this cache database as well to reflect the change of the DN.<= /div>
 
Issue 3: Async Mode (discussed in previous mail)
 
If we refer to the discussions taking place in the IETF mailing list, = SCIM cannot be "simply" seen as a provisioning protocol, as as yo= u see, it cannot work AS IS for Active Directory provisioning and needs a c= omplex external logic to work with AD.
 
Conclusion : I can't imagine SCIM (as defined in the current state of = the spec) as a simple provisioning protocol that could be integrated i= n any IAM/metadirectory platform in the form of a "simple" connec= tor implementing the REST apis.
Today, putting SCIM to provision an Active Directory/LDAP Server is ch= allenging and requires non negligible external logic not defined in th= e specs.

--_000_CACEED7850594F0182135C349A9E8DBDhuaweicom_-- From melinda.shore@gmail.com Sun Apr 15 17:30: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 398AC21F88DA for ; Sun, 15 Apr 2012 17:30:40 -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 8PkwYEmYXyA4 for ; Sun, 15 Apr 2012 17:30:39 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C56BB21F88C8 for ; Sun, 15 Apr 2012 17:30:39 -0700 (PDT) Received: by dady13 with SMTP id y13so8497891dad.27 for ; Sun, 15 Apr 2012 17:30: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=ZYOocbLnDe67e79TnJWVdaBPqSzd55oqClVph8cF8sM=; b=SKvcLvvbrneZb16dUw0DJWlBmiM1ci6yNdPIUw+lD4hEHEefeeUSTKdd8jz+aqrv7F 77oRId5MrQJ+XifZRJUxiKkROVHWErvxJDdFdJ+XiTTm0GGNz7e1XM7EQldV6jpSAwtr MgVCioPOVmbTNhqPLZnd7IDW4IM8ipfL4Nua+1qhZn9VzXBNytiN627Jy7L4Sv2n2z4S 96a+iAAahy14iurCxvY+vKbQHny1rCXO9CHDzCskHsFfL+p/AOOIPgQ2sVU7StSXplZk oZrhC+S7YzqkdmS4dnXv6liqeYpGgoCDpK90NjUr1957upvwtPALBCt8xNLfF/oy/dwB 08mg== Received: by 10.68.221.102 with SMTP id qd6mr23528276pbc.36.1334536239661; Sun, 15 Apr 2012 17:30:39 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id qo2sm11522776pbb.15.2012.04.15.17.30.37 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 17:30:38 -0700 (PDT) Message-ID: <4F8B6829.3090500@gmail.com> Date: Sun, 15 Apr 2012 16:30:33 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 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] Fwd: Summary of issues with 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, 16 Apr 2012 00:30:40 -0000 On 4/15/12 1:53 AM, Emmanuel Dreux wrote: > This module of allocation of IDs (AllocID) has to provide identity > translation services (what is the identity of {uniqID} in this > target?). This is mandatory for groups/roles provisioning where SCIM > sends you uniqIDs as groupMembership that you have to translate to CN > to write to the LDAP directory. It seems to me that there are several ways to do this. You can convey some set of identities in a blob, in which case there needs to be changes to the schema and to the semantics, or you can do identityt mappings/translation in a bump in the {wire,stack} and with a wave of the hand declare it out-of-scope for scim. From the documents I haven't been able to get a handle on why uniqID needs to be unique for the purposes of scim. Melinda From radovan.semancik@evolveum.com Mon Apr 16 06:09: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 6B49D21F86B8 for ; Mon, 16 Apr 2012 06:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 3J8jg7JbAEdv for ; Mon, 16 Apr 2012 06:09:07 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7958121F86B7 for ; Mon, 16 Apr 2012 06:09:05 -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 51270A43DF6 for ; Mon, 16 Apr 2012 15:08:57 +0200 (CEST) Message-ID: <4F8C19E8.2010309@evolveum.com> Date: Mon, 16 Apr 2012 15:08:56 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 13:12:01 -0000 Hello, After reading the SCIM core specification I have compiled a list of issues, some of which I see as quite severe. I was encouraged by Travis Spencer to share the list here. So here it goes: There is externalId attribute for user. It may seems as a single attribute but it is not. In fact "The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant". Which means that the provider needs to store one value for every client. This is an extra state that has nothing to do with the provider itself. It is transfer of client's responsibility to server. Wrong application of separation of concerns principle. This is not even made optional. Therefore it will complicate all the server deployments, regardless if it is necessary or not. It looks like change of user's userName is not supported. This seems quite limiting to have two persistent identifiers for users (id and userName). Also, username changes are very common. If username is based on familyName it changes after most wedding for approximately half of the population. The familyName and givenName attributes have culture-neutral names. This is a nice take from FOAF. But the middleName is not that good. It enforces "american" point of view to the schema. Maybe "additionalName" would be more appropriate. User has displayName and also name/formatted attributes. It seems like these two are used for the same purpose? Or maybe it is displayName and userName? It looks like SCIM is following LDAP and SAP anti-patterns where users have just too many names to choose from. It is perhaps good for the entity that displays them, but terrible for the one that needs to manage that. The protocol should be more balanced in this aspect. User has nickName as a top-level attribute. But isn't a "name" complex attribute a better place for nickName? Especially considering the fact that nickname is frequently formatted as a part of full name. Does profileUrl represent application profile maintained by the application that is being provisioned? Or some other external profile? Should be "profileUrl" multivalued? The specification is not clear about that. User has title and userType in the core schema. But these seem to better fit into the "enterprise" extension. User has phoneNumbers, but no canonical phone number format is specified. This is limiting the usability of the specification especially in telco environment. The type meta-attribute in the multi-valued attributes is a plain string. This is prone to conflicts, especially in ims and similar "open" attributes. URL instead of plain string may be a better choice. And probably the most important one: Both groups and roles can be considered entitlements. The groups attribute is read-only, but it can be manipulated through Group Resource. Should such group also appear in entitlements user attribute? If it cannot than the correct name of that attribute should rather be "otherEntitlements" and the specification should make that clear. If it can then we have a redundancy: a group can be manipulated both through Group Resource and "entitlements" attribute. Similarly for roles. The specification does not specify if a role should only appear in "roles" and not in "entitlements" or can appear in both. The "SCIM Group Schema" also defines that roles may be represented as groups, which adds to the confusion. The ignorance of complexity of entitlement management was one of the time bombs in SPML. Not it is time bomb silently ticking in SCIM. The members attribute in group does not scale. Groups with thousands of members are very difficult to manage in this way. And it is typical that a group such as "Generic Employee" have more members than that, not even speaking about telcos. This is one of the common problems in LDAP and also in SCIM. There is also a corollary: creating a user as a member of a group requires two operations: add user, modify group. This complicates the implementation in case that the second operation fails. Should a provisioning system report that as a failure or success? User is created but not assigned to a group. Good provisioning system should handle that, but how many good provisioning systems are out there? Minor issue: Canonical types for members are capitalizes while other types start with lowercase letter. Should not authenticationSchema be outside of the SCIM core schema? Schema defines no transport protocol and the authentication types clearly depend on transport protocols. Maybe a binding specificiation is a better place for authenticationSchema definition? Resource schema has name attribute that obviously points to the object type. But it seems to be plain string. Namespace is not obvious here. If any SCIM extension adds a new object types (which seems likely) this may be very confusing. URL may be a better choice here. User has userName, displayName and name/formatted. Group has displayName. Resource has name as string. It is confusing. It is also quite inconsistent and makes if difficult to support uniform representation of "objects" in the underlying SCIM implementation. Resource Schema has description, but user and groups does not? Description may come handy in any object. Can endpoint in the Resource Schema be only relative? Or may it be absolute? Base URL is not a good concept, especially when it comes to different representations of the schema (e.g. see http://www.w3.org/2001/tag/doc/alternatives-discovery.html). The attributes/type definition in Resource Schema does not specify whether the value is URL or QName or plain string. If a plain string (which seems to be the case by looking at the examples) how to map that string to XSD QNames? Are only XSD data types possible? The specification says "SHOULD not" not "MUST NOT", therefore an extension mechanism should be specified here. The multiValuedAttributeChildName attribute and associated way how to represent data in XML seems to add to the redundancy of the data format. Strictly speaking, this one is also quite specific to XML and should not be in the generic core schema. When defining an attribute in a resource schema, how is attribute schema used? Is it a namespace that applies to attribute type? Or to the attribute name? Attribute has schema and sub-attribute does not? Why? Does it inherit it from parent? The specification should make that clear. Sub-attributes cannot have sub-attributes? If the type is mandatory for every multi-valued attribute (is "hardcoded" in the core schema specification), is there any point to define it explicitly in all the resource schemas? I have noticed meta attribute in the examples, but it looks like it is not defined in the specification. Is ordering of multi-value attribute values significant? Critical problems in JSON-like representations: as there are no namespaces in JSON, naming conflicts can happen. If two schemas define a "employeeNumber" attribute while one of them defines it as string and the other as number, such schemas cannot be used together. Is this a known limitation of SCIM? ( The original post is here: http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface ) -- Radovan Semancik Software Architect evolveum.com From kelly.grizzle@sailpoint.com Mon Apr 16 07:04: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 6E78621F870E for ; Mon, 16 Apr 2012 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bxIHt3syijCv for ; Mon, 16 Apr 2012 07:04:57 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25E21F862F for ; Mon, 16 Apr 2012 07:04:57 -0700 (PDT) Received: from mail71-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 14:04:56 +0000 Received: from mail71-am1 (localhost [127.0.0.1]) by mail71-am1-R.bigfish.com (Postfix) with ESMTP id 625741C01B3; Mon, 16 Apr 2012 14:04:56 +0000 (UTC) X-SpamScore: -42 X-BigFish: PS-42(zz9371I936eK542M1dbaL1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) 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 (mail71-am1: 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 mail71-am1 (localhost.localdomain [127.0.0.1]) by mail71-am1 (MessageSwitch) id 1334585095145735_9473; Mon, 16 Apr 2012 14:04:55 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.248]) by mail71-am1.bigfish.com (Postfix) with ESMTP id 1503E3C0043; Mon, 16 Apr 2012 14:04:55 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 14:04:51 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.53]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0143.004; Mon, 16 Apr 2012 14:04:50 +0000 From: Kelly Grizzle To: Jeremy Palenchar , 'Phil Hunt' Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AB309bwABRy4IAAC4w+AAAkpVOAABGSqYAABnIogAAApA8AAARAPIAAehUmEA== Date: Mon, 16 Apr 2012 14:04:49 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C676997@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> <1CC88DAE-7E06-4D8C-B26B-BAC3DCD975EC@oracle.com> <04af01cd19da$3854aa10$a8fdfe30$@palenchar.net> <04b001cd19ed$c85241f0$58f6c5d0$@palenchar.net> In-Reply-To: <04b001cd19ed$c85241f0$58f6c5d0$@palenchar.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , 'Barry Leiba' , "'Morteza Ansari \(moransar\)'" , 'EliotLear' Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 14:04:59 -0000 I have been discussing a RAP vs. provisioning API with Phil. The distincti= on is not a read vs. a write channel, but the use cases that are being solv= ed. A provisioning API would support use cases that are important to provi= sioning (aka - IdM) solutions, whereas the RAP concept addresses the single= identity use cases that have been the primary focus up until now. I actua= lly think there is a *lot* of overlap between the two, so I would like to s= ee this discussion/work happen in this group. Examples of "provisioning" use cases would be: - Support for more "operational" attributes, such as unlocking a user. - Support for targeting, which enables using SCIM as a gateway/hub to othe= r applications. - Deeper support for other IdM concepts, such as a schema around role defi= nitions. - etc... I can see all of these being very relevant for both provisioning solutions = and the current identity service providers. I don't think that all need to= necessarily be addressed in SCIM 2.0, but would like to include some of th= em in the conversation. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Jer= emy Palenchar Sent: Friday, April 13, 2012 10:22 PM To: 'Phil Hunt' Cc: scim@ietf.org; 'Barry Leiba'; 'Morteza Ansari (moransar)'; 'EliotLear' Subject: Re: [scim] Draft charter - v7 Understood, However, I understood you to be arguing against "provisioning" and to me, p= rovisioning means creating entities, so a service that does not support pro= visioning would, in my mind, be read-only. Perhaps you could clarify the concept of a "provisioning protocol" which yo= u seem to be leaning against vs. a data API and core schema which you seem = to be leaning towards. -Jeremy -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Friday, April 13, 2012 6:20 PM To: Jeremy Palenchar Cc: Barry Leiba; scim@ietf.org; Morteza Ansari (moransar); EliotLear Subject: Re: [scim] Draft charter - v7 For clarification the r in rap stood for REST. :) Phil On 2012-04-13, at 18:02, Jeremy Palenchar wrote: > I vote for SCIM as an interface that allows for reads and writes. A=20 > read-only interface means that service providers would need to=20 > implement a separate interface to support writes. It would also mean=20 > that clients would need to have two channels for identity data - one=20 > for reading from a service and one for writing to the service. I don't=20 > see SCIM as a provisioning protocol, I see it as an API and core=20 > schema for a data endpoint that supports CRUD. The API allows for an=20 > endpoint to be configured in a read-only way which would result in=20 > your RAP. >=20 >=20 > -Jeremy >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 > Of Phil Hunt > Sent: Friday, April 13, 2012 2:58 PM > To: Barry Leiba > Cc: scim@ietf.org; Morteza Ansari (moransar); Eliot Lear > Subject: Re: [scim] Draft charter - v7 >=20 > +1 >=20 > I agree with Barry, part of the objective of bringing SCIM to IETF is=20 > to engage a larger community. In my opinion that broader community has=20 > yet to join this potential WG. One of those communities is the members=20 > of the OASIS Provisioning TC. Members elected to idle that TC pending=20 > SCIMs move into IETF. Many of those members have yet to join this=20 > discussion as they are unsure about whether SCIM is to be a=20 > provisioning protocol. >=20 > When we talk about consensus the group is somewhat skewed towards the=20 > perspectives of SPs and directories. The group may be making the same=20 > mistake that OASIS SPML made -- just in reverse. --> SPML emphasized=20 > the client role at the expense of the SP, while SCIIM emphasizes the=20 > service API at the expense of the client. I contend we need to look=20 > at this problem domain with *appropriate balance*. >=20 > The current draft looks very much like a RESTful LDAP spec with=20 > updated schema (e.g. complex attributes) - in fact I understand that=20 > was the original objective. Much like you can do provisioning with=20 > LDAP, you can do provisioning with SCIM. However, from the perspective=20 > of a provisioning "system" client, you can use LDAP (or SCIM) as a=20 > connector, but neither LDAP nor SCIM are provisioning protocols (yet). >=20 > I think the group should decide whether "provisioning" is an important=20 > objective going forwards. If the group is prepared to entertain SCIM=20 > being a provisioning protocol, I'm prepared to send another message=20 > shortly detailing issues that should be more broadly considered. We=20 > can then debate those topics on their merits. However, I have the=20 > strong sense the consensus is SCIM should be a RESTfull Access=20 > Protocol (RAP). >=20 > Let me state then, that I can support EITHER direction. The case for=20 > SCIM/RAP is very STRONG. I've already run across several RESTful LDAP=20 > implementations. My own organization has a few. This alone makes a=20 > strong case for standardization. Based on supporting customers running=20 > LDAP on the open Internet for over 10 years, there are some lessons=20 > learned that can be applied to the spec with regards to attacks and=20 > error handling. But that won't need charter revisions. I see these as=20 > issues that will arise as we go through security considerations (see Melinda's message today). >=20 > Does the group wish to exclude provisioning as an objective? I will=20 > support either direction. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-13, at 6:34 AM, Barry Leiba wrote: >=20 >>> First, putting aside the name for a moment (we'll come back to that)=20 >>> what do you think of the REST of the charter (pun intended)? >>=20 >> A fair question. I had wanted to wait for the next iteration, since=20 >> I know that Morteza has updates to make, based on comments. But yes,=20 >> here are my thoughts. >>=20 >> * I do think the charter is well thought out and well scoped, in general= . >>=20 >> * I am still concerned about the need to develop a new *protocol*,=20 >> rather than using or adapting existing protocols with new,=20 >> standardized schemas and uses. It's often the case that an=20 >> applicability statement on an existing protocol can do the job, and=20 >> I'd like to see that seriously considered *within the IETF context*. >>=20 >> * That said, something built on REST might, indeed, be the right=20 >> thing. At the risk of repeating: it's hard to know that without a=20 >> real analysis. And as I said in Paris, it's hard to do an objective=20 >> analysis when you already have the answer you want. I'm not sure how=20 >> to fix that, but I think we need to try. >>=20 >> * I worry that there's no consideration in the charter for security=20 >> aspects of this, other than to specifically *exclude* work on=20 >> authentication and authorization. It's probably good not to spin up=20 >> new mechanisms for these, but I'd like the charter to say something=20 >> about how the system *will* address issues of authentication,=20 >> authorization, access control, privacy, and integrity. >>=20 >> * The milestones are of course very fuzzy at this point, as they=20 >> should be. So I'll stick this in just as an early warning: having=20 >> five documents in active development in the working group at once is=20 >> probably not the best approach. I'm less interested in milestones=20 >> for adoption of drafts than I am about ones for completion of drafts,=20 >> and I expect WG chairs to make sure that the work gets started at an=20 >> appropriate time to have a good hope of meeting the completion=20 >> milestones. WGs too often set up too many things going on at once,=20 >> and then have trouble coordinating them. Be aware of that. >>=20 >>=20 >> Back to the name just for a moment, since Mark said something I have=20 >> to respond to, which I think is an important point beyond rat-holing=20 >> on the name: >>=20 >>> If SCIM is renamed, it will negatively impact its success. >>=20 >> Really? OK, I know naming is marketing, and marketing is important. >> I also know that this is a statement of one person's opinion, not=20 >> necessarily a point of consensus. But I suggest that if that's=20 >> really the case, there's a significant problem here. >>=20 >> If what comes out of this is a useful, well designed, and important=20 >> solution, it will be adopted, regardless of the name. If it *is*=20 >> useful, well designed, and important, and its name alone gets in the=20 >> way of adoption, then I think we have more problems than a standards=20 >> working group can solve, and I'm very much concerned. >>=20 >> You have an established group *outside* the IETF that's been working=20 >> on this. That's a beautiful thing; we like that. What you're trying=20 >> to do now is get people *within* the IETF to come work with you, to=20 >> finish and solidify it. Your marketing focus has shifted: you now=20 >> want to market to the IETF, to make sure you get the right people=20 >> involved. >>=20 >>> we are already seeing products adopt it. What message is sent to=20 >>> adopters if we change the name? >>=20 >> We send the message that we thought there was a good reason to change=20 >> the name. That's all. It's happened in many cases, and in none of=20 >> them did it seriously bother anyone or significantly affect the=20 >> success of the result. >>=20 >> Barry >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From Chris.Phillips@canarie.ca Mon Apr 16 09:00:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD321F8731 for ; Mon, 16 Apr 2012 09:00:07 -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 JaO6rdsnrxCa for ; Mon, 16 Apr 2012 09:00:04 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8408021F8725 for ; Mon, 16 Apr 2012 09:00:04 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 16 Apr 2012 12:00:03 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Mon, 16 Apr 2012 12:00:02 -0400 Thread-Topic: About roles, entitlements, and groups, was ->Re: [scim] SCIM Issues Thread-Index: Ac0b6fvUgfuzmjenSZ6xUHtZAj0uDw== Message-ID: In-Reply-To: <4F8C19E8.2010309@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 16:00:07 -0000 Hi Radovan (and others), I've been lurking on the list and it's been great to see the depth that people are going to on SCIM. As the contributor for the core schema attributes entitlements and roles it's not about redundancy and 'can I fit one into the other' it is about 'can I preserve what is intended by roles, groups and entitlements?'. To do so needs all these fields. The original use cases about the differences expressed between groups, roles, and entitlements are here[1]. Summarized: Groups are things you belong to Roles are things you are (and implies the assignment of a collection of entitlements) Entitlements are things you have Implementing SCIM with the schema capable of representing these means not having to serialize one into the other and then trying to figure out on the other end what to de-serialize. SCIM is agnostic and preserves the fidelity of the information regardless of what you are doing with groups, roles, or entitlements. The spec does not constrain or exclude anything from any of those 3 fields because it shouldn't. Following a certain access control paradigm or consuming the attributes in a particular fashion once the values are delivered are up to the implementer to decide what to do next. Hope this helps... Chris. ___________________________________________________________________________ ________________ Chris Phillips=20 Technical Architect, Canadian Access Federation | CANARIE| chris.phillips@canarie.ca [1]http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6? On 12-04-16 9:08 AM, "Radovan Semancik" wrote: >And probably the most important one: Both groups and roles can be >considered entitlements. The groups attribute is read-only, but it can >be manipulated through Group Resource. Should such group also appear in >entitlements user attribute? If it cannot than the correct name of that >attribute should rather be "otherEntitlements" and the specification >should make that clear. If it can then we have a redundancy: a group can >be manipulated both through Group Resource and "entitlements" attribute. >Similarly for roles. The specification does not specify if a role should >only appear in "roles" and not in "entitlements" or can appear in both. >The "SCIM Group Schema" also defines that roles may be represented as >groups, which adds to the confusion. The ignorance of complexity of >entitlement management was one of the time bombs in SPML. Not it is time >bomb silently ticking in SCIM. From kelly.grizzle@sailpoint.com Mon Apr 16 09:35: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 011AB11E8091 for ; Mon, 16 Apr 2012 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vJizL4LeJ8K0 for ; Mon, 16 Apr 2012 09:35:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id E157011E80A5 for ; Mon, 16 Apr 2012 09:35:10 -0700 (PDT) Received: from mail100-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 16 Apr 2012 16:35:09 +0000 Received: from mail100-va3 (localhost [127.0.0.1]) by mail100-va3-R.bigfish.com (Postfix) with ESMTP id 43880202C9; Mon, 16 Apr 2012 16:35:09 +0000 (UTC) X-SpamScore: -29 X-BigFish: PS-29(zz9371I936eK542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) 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 (mail100-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=BL2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail100-va3 (localhost.localdomain [127.0.0.1]) by mail100-va3 (MessageSwitch) id 1334594107180534_22520; Mon, 16 Apr 2012 16:35:07 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.245]) by mail100-va3.bigfish.com (Postfix) with ESMTP id 1A7174C00A2; Mon, 16 Apr 2012 16:35:07 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 16:35:05 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.53]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0143.004; Mon, 16 Apr 2012 16:35:05 +0000 From: Kelly Grizzle To: "scim@ietf.org" , "Morteza Ansari (moransar)" Thread-Topic: [scim] Draft charter - v7 Thread-Index: Ac0WiEIInaDVvHkOTya4i11YPUxm1AB309bwAADKo3AAAmGTgADdvtKg Date: Mon, 16 Apr 2012 16:35:04 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C676B98@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C7@XMB-RCD-313.cisco.com> <4F867403.7000207@jjaimon.net> In-Reply-To: <4F867403.7000207@jjaimon.net> 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] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 16:35:12 -0000 Jaimon, I agree that in many cases things tend to be moving toward the consolidatio= n of identities into IdP's, however, I don't think this will be a full real= ity in the near-term (or maybe even the long-term). There are other effort= s that are addressing some of the four A's (SAML, OAuth, OpenID Connect, et= c...), so I don't think that SCIM needs to directly be aimed at the single = IdP scenario. While SCIM's read operations could be used to facilitate att= ribute exchange, this is not the core competency. There was a lot of lively debate at the BoF, but I think the biggest point = of agreement was that SCIM is addressing an important problem that needs to= be solved. Morteza's slides for the BoF do a good job of explaining the problem and wh= y current solutions don't work for certain scenarios. Check them out here:= http://www.ietf.org/proceedings/83/slides/slides-83-scim-3.pdf. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Jai= mon Jose Sent: Thursday, April 12, 2012 1:20 AM To: Morteza Ansari (moransar) Cc: scim@ietf.org Subject: Re: [scim] Draft charter - v7 I'm joining the discussion a little late. I searched through the threads a= nd decided to shoot this mail since I didn't find a satisfactory answer for= rationale behind the current charter. Please pardon me if the same has be= en debated earlier. The core of the WG seems to be to "design ......by defining standard = protocols and schemas for creating, reading/searching, modifying and deleti= ng user identities and identity-related objects across administrative domai= ns." I also noticed that the charter specifically called out that "definin= g new authentication and policy/authorization schemes" is considered outsid= e the scope. However, I"m wondering if the IDM as a domain is moving towards consolidati= on of identity services with a number of identity providers (social identit= y providers like google, facebook etc.) in addition to enterprise identitie= s, isn't it better to address how services or applications can consume iden= tities rather than expecting identities to be provisioned for each of those services. All that an application/service would require is the 4 A's (attributes, authentication,= authorization and audit) of identities. This way we will move away from t= he notion of "identity provisioning" to identifying ways and means to "secu= rely" consume identities across enterprise, private and public cloud entiti= es. As a side effect, enterprise identities will be safe within their prem= ise. Sorry if I'm way off track :-) Regards --jaimon Morteza Ansari (moransar) wrote, On 12-04-2012 10:42 AM: > Also, if I missed any other comments beyond these two please let me know. _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From radovan.semancik@evolveum.com Mon Apr 16 10:03: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 E890F11E80EC for ; Mon, 16 Apr 2012 10:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCKrpbnBquY3 for ; Mon, 16 Apr 2012 10:03:51 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2C11E80EA for ; Mon, 16 Apr 2012 10:03:50 -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 2E3B2A43E42 for ; Mon, 16 Apr 2012 19:03:49 +0200 (CEST) Message-ID: <4F8C50F4.6050002@evolveum.com> Date: Mon, 16 Apr 2012 19:03:48 +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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 17:03:52 -0000 Chris, As far as I understand the theory behind specifications, the specifications are always about constraining something. I understand that everything cannot be constrained, but the specification should go to the reasonable details. I was thinking how I would implement this particular piece of SCIM when I realized it can be implement in many different ways. And that somehow does not align with my understanding of "standard specification". The more ways is there to implement the same thing the lower is the probability that implementations will be interoperable. If the core schema cannot specify this part in sufficient detail then maybe it should be moved into an (experimental) extension? Regarding the explanation: there is a very fuzzy boundary between "what I am" and "what I have". E.g. the same thing can be expressed as both: "I am system administrator" and "I have the right to do system administration". It also can be expressed as group "I am a member of the 'admin' group". Therefore these concepts may significantly overlap. Which is not a bad thing per se and I guess that every system will figure a way how to represent them in SCIM. But because these concepts overlap, there should be a clear specification how they should be represented in SCIM. E.g. explicitly state whether "entitlements", "roles" and "groups" MAY or MUST NOT contain representation of the same entity (are overlapping or disjoint sets) at the very minimum. Otherwise this will not lead to interoperable implementations and the whole point of standardizing these aspects is pointless. And there yet another level of complexity here: extensions. Groups have its own object now. Why roles and entitlements do not have that? Is it expected to come in the future? Or be defined as per-deployment extension? If that is the case, can an extension define a sub-class of entitlements, e.g. "Privileges". How will the logic work in that case? E.g. a "privilege" should then also appear in entitlements, but roles and groups should not? This is a very tricky part. I guess that the best approach here would be to base the specification on a sound formal model. -- Radovan Semancik Software Architect evolveum.com On 04/16/2012 06:00 PM, Chris Phillips wrote: > Hi Radovan (and others), > > I've been lurking on the list and it's been great to see the depth that > people are going to on SCIM. > > As the contributor for the core schema attributes entitlements and roles > it's not about redundancy and 'can I fit one into the other' it is about > 'can I preserve what is intended by roles, groups and entitlements?'. To > do so needs all these fields. > > The original use cases about the differences expressed between groups, > roles, and entitlements are here[1]. > > Summarized: > Groups are things you belong to > Roles are things you are (and implies the assignment of a collection of > entitlements) > Entitlements are things you have > > > > Implementing SCIM with the schema capable of representing these means not > having to serialize one into the other and then trying to figure out on > the other end what to de-serialize. SCIM is agnostic and preserves the > fidelity of the information regardless of what you are doing with groups, > roles, or entitlements. > > The spec does not constrain or exclude anything from any of those 3 fields > because it shouldn't. Following a certain access control paradigm or > consuming the attributes in a particular fashion once the values are > delivered are up to the implementer to decide what to do next. > > Hope this helps... From stpeter@stpeter.im Mon Apr 16 10:40: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 7EF6111E80AB for ; Mon, 16 Apr 2012 10:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 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 rtDWHrsjBwRr for ; Mon, 16 Apr 2012 10:40:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8836C11E809C for ; Mon, 16 Apr 2012 10:40:16 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8820F4005B; Mon, 16 Apr 2012 11:54:23 -0600 (MDT) Message-ID: <4F8C597E.2040609@stpeter.im> Date: Mon, 16 Apr 2012 11:40:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F873572.9060205@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" , Eliot Lear Subject: Re: [scim] Draft charter - v7 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 17:40:17 -0000 On 4/13/12 7:34 AM, Barry Leiba wrote: >> First, putting aside the name for a moment (we'll come back to that) >> what do you think of the REST of the charter (pun intended)? > > A fair question. I had wanted to wait for the next iteration, since I > know that Morteza has updates to make, based on comments. But yes, > here are my thoughts. > > * I do think the charter is well thought out and well scoped, in general. > > * I am still concerned about the need to develop a new *protocol*, > rather than using or adapting existing protocols with new, > standardized schemas and uses. It's often the case that an > applicability statement on an existing protocol can do the job, and > I'd like to see that seriously considered *within the IETF context*. We had similar debates during formation of the PAWS WG. See for instance its original charter: http://trac.tools.ietf.org/wg/paws/charters?item=charter-paws-2011-06-14.txt Here is some of the relevant text: ### The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize query and response formats to be carried over the database access method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. ### Something along those lines (but briefer) might be appropriate. > * That said, something built on REST might, indeed, be the right > thing. At the risk of repeating: it's hard to know that without a > real analysis. And as I said in Paris, it's hard to do an objective > analysis when you already have the answer you want. I'm not sure how > to fix that, but I think we need to try. I think we also need to try to respect the fact that there are half a dozen or more existing implementations, which is different from the PAWS case. Running code still counts for something, and building upon HTTP seems like a perfectly fine thing to do here (it's not as if folks are thinking about designing a completely new application protocols, which I'd agree would be crazy). In particular, Barry, what would you expect the results of a more detailed analysis to look like here? > * I worry that there's no consideration in the charter for security > aspects of this, other than to specifically *exclude* work on > authentication and authorization. It's probably good not to spin up > new mechanisms for these, but I'd like the charter to say something > about how the system *will* address issues of authentication, > authorization, access control, privacy, and integrity. Something along the lines of what was included in the original OAuth charter seems appropriate: * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. http://trac.tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt Naturally, everything in the IETF undergoes security review, so a short statement seems sufficient. As to the name, although I'm no fan of buzzwords in protocol names, I personally see no active harm in continuity here. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Apr 16 10:44: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 2056D11E80AB for ; Mon, 16 Apr 2012 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 AZf29WrBIp3q for ; Mon, 16 Apr 2012 10:44:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 862CF11E80A6 for ; Mon, 16 Apr 2012 10:44:51 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 84A3E4005B; Mon, 16 Apr 2012 11:58:58 -0600 (MDT) Message-ID: <4F8C5A91.6090508@stpeter.im> Date: Mon, 16 Apr 2012 11:44:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Melinda Shore References: <4F887DE5.6000403@gmail.com> <4F889E64.2060608@gmail.com> In-Reply-To: <4F889E64.2060608@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Security considerations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 17:44:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/13/12 3:45 PM, Melinda Shore wrote: > On 4/13/12 1:09 PM, Barry Leiba wrote: >> Mostly, yes... but it's very easy to put a sentence in a charter >> that says, "The working group will address security-related >> issues," and it doesn't really say much, does it? The charter >> won't have answers, of course, but I'd like to see that there was >> *some* thought put into it, and that there isn't just a sentence >> in there to make a few ADs smile. > > What about something along the lines of: > > "Given both the sensitivity of the information being conveyed in > scim (or whatever) messages and the regulatory requirements around > the privacy of personally identifiable information, the working > group will pay particular attention to issues around authenticity > and privacy, in addition to the usual requirements around security > consideration." > > I've been involved with working groups where there was very > explicit language around security in the charter, mostly to mollify > the IESG, and where ultimately the working group punted, and I'll > bet you have, too. In the end it comes down to the working group. IMHO it also comes down to security review both within the WG and the broader IETF community. A protocol without any security features just isn't going to pass muster with the SecDir, ADs, etc. > As an aside I'd hate to see "Just use oauth bearer tokens" join > "just use TLS" and "just use ipsec" on the heap of unthoughtful/ > uninteroperable security text. Indeed. Your proposed text looks good to me. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MWpEACgkQNL8k5A2w/vzjkQCg3KqU4eR1/8rCewkp2oyFohyq FckAoIkNcGs8E2M+6AsEROdgXIR2nUsC =8a+R -----END PGP SIGNATURE----- From michael.hammer@yaanatech.com Mon Apr 16 10:47: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 0125E21F8760 for ; Mon, 16 Apr 2012 10:47: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 tfdChJVglneL for ; Mon, 16 Apr 2012 10:47:30 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id CE54021F873E for ; Mon, 16 Apr 2012 10:47:30 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 16 Apr 2012 10:47:30 -0700 From: Michael Hammer To: "radovan.semancik@evolveum.com" , "scim@ietf.org" Thread-Topic: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues Thread-Index: AQHNG+oM9l1O9sZr60yWJY7suBOCy5aeI0wA//+UxdA= Date: Mon, 16 Apr 2012 17:47:29 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389F63B@EX2K10MB1.corp.yaanatech.com> References: <4F8C50F4.6050002@evolveum.com> In-Reply-To: <4F8C50F4.6050002@evolveum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.17] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0097_01CD1BD7.7693F8E0" MIME-Version: 1.0 Subject: Re: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 16 Apr 2012 17:47:32 -0000 ------=_NextPart_000_0097_01CD1BD7.7693F8E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hmmm... It sounds like roles are a collection of entitlements, while a group is a collection of individuals. (Not sure what a "you" is.) It would then seem that roles/entitlements could be assigned to either individuals or groups. Can we then infer that a binding of individual to a group also leads to indirect binding to roles assigned to group, and further to entitlements assigned to roles? Seems like a lot can get inherited with recursive checks of bindings. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Radovan Semancik Sent: Monday, April 16, 2012 1:04 PM To: scim@ietf.org Subject: Re: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues Chris, As far as I understand the theory behind specifications, the specifications are always about constraining something. I understand that everything cannot be constrained, but the specification should go to the reasonable details. I was thinking how I would implement this particular piece of SCIM when I realized it can be implement in many different ways. And that somehow does not align with my understanding of "standard specification". The more ways is there to implement the same thing the lower is the probability that implementations will be interoperable. If the core schema cannot specify this part in sufficient detail then maybe it should be moved into an (experimental) extension? Regarding the explanation: there is a very fuzzy boundary between "what I am" and "what I have". E.g. the same thing can be expressed as both: "I am system administrator" and "I have the right to do system administration". It also can be expressed as group "I am a member of the 'admin' group". Therefore these concepts may significantly overlap. Which is not a bad thing per se and I guess that every system will figure a way how to represent them in SCIM. But because these concepts overlap, there should be a clear specification how they should be represented in SCIM. E.g. explicitly state whether "entitlements", "roles" and "groups" MAY or MUST NOT contain representation of the same entity (are overlapping or disjoint sets) at the very minimum. Otherwise this will not lead to interoperable implementations and the whole point of standardizing these aspects is pointless. And there yet another level of complexity here: extensions. Groups have its own object now. Why roles and entitlements do not have that? Is it expected to come in the future? Or be defined as per-deployment extension? If that is the case, can an extension define a sub-class of entitlements, e.g. "Privileges". How will the logic work in that case? E.g. a "privilege" should then also appear in entitlements, but roles and groups should not? This is a very tricky part. I guess that the best approach here would be to base the specification on a sound formal model. -- Radovan Semancik Software Architect evolveum.com On 04/16/2012 06:00 PM, Chris Phillips wrote: > Hi Radovan (and others), > > I've been lurking on the list and it's been great to see the depth > that people are going to on SCIM. > > As the contributor for the core schema attributes entitlements and > roles it's not about redundancy and 'can I fit one into the other' it > is about 'can I preserve what is intended by roles, groups and > entitlements?'. To do so needs all these fields. > > The original use cases about the differences expressed between groups, > roles, and entitlements are here[1]. > > Summarized: > Groups are things you belong to > Roles are things you are (and implies the assignment of a collection > of > entitlements) > Entitlements are things you have > > > > Implementing SCIM with the schema capable of representing these means > not having to serialize one into the other and then trying to figure > out on the other end what to de-serialize. SCIM is agnostic and > preserves the fidelity of the information regardless of what you are > doing with groups, roles, or entitlements. > > The spec does not constrain or exclude anything from any of those 3 > fields because it shouldn't. Following a certain access control > paradigm or consuming the attributes in a particular fashion once the > values are delivered are up to the implementer to decide what to do next. > > Hope this helps... _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0097_01CD1BD7.7693F8E0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NjE3NDcyOFowIwYJKoZIhvcNAQkEMRYEFJmXXqrE1UmFcqjHbgLW7k359clUMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAX1wjq8dmhZPqD24SWc2lYtMtLeZ4CC4nvcbLoNbF+aM6 DUj9ZW3x6bW+CX2yWVLbk70vpzpjpyMLh+tduPuiUIEzqFhEU1Wytx2Aw7zYafDjsQ3uR9tZzSnL XV1GMPB2s9e9WZFMaAU7I0uUbGGzt886kN7yynwai7Xo9k/FTAsAAAAAAAA= ------=_NextPart_000_0097_01CD1BD7.7693F8E0-- From samuel@erdtman.se Mon Apr 16 22:09:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B274321F860D for ; Mon, 16 Apr 2012 22:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 NXKTaeuZoTi4 for ; Mon, 16 Apr 2012 22:09:48 -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 EA22621F8618 for ; Mon, 16 Apr 2012 22:09:47 -0700 (PDT) Received: by lagj5 with SMTP id j5so4842067lag.31 for ; Mon, 16 Apr 2012 22:09:46 -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=vXN2XbzdkbQWE4dCLV2+Qy1sOK1u1PFQahN7H8wQRH0=; b=LWVN5eC+tKAYvNJJz4gJcwDMqnBcyREMhGN3DyCSrZ2AhszSYj8gYTY4W+RrawktiG xrblhgRUsmUyQqOwt4o4RF4T6WLkOImNW85ALNmMo8XNHRfy6p3SD43AWYE4NsVb3ZKM +KV3svnjTSZbn5B/NyzXxuDfv6bnJqTuFTI2Zv6xRPDXPsnlb3QVpcD5Djtn3L6farkU FrjbhpnvzcLoVJXpbeZzKn7E3agvbDJW20WrWHCVaidVw78ZJNKCiI/9OwSzwRAv1qQn Ol2EA1l1/VKdrEJbEKtoY0SjDNS4L7qHq1ypcxsGiWRWwv2aKtU94+FkJ+RhEEjAh4fB EqmQ== MIME-Version: 1.0 Received: by 10.152.148.9 with SMTP id to9mr7153291lab.6.1334639386433; Mon, 16 Apr 2012 22:09:46 -0700 (PDT) Received: by 10.112.84.106 with HTTP; Mon, 16 Apr 2012 22:09:46 -0700 (PDT) In-Reply-To: <4F8C19E8.2010309@evolveum.com> References: <4F8C19E8.2010309@evolveum.com> Date: Tue, 17 Apr 2012 07:09:46 +0200 Message-ID: From: Samuel Erdtman To: Radovan Semancik Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncXzWIZDq2xaxrIdMcpRnqNZZjsh+0fIf8ohRZ8y7cIUgZuXM6jIcDS/ndJeFtwqx+EU2H Cc: scim@ietf.org Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 05:09:53 -0000 Thanx for lots of good comments, I have inlined some thoughts, answers, and questions. The questions I have not touched is mainly because I have no good answer. Cheers //Samuel On Mon, Apr 16, 2012 at 3:08 PM, Radovan Semancik wrote: > Hello, > > After reading the SCIM core specification I have compiled a list of issue= s, > some of which I see as quite severe. I was encouraged by Travis Spencer t= o > share the list here. So here it goes: > > There is externalId attribute for user. It may seems as a single attribut= e > but it is not. In fact "The Service Provider MUST always interpret the > externalId as scoped to the Service Consumer's tenant". Which means that = the > provider needs to store one value for every client. This is an extra stat= e > that has nothing to do with the provider itself. It is transfer of client= 's > responsibility to server. Wrong application of separation of concerns > principle. This is not even made optional. Therefore it will complicate a= ll > the server deployments, regardless if it is necessary or not. externalId is not mandatory as far as I know. Are there aspects that I miss here? > > It looks like change of user's userName is not supported. This seems quit= e > limiting to have two persistent identifiers for users (id and userName). > Also, username changes are very common. If username is based on familyNam= e > it changes after most wedding for approximately half of the population. Does really userName change, sure you do change name and userName is often coupled to that but to me it seems like the username is not changed anyway. I have one colleague that change both family name and given name but the account did not change userName, but he got a new account. Further, in the case of an email provider a username could be saerd@mail.com but I do not think that it would change if my name changed (same for my Facebook login). The difference between userName and id is that username is assigned by the service consumer (client) and the id is assigned by the service provider (in this case externalId might be more redundant in relation to userName). > > The familyName and givenName attributes have culture-neutral names. This = is > a nice take from FOAF. But the middleName is not that good. It enforces > "american" point of view to the schema. Maybe "additionalName" would be m= ore > appropriate. I do not thing that middleName/additionalName is a big deal but good point. to be fully compliant with the global view might we also the need to make it multiValued for situations where more then one is common? > > User has displayName and also name/formatted attributes. It seems like th= ese > two are used for the same purpose? Or maybe it is displayName and userNam= e? > It looks like SCIM is following LDAP and SAP anti-patterns where users ha= ve > just too many names to choose from. It is perhaps good for the entity tha= t > displays them, but terrible for the one that needs to manage that. The > protocol should be more balanced in this aspect. Interesting > > User has nickName as a top-level attribute. But isn't a "name" complex > attribute a better place for nickName? Especially considering the fact th= at > nickname is frequently formatted as a part of full name. Good point > > Does profileUrl represent application profile maintained by the applicati= on > that is being provisioned? Or some other external profile? Should be > "profileUrl" multivalued? The specification is not clear about that. Specification puts profileUrl under singular attributes, i.e. not multiValued. The kind url seems complex to specify, by not specifying we giving the client the option to select. > > User has title and userType in the core schema. But these seem to better = fit > into the "enterprise" extension. > > User has phoneNumbers, but no canonical phone number format is specified. > This is limiting the usability of the specification especially in telco > environment. Really good point, any suggestions on global phone number formats? Would E.164 be a good choice? > > The type meta-attribute in the multi-valued attributes is a plain string. > This is prone to conflicts, especially in ims and similar "open" attribut= es. > URL instead of plain string may be a better choice. > > And probably the most important one: Both groups and roles can be conside= red > entitlements. The groups attribute is read-only, but it can be manipulate= d > through Group Resource. Should such group also appear in entitlements use= r > attribute? If it cannot than the correct name of that attribute should > rather be "otherEntitlements" and the specification should make that clea= r. > If it can then we have a redundancy: a group can be manipulated both thro= ugh > Group Resource and "entitlements" attribute. Similarly for roles. The > specification does not specify if a role should only appear in "roles" an= d > not in "entitlements" or can appear in both. The "SCIM Group Schema" also > defines that roles may be represented as groups, which adds to the > confusion. The ignorance of complexity of entitlement management was one = of > the time bombs in SPML. Not it is time bomb silently ticking in SCIM. > > The members attribute in group does not scale. Groups with thousands of > members are very difficult to manage in this way. And it is typical that = a > group such as "Generic Employee" have more members than that, not even > speaking about telcos. This is one of the common problems in LDAP and als= o > in SCIM. There is also a corollary: creating a user as a member of a grou= p > requires two operations: add user, modify group. This complicates the > implementation in case that the second operation fails. Should a > provisioning system report that as a failure or success? User is created = but > not assigned to a group. Good provisioning system should handle that, but > how many good provisioning systems are out there? To create a user that is member of a group is a problem and it comes down to groups being read-only. The reason for groups being read-only is because the groups attribute may contain memberships that are inherited and dynamic which would make it problematic to remove a membership from a user this way. However this problem has been discussed and e.g. Salesforce needs a group on a user when it is created. A solution might be to remove read-only from groups and add some language on how to handle inherited and dynamic groups. Could you elaborate on the issue with very large groups? You can add and remove single users with PATCH? > > Minor issue: Canonical types for members are capitalizes while other type= s > start with lowercase letter. Good catch, it might be a legacy from the time when the endpoints where called User and Group and not Users and Groups. > > Should not authenticationSchema be outside of the SCIM core schema? Schem= a > defines no transport protocol and the authentication types clearly depend= on > transport protocols. Maybe a binding specificiation is a better place for > authenticationSchema definition? > > Resource schema has name attribute that obviously points to the object ty= pe. > But it seems to be plain string. Namespace is not obvious here. If any SC= IM > extension adds a new object types (which seems likely) this may be very > confusing. URL may be a better choice here. > > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite inconsiste= nt > and makes if difficult to support uniform representation of "objects" in = the > underlying SCIM implementation. > > Resource Schema has description, but user and groups does not? Descriptio= n > may come handy in any object. > > Can endpoint in the Resource Schema be only relative? Or may it be absolu= te? > Base URL is not a good concept, especially when it comes to different > representations of the schema (e.g. see > http://www.w3.org/2001/tag/doc/alternatives-discovery.html). > > The attributes/type definition in Resource Schema does not specify whethe= r > the value is URL or QName or plain string. If a plain string (which seems= to > be the case by looking at the examples) how to map that string to XSD > QNames? Are only XSD data types possible? The specification says "SHOULD > not" not "MUST NOT", therefore an extension mechanism should be specified > here. > > The multiValuedAttributeChildName attribute and associated way how to > represent data in XML seems to add to the redundancy of the data format. > Strictly speaking, this one is also quite specific to XML and should not = be > in the generic core schema. > > When defining an attribute in a resource schema, how is attribute schema > used? Is it a namespace that applies to attribute type? Or to the attribu= te > name? Attribute has schema and sub-attribute does not? Why? Does it inher= it > it from parent? The specification should make that clear. > > Sub-attributes cannot have sub-attributes? Yes, this was a chosen limitation, is it bad? One reason for the choice might have been that mapping to flat structures gets harder for every layer, e.g. there is work done on both LDAP and SAML mappings. > > If the type is mandatory for every multi-valued attribute (is "hardcoded"= in > the core schema specification), is there any point to define it explicitl= y > in all the resource schemas? Could you be more specific around hardcoded? > > I have noticed meta attribute in the examples, but it looks like it is no= t > defined in the specification. Meta attribute is defined here http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor2 > > Is ordering of multi-value attribute values significant? No, multivalued attributes are unordered. This has made mapping to e.g. SAML harder. > > Critical problems in JSON-like representations: as there are no namespace= s > in JSON, naming conflicts can happen. If two schemas define a > "employeeNumber" attribute while one of them defines it as string and the > other as number, such schemas cannot be used together. Is this a known > limitation of SCIM? This is only a problem if both extensions has the same urn, see example bel= ow: { "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], "userName": "kalle", "ext1": { employeeNumber: "abc123" }, "ext2": { employeeNumber: "123abc" } } > > ( The original post is here: > http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface ) > > -- > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Radovan Semancik > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Software Architect > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 evolveum.com > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim On Mon, Apr 16, 2012 at 3:08 PM, Radovan Semancik wrote: > Hello, > > After reading the SCIM core specification I have compiled a list of issue= s, > some of which I see as quite severe. I was encouraged by Travis Spencer t= o > share the list here. So here it goes: > > There is externalId attribute for user. It may seems as a single attribut= e > but it is not. In fact "The Service Provider MUST always interpret the > externalId as scoped to the Service Consumer's tenant". Which means that = the > provider needs to store one value for every client. This is an extra stat= e > that has nothing to do with the provider itself. It is transfer of client= 's > responsibility to server. Wrong application of separation of concerns > principle. This is not even made optional. Therefore it will complicate a= ll > the server deployments, regardless if it is necessary or not. > > It looks like change of user's userName is not supported. This seems quit= e > limiting to have two persistent identifiers for users (id and userName). > Also, username changes are very common. If username is based on familyNam= e > it changes after most wedding for approximately half of the population. > > The familyName and givenName attributes have culture-neutral names. This = is > a nice take from FOAF. But the middleName is not that good. It enforces > "american" point of view to the schema. Maybe "additionalName" would be m= ore > appropriate. > > User has displayName and also name/formatted attributes. It seems like th= ese > two are used for the same purpose? Or maybe it is displayName and userNam= e? > It looks like SCIM is following LDAP and SAP anti-patterns where users ha= ve > just too many names to choose from. It is perhaps good for the entity tha= t > displays them, but terrible for the one that needs to manage that. The > protocol should be more balanced in this aspect. > > User has nickName as a top-level attribute. But isn't a "name" complex > attribute a better place for nickName? Especially considering the fact th= at > nickname is frequently formatted as a part of full name. > > Does profileUrl represent application profile maintained by the applicati= on > that is being provisioned? Or some other external profile? Should be > "profileUrl" multivalued? The specification is not clear about that. > > User has title and userType in the core schema. But these seem to better = fit > into the "enterprise" extension. > > User has phoneNumbers, but no canonical phone number format is specified. > This is limiting the usability of the specification especially in telco > environment. > > The type meta-attribute in the multi-valued attributes is a plain string. > This is prone to conflicts, especially in ims and similar "open" attribut= es. > URL instead of plain string may be a better choice. > > And probably the most important one: Both groups and roles can be conside= red > entitlements. The groups attribute is read-only, but it can be manipulate= d > through Group Resource. Should such group also appear in entitlements use= r > attribute? If it cannot than the correct name of that attribute should > rather be "otherEntitlements" and the specification should make that clea= r. > If it can then we have a redundancy: a group can be manipulated both thro= ugh > Group Resource and "entitlements" attribute. Similarly for roles. The > specification does not specify if a role should only appear in "roles" an= d > not in "entitlements" or can appear in both. The "SCIM Group Schema" also > defines that roles may be represented as groups, which adds to the > confusion. The ignorance of complexity of entitlement management was one = of > the time bombs in SPML. Not it is time bomb silently ticking in SCIM. > > The members attribute in group does not scale. Groups with thousands of > members are very difficult to manage in this way. And it is typical that = a > group such as "Generic Employee" have more members than that, not even > speaking about telcos. This is one of the common problems in LDAP and als= o > in SCIM. There is also a corollary: creating a user as a member of a grou= p > requires two operations: add user, modify group. This complicates the > implementation in case that the second operation fails. Should a > provisioning system report that as a failure or success? User is created = but > not assigned to a group. Good provisioning system should handle that, but > how many good provisioning systems are out there? > > Minor issue: Canonical types for members are capitalizes while other type= s > start with lowercase letter. > > Should not authenticationSchema be outside of the SCIM core schema? Schem= a > defines no transport protocol and the authentication types clearly depend= on > transport protocols. Maybe a binding specificiation is a better place for > authenticationSchema definition? > > Resource schema has name attribute that obviously points to the object ty= pe. > But it seems to be plain string. Namespace is not obvious here. If any SC= IM > extension adds a new object types (which seems likely) this may be very > confusing. URL may be a better choice here. > > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite inconsiste= nt > and makes if difficult to support uniform representation of "objects" in = the > underlying SCIM implementation. > > Resource Schema has description, but user and groups does not? Descriptio= n > may come handy in any object. > > Can endpoint in the Resource Schema be only relative? Or may it be absolu= te? > Base URL is not a good concept, especially when it comes to different > representations of the schema (e.g. see > http://www.w3.org/2001/tag/doc/alternatives-discovery.html). > > The attributes/type definition in Resource Schema does not specify whethe= r > the value is URL or QName or plain string. If a plain string (which seems= to > be the case by looking at the examples) how to map that string to XSD > QNames? Are only XSD data types possible? The specification says "SHOULD > not" not "MUST NOT", therefore an extension mechanism should be specified > here. > > The multiValuedAttributeChildName attribute and associated way how to > represent data in XML seems to add to the redundancy of the data format. > Strictly speaking, this one is also quite specific to XML and should not = be > in the generic core schema. > > When defining an attribute in a resource schema, how is attribute schema > used? Is it a namespace that applies to attribute type? Or to the attribu= te > name? Attribute has schema and sub-attribute does not? Why? Does it inher= it > it from parent? The specification should make that clear. > > Sub-attributes cannot have sub-attributes? > > If the type is mandatory for every multi-valued attribute (is "hardcoded"= in > the core schema specification), is there any point to define it explicitl= y > in all the resource schemas? > > I have noticed meta attribute in the examples, but it looks like it is no= t > defined in the specification. > > Is ordering of multi-value attribute values significant? > > Critical problems in JSON-like representations: as there are no namespace= s > in JSON, naming conflicts can happen. If two schemas define a > "employeeNumber" attribute while one of them defines it as string and the > other as number, such schemas cannot be used together. Is this a known > limitation of SCIM? > > ( The original post is here: > http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface ) > > -- > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Radovan Semancik > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Software Architect > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 evolveum.com > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From radovan.semancik@evolveum.com Tue Apr 17 07:58: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 6D40C11E80AE for ; Tue, 17 Apr 2012 07:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 fHAqp4hVU-2G for ; Tue, 17 Apr 2012 07:58:30 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00C11E80B2 for ; Tue, 17 Apr 2012 07:58:29 -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 191AEA43E52 for ; Tue, 17 Apr 2012 16:58:27 +0200 (CEST) Message-ID: <4F8D8512.7030404@evolveum.com> Date: Tue, 17 Apr 2012 16:58:26 +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: <4F8C19E8.2010309@evolveum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 14:58:35 -0000 Hi, On 04/17/2012 07:09 AM, Samuel Erdtman wrote: > externalId is not mandatory as far as I know. Are there aspects that I > miss here? I have understood that it is mandatory. The specification says "These attributes MUST be included in all Resources, ...". I have noticed that optional attributes are explicitly marked, but the "externalId" is not marked in any way. Maybe this is just an unclear wording? > Does really userName change, sure you do change name and userName is > often coupled to that but to me it seems like the username is not > changed anyway. I have one colleague that change both family name and > given name but the account did not change userName, but he got a new > account. This usualy means that the account history and audit trails are lost. New account also means new persistent identifier and therefore it is almost impossible to track it back to the original account. I would not assume that "immutable usernames" is the case for all the applications. We have done a lot of IDM deployments in last 10 years and requirement to change usernames was there in a vast majority of them. > I do not thing that middleName/additionalName is a big deal but good > point. to be fully compliant with the global view might we also the > need to make it multiValued for situations where more then one is > common? Multivalued name attributes are quite tricky. We have been experimenting with that in midPoint (IDM solution that we develop) but there are problems formatting multivalue attributes. Especially if they are unordered (which is our case, but also an LDAP case). LDAP has multi-valued naming attributes but I haven't seen anyone using that feature as it complicates things a lot (except the case of multiple uid values, but that is kind of special case). I don't have a definitive answer to that, but I would be inclined towards a single-valued additionalName field now. > Really good point, any suggestions on global phone number formats? > Would E.164 be a good choice? Telcos that I worked for all use E.164. But I don't know how much "europe-centric" is that. > To create a user that is member of a group is a problem and it comes > down to groups being read-only. The reason for groups being read-only > is because the groups attribute may contain memberships that are > inherited and dynamic which would make it problematic to remove a > membership from a user this way. However this problem has been > discussed and e.g. Salesforce needs a group on a user when it is > created. A solution might be to remove read-only from groups and add > some language on how to handle inherited and dynamic groups. > Could you elaborate on the issue with very large groups? You can add > and remove single users with PATCH? The problem with a very large groups is that the list of returned members is huge. This is not efficient to retrieve every time. Therefore the only efficient way is probably to read the "groups" pseudo-attribute of user. However, all changes have to be made to the "members" attribute of the group, which is a bit confusing. It can also be a critical problem for applications that require at least one group to create a user. Such applications just cannot be provisioned with SCIM currently. Making "groups" (in user) read-write may really help here. We have been solving similar problem in midPoint. Our solution (not well tested yet) is to allow "additional operations" to go with a create operation. Adding a group membership to a user can be passed together with "create user" operation. This "batch" can be used by server to "recompose" the operation to a create operation that includes a group membership if that is needed. And it does not affect the protocol too much. However, this approach is somehow incompatible with REST. Also, if the group has many members then changes to such group will be frequent. Operations like PUT may not be feasible, even with optimistic locking (ETag). I see that the presence of PATCH operation can make this efficient. But does SCIM rely on the fact that every protocol will have this efficient way of attribute modification? Most provisioning systems are (unfortunately) based on read-modify-write cycle and it may be difficult for them to implement interface that relies on PATCH. E.g. imagine a provisioning system that "writes" user with a new set of groups [A, B, C]. The SCIM connector would need to read current user's group (e.g. by reading "groups" from user), compare with the [A, B, C] and then use PATCH to align the difference by adding values of "members" attribute (up to) three groups and removing the values from the groups that user should no longer have (efficiently doing a "diff" operation). Don't get me wrong: I like this "delta logic" and I consider it the only reasonable way to go. I also don't see anything bad in punishing broken IDM systems by requiring additional logic on their side. I'm just pointing out that there may be additional adoption barrier when it comes to most older (and also some newer) user provisioning products. Maybe it is worth to think if there is a way that will still allows the "delta logic" as a primary mechanism but will not be that confusing and difficult to implement for legacy systems. E.g. reflecting group membership to a read-write user attribute can make "PUT" feasible as the conflicts on large groups will be avoided and a (concurrency) conflict on a single user is unlikely (and hence the optimistic locking may be efficient). And most importantly: I think there should be a clear and uniform way how to deal with assignment of the things that user belongs to. I call them "entitlements" but I see that SCIM has a slightly different terminology and does not have a common concept that unifies SCIM groups, roles and other entitlements. And I think this is the missing piece that is one of the causes of this confusion. >> Sub-attributes cannot have sub-attributes? > Yes, this was a chosen limitation, is it bad? One reason for the > choice might have been that mapping to flat structures gets harder for > every layer, e.g. there is work done on both LDAP and SAML mappings. I don't know if it is bad or not. I just have a feeling that the structure should either have 1 level or arbitrary number of levels. Multiplicities other than 0, 1 and "many" are usually a source of unexpected problems in data models (even if this is meta-model rather than model). Anyway, if that limitation is done with a purpose it should be documented in the specification. >> If the type is mandatory for every multi-valued attribute (is "hardcoded" in >> the core schema specification), is there any point to define it explicitly >> in all the resource schemas? > Could you be more specific around hardcoded? The "type" attribute is explicitly defined for any multi-valued attributes in the specification (section 3.2). Therefore it is a part of the meta-schema rather than schema. May there be a multi-valued attribute that does not have "type"? If yes then the "type" should be marked as optional in the specification. If not then there is no point of specifying "type" in every run-time schema because it just must always be there. Or maybe my understanding of the distinction between the fixed (specification) part of the protocol and the flexible (extenstion, runtime) part is wrong? If that is the case then maybe the specification should explain that in more detail. > Meta attribute is defined here > http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor2 Oh yes. My bad. Thanks for pointing that out. >> Is ordering of multi-value attribute values significant? > No, multivalued attributes are unordered. This has made mapping to > e.g. SAML harder. That is a crucial point that should be documented in the schema. I was explicitly looking for that and haven't found it. >> Critical problems in JSON-like representations: as there are no namespaces >> in JSON, naming conflicts can happen. If two schemas define a >> "employeeNumber" attribute while one of them defines it as string and the >> other as number, such schemas cannot be used together. Is this a known >> limitation of SCIM? > This is only a problem if both extensions has the same urn, see example below: > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } Oh. This "encapsulating" of extensions into a specific parts of the JSON structure somehow eluded me. Anyway, there is still a problem with future schema extensions. E.g. if a future version of SCIM defines new user attribute "ext1" it can break valid existing "documents" and therefore is a risk for compatibility. Maybe it would be a good idea to adopt the XML "best practice" of quarantining extensibility points into dedicated elements? E.g. it can look like this in JSON: { "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], "userName": "kalle", "extension": { "ext1": { employeeNumber: "abc123" }, "ext2": { employeeNumber: "123abc" } } } -- Radovan Semancik Software Architect evolveum.com From michael.hammer@yaanatech.com Tue Apr 17 08:15: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 EC2BC11E80AE for ; Tue, 17 Apr 2012 08:15:46 -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.000, 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 q8wh2K7iDtr5 for ; Tue, 17 Apr 2012 08:15:42 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61B11E80BB for ; Tue, 17 Apr 2012 08:15:41 -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; Tue, 17 Apr 2012 08:15:41 -0700 From: Michael Hammer To: "radovan.semancik@evolveum.com" , "scim@ietf.org" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQD//48jAA== Date: Tue, 17 Apr 2012 15:15:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FE56@EX2K10MB1.corp.yaanatech.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> In-Reply-To: <4F8D8512.7030404@evolveum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0031_01CD1C8B.6B5D7050" MIME-Version: 1.0 Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 15:15:47 -0000 ------=_NextPart_000_0031_01CD1C8B.6B5D7050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit E.164 is global. E.g. +1 = North American region All global country codes are defined by it. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Radovan Semancik Sent: Tuesday, April 17, 2012 10:58 AM To: scim@ietf.org Subject: Re: [scim] SCIM Issues Hi, On 04/17/2012 07:09 AM, Samuel Erdtman wrote: > externalId is not mandatory as far as I know. Are there aspects that I > miss here? I have understood that it is mandatory. The specification says "These attributes MUST be included in all Resources, ...". I have noticed that optional attributes are explicitly marked, but the "externalId" is not marked in any way. Maybe this is just an unclear wording? > Does really userName change, sure you do change name and userName is > often coupled to that but to me it seems like the username is not > changed anyway. I have one colleague that change both family name and > given name but the account did not change userName, but he got a new > account. This usualy means that the account history and audit trails are lost. New account also means new persistent identifier and therefore it is almost impossible to track it back to the original account. I would not assume that "immutable usernames" is the case for all the applications. We have done a lot of IDM deployments in last 10 years and requirement to change usernames was there in a vast majority of them. > I do not thing that middleName/additionalName is a big deal but good > point. to be fully compliant with the global view might we also the > need to make it multiValued for situations where more then one is > common? Multivalued name attributes are quite tricky. We have been experimenting with that in midPoint (IDM solution that we develop) but there are problems formatting multivalue attributes. Especially if they are unordered (which is our case, but also an LDAP case). LDAP has multi-valued naming attributes but I haven't seen anyone using that feature as it complicates things a lot (except the case of multiple uid values, but that is kind of special case). I don't have a definitive answer to that, but I would be inclined towards a single-valued additionalName field now. > Really good point, any suggestions on global phone number formats? > Would E.164 be a good choice? Telcos that I worked for all use E.164. But I don't know how much "europe-centric" is that. > To create a user that is member of a group is a problem and it comes > down to groups being read-only. The reason for groups being read-only > is because the groups attribute may contain memberships that are > inherited and dynamic which would make it problematic to remove a > membership from a user this way. However this problem has been > discussed and e.g. Salesforce needs a group on a user when it is > created. A solution might be to remove read-only from groups and add > some language on how to handle inherited and dynamic groups. > Could you elaborate on the issue with very large groups? You can add > and remove single users with PATCH? The problem with a very large groups is that the list of returned members is huge. This is not efficient to retrieve every time. Therefore the only efficient way is probably to read the "groups" pseudo-attribute of user. However, all changes have to be made to the "members" attribute of the group, which is a bit confusing. It can also be a critical problem for applications that require at least one group to create a user. Such applications just cannot be provisioned with SCIM currently. Making "groups" (in user) read-write may really help here. We have been solving similar problem in midPoint. Our solution (not well tested yet) is to allow "additional operations" to go with a create operation. Adding a group membership to a user can be passed together with "create user" operation. This "batch" can be used by server to "recompose" the operation to a create operation that includes a group membership if that is needed. And it does not affect the protocol too much. However, this approach is somehow incompatible with REST. Also, if the group has many members then changes to such group will be frequent. Operations like PUT may not be feasible, even with optimistic locking (ETag). I see that the presence of PATCH operation can make this efficient. But does SCIM rely on the fact that every protocol will have this efficient way of attribute modification? Most provisioning systems are (unfortunately) based on read-modify-write cycle and it may be difficult for them to implement interface that relies on PATCH. E.g. imagine a provisioning system that "writes" user with a new set of groups [A, B, C]. The SCIM connector would need to read current user's group (e.g. by reading "groups" from user), compare with the [A, B, C] and then use PATCH to align the difference by adding values of "members" attribute (up to) three groups and removing the values from the groups that user should no longer have (efficiently doing a "diff" operation). Don't get me wrong: I like this "delta logic" and I consider it the only reasonable way to go. I also don't see anything bad in punishing broken IDM systems by requiring additional logic on their side. I'm just pointing out that there may be additional adoption barrier when it comes to most older (and also some newer) user provisioning products. Maybe it is worth to think if there is a way that will still allows the "delta logic" as a primary mechanism but will not be that confusing and difficult to implement for legacy systems. E.g. reflecting group membership to a read-write user attribute can make "PUT" feasible as the conflicts on large groups will be avoided and a (concurrency) conflict on a single user is unlikely (and hence the optimistic locking may be efficient). And most importantly: I think there should be a clear and uniform way how to deal with assignment of the things that user belongs to. I call them "entitlements" but I see that SCIM has a slightly different terminology and does not have a common concept that unifies SCIM groups, roles and other entitlements. And I think this is the missing piece that is one of the causes of this confusion. >> Sub-attributes cannot have sub-attributes? > Yes, this was a chosen limitation, is it bad? One reason for the > choice might have been that mapping to flat structures gets harder for > every layer, e.g. there is work done on both LDAP and SAML mappings. I don't know if it is bad or not. I just have a feeling that the structure should either have 1 level or arbitrary number of levels. Multiplicities other than 0, 1 and "many" are usually a source of unexpected problems in data models (even if this is meta-model rather than model). Anyway, if that limitation is done with a purpose it should be documented in the specification. >> If the type is mandatory for every multi-valued attribute (is >> "hardcoded" in the core schema specification), is there any point to >> define it explicitly in all the resource schemas? > Could you be more specific around hardcoded? The "type" attribute is explicitly defined for any multi-valued attributes in the specification (section 3.2). Therefore it is a part of the meta-schema rather than schema. May there be a multi-valued attribute that does not have "type"? If yes then the "type" should be marked as optional in the specification. If not then there is no point of specifying "type" in every run-time schema because it just must always be there. Or maybe my understanding of the distinction between the fixed (specification) part of the protocol and the flexible (extenstion, runtime) part is wrong? If that is the case then maybe the specification should explain that in more detail. > Meta attribute is defined here > http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#ancho > r2 Oh yes. My bad. Thanks for pointing that out. >> Is ordering of multi-value attribute values significant? > No, multivalued attributes are unordered. This has made mapping to > e.g. SAML harder. That is a crucial point that should be documented in the schema. I was explicitly looking for that and haven't found it. >> Critical problems in JSON-like representations: as there are no >> namespaces in JSON, naming conflicts can happen. If two schemas >> define a "employeeNumber" attribute while one of them defines it as >> string and the other as number, such schemas cannot be used together. >> Is this a known limitation of SCIM? > This is only a problem if both extensions has the same urn, see example below: > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } Oh. This "encapsulating" of extensions into a specific parts of the JSON structure somehow eluded me. Anyway, there is still a problem with future schema extensions. E.g. if a future version of SCIM defines new user attribute "ext1" it can break valid existing "documents" and therefore is a risk for compatibility. Maybe it would be a good idea to adopt the XML "best practice" of quarantining extensibility points into dedicated elements? E.g. it can look like this in JSON: { "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], "userName": "kalle", "extension": { "ext1": { employeeNumber: "abc123" }, "ext2": { employeeNumber: "123abc" } } } -- Radovan Semancik Software Architect evolveum.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0031_01CD1C8B.6B5D7050 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE1MTUzOVowIwYJKoZIhvcNAQkEMRYEFKgqMKUIff78okFVczJlK5BrEfp+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA4eEPhJLjM7ECr4zl6X2BCXlNeHgdhCbBQXBkoIBimYp/ 9Ue1C8tP//rFULD0+16Olu508tYo3foeq6b2oeWWpCZ9kdoy8QLXC/mtyRTh4W5+cZBOjZJntL7p Yq9hmL8pJbnM2gCDXWbs5T0Jv1u6K4L7/Ku80P4Ep2itkMgqreQAAAAAAAA= ------=_NextPart_000_0031_01CD1C8B.6B5D7050-- From kelly.grizzle@sailpoint.com Tue Apr 17 11:12: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 1ADE521F84AA for ; Tue, 17 Apr 2012 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=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 vu-B28T5m4le for ; Tue, 17 Apr 2012 11:11:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7013021F848B for ; Tue, 17 Apr 2012 11:11:56 -0700 (PDT) Received: from mail148-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 18:11:55 +0000 Received: from mail148-ch1 (localhost [127.0.0.1]) by mail148-ch1-R.bigfish.com (Postfix) with ESMTP id 732721A01E9; Tue, 17 Apr 2012 18:11:55 +0000 (UTC) X-SpamScore: -11 X-BigFish: PS-11(zz1b0aL146fI1432N1418Izz1202hzz8275eh8275bha1495iz2fh2a8h668h839h944hd25h) 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 (mail148-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 mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1 (MessageSwitch) id 133468631454639_15828; Tue, 17 Apr 2012 18:11:54 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail148-ch1.bigfish.com (Postfix) with ESMTP id 0B0B4180452; Tue, 17 Apr 2012 18:11:54 +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; Tue, 17 Apr 2012 18:11:50 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.26]) by BL2PRD0410HT001.namprd04.prod.outlook.com ([10.255.99.36]) with mapi id 14.16.0143.004; Tue, 17 Apr 2012 18:11:42 +0000 From: Kelly Grizzle To: Radovan Semancik , "scim@ietf.org" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KHRKCGtgTVFU2m9SlJj7fm7paeePcAgACkeQCAADVNoA== Date: Tue, 17 Apr 2012 18:11:42 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> In-Reply-To: <4F8D8512.7030404@evolveum.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] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 18:12:04 -0000 Radovan, Thanks for all of the excellent feedback. You have brought up some great points! > I have noticed that optional attributes are explicitly marked, but the > "externalId" is not marked in any way. Maybe this is just an unclear wor= ding? This is supposed to be optional. I agree that the spec should be explicit = about this. Regarding externalId-per-consumer, this topic came up at IIW in Octo= ber. One thought was to allow this be multi-valued and have the type specify som= e sort of URN for the consumer. The discussion ended there, though. > We have done a lot of IDM deployments in last 10 years and requirement to > change usernames was there in a vast majority of them. I agree. In Active Directory, it seems like samAccountName (which is mutab= le) would be modeled as the SCIM userName. I don't see any problem in dropping= the immutability requirement from the spec. > The problem with a very large groups is that the list of returned members= is > huge. This is not efficient to retrieve every time. This is issue 43 in the issue tracker. Hopefully this can get fixed in SCI= M 2.0. http://code.google.com/p/scim/issues/detail?id=3D43 > However, all changes have to be made to the "members" attribute of the > group, which is a bit confusing. It can also be a critical problem for > applications that require at least one group to create a user. Such > applications just cannot be provisioned with SCIM currently. Making > "groups" (in user) read-write may really help here. I believe that when we first bumped into this at IIW in October, we propose= d an extension to the User schema that allows specifying the default group upon creation. If this is a common case (requiring a group upon creation), it s= hould be considered in the core spec rather than just as a workaround. > Adding a group membership to a user can be passed together with > "create user" operation. This "batch" can be used by server to "recompose= " > the operation to a create operation that includes a group membership if t= hat > is needed. And it does not affect the protocol too much. However, this > approach is somehow incompatible with REST. SCIM has a /Bulk endpoint that can be used for batching, but the spec says = that ordering is not guaranteed. Perhaps this could be used if the service prov= ider is smart enough, but it could be difficult to implement efficiently. > I see that the presence of PATCH operation can make this > efficient. But does SCIM rely on the fact that every protocol will have t= his > efficient way of attribute modification? PATCH support is not required by the spec, but I would imagine that any ser= vice provider that has large data (eg - a directory server) would strive to impl= ement it for their own good. I'm not sure how this would be done in different protocols, though. This needs more thought for non-REST protocols. > Maybe it is worth to think if there is a way that will still allows the "= delta > logic" as a primary mechanism but will not be that confusing and difficul= t to > implement for legacy systems. E.g. reflecting group membership to a > read-write user attribute can make "PUT" feasible as the conflicts on lar= ge > groups will be avoided and a (concurrency) conflict on a single user is > unlikely (and hence the optimistic locking may be efficient). A read-write groups attribute on the User has been discussed quite a bit. = I agree that it is much easier to manipulate group membership via the user th= an the other way around. As Samuel pointed out, the groups attribute contains groups that are not only directly assigned, inherited, or dynamically calculated. As such, it is difficult to allow modification of this attribu= te since some groups (eg - dynamic) cannot be removed or added. Various ideas= were considered to allow this (splitting dynamic and nested groups into a separa= te attribute, etc...), but they all had their own complications. Because of t= his we decided to stick with the "edit membership via the group" philosophy. > And most importantly: I think there should be a clear and uniform way how= to > deal with assignment of the things that user belongs to. I call them > "entitlements" but I see that SCIM has a slightly different terminology a= nd > does not have a common concept that unifies SCIM groups, roles and other > entitlements. And I think this is the missing piece that is one of the > causes of this confusion. You are right that a group can be considered an entitlement and there is so= me confusion here. Concrete examples may help. This is how I think about the three: - Entitlements: These are individual low-level access grants that are assi= gned directly to a user. An example granting a user the "Write" right on a resource called DevWiki. This might be modeled as "write:DevWiki" or something. - Roles: These describe what roles or job functions the user holds within = the organization (eg - Developer, Sales Executive, Student, etc...). In som= e systems, having a role might cause a user to be granted individual entitlements or group memberships. These relationships are not specifie= d in SCIM since roles are opaque. - Groups: These are groupings of users that may support nesting. In some = cases they are used for access control (security groups) and in other cases th= ey are used for other purposes (eg - distribution groups). Security groups= may be able to grant entitlements to a user. I think that there is merit in keeping these concepts separated. I can con= ceive of future extensions to expose /Entitlements and /Roles endpoints that allo= w reading and updating an entitlement catalog and role model. There has been= some confusion around these three attributes, so it is probably worth trying to = clean this up in the spec. >> Minor issue: Canonical types for members are capitalizes while other typ= es >> start with lowercase letter.=20 > > Good catch, it might be a legacy from the time when the endpoints where c= alled > User and Group and not Users and Groups. It is probably legacy. There are actually currently some discussions aroun= d this wrt allowing the group members to be dereferenced. "User" and "Group" match the name in the resource schema (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-= schema) and it may be worth keeping these to allow dereferencing. > Should not authenticationSchema be outside of the SCIM core schema?=20 > Schema defines no transport protocol and the authentication types=20 > clearly depend on transport protocols. Maybe a binding specificiation=20 > is a better place for authenticationSchema definition? This is defined in the ServiceProviderConfig, which regardless of the trans= port protocol should be available. You're right that this assumes the REST protocol. Perhaps authenticationSchemas should have a sub-attribute that specifies the applicable protocol? > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite=20 > inconsistent and makes if difficult to support uniform representation=20 > of "objects" in the underlying SCIM implementation. Maybe Group could use name instead of displayName? I kind of like displayN= ame because this might be different from a raw name (eg - Super Users vs. cn=3D= Super Users,dc=3Dfoo,...). This doesn't seem like much of an issue to me. Looki= ng at the confusion between userName, displayName, formattedName is worthwhile, though. > Resource Schema has description, but user and groups does not?=20 > Description may come handy in any object. I could see this for groups but haven't ever really seen this for users. > The attributes/type definition in Resource Schema does not specify=20 > whether the value is URL or QName or plain string. If a plain string=20 > (which seems to be the case by looking at the examples) how to map=20 > that string to XSD QNames? Are only XSD data types possible? The=20 > specification says "SHOULD not" not "MUST NOT", therefore an extension=20 > mechanism should be specified here. Yes these are based on XSD data types and are not currently extensible. Ar= e there any data types that are not currently covered by the spec? >>> If the type is mandatory for every multi-valued attribute (is "hardcode= d" >>> in the core schema specification), is there any point to define it >>> explicitly in all the resource schemas? >> Could you be more specific around hardcoded? >=20 > The "type" attribute is explicitly defined for any multi-valued attribute= s > in the specification (section 3.2). Therefore it is a part of the > meta-schema rather than schema. May there be a multi-valued attribute tha= t > does not have "type"? If yes then the "type" should be marked as optional= in > the specification. If not then there is no point of specifying "type" in > every run-time schema because it just must always be there. I believe that the type sub-attribute is optional. I believe that generall= y in the schema spec if an attribute doesn't say REQUIRED than it is implied to = be optional. This should be made more explicit. >>> Is ordering of multi-value attribute values significant? No, multivalu= ed >>attributes are unordered. This has made mapping to e.g. SAML harder. >=20 > That is a crucial point that should be documented in the schema. I was > explicitly looking for that and haven't found it. I agree. > Oh. This "encapsulating" of extensions into a specific parts of the JSON > structure somehow eluded me. Anyway, there is still a problem with future > schema extensions. E.g. if a future version of SCIM defines new user > attribute "ext1" it can break valid existing "documents" and therefore is= a > risk for compatibility. Maybe it would be a good idea to adopt the XML "b= est > practice" of quarantining extensibility points into dedicated elements? > E.g. it can look like this in JSON: >=20 > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "extension": { > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } } Extensions are actually defined with URNs (eg - urn:scim:schemas:extension:= enterprise:1.0), so it is pretty unlikely that there will be conflicts. See an example in t= he JSON representation of an enterprise user here: http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. > I hope that the authors of SCIM will try to correct the obvious problems = of > the specification and focus on proving that it works before going any > further. The only reasonable way to go is: working software first, standa= rds > second. Implementations have been developed in parallel with the spec, and there we= re 9 of them that worked (at least to some extent) together just a few weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (mysel= f included) have always had an eye toward making something that is practical, useful, and actually works. As you have found, there are definitely some h= oles and warts that need to be addressed. I really appreciate your feedback and will make sure that some of these iss= ues make it into the issue tracker. --Kelly From stephen.farrell@cs.tcd.ie Tue Apr 17 11:35:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B1221F84F8 for ; Tue, 17 Apr 2012 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 MKGrpd-lA+s7 for ; Tue, 17 Apr 2012 11:35:09 -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 1418621F84EE for ; Tue, 17 Apr 2012 11:35:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD426171476; Tue, 17 Apr 2012 19:35:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334687707; bh=M45ffDGasChe9m qt7N0IWHv+UnZzPLKjBr1tqLjvPLY=; b=z36XmTcBh5RTfkEh71mf/KD+u6XjEz T4jUIWvAnZsmYDxvi4XobqwJnnHTpC4UKEtbTTNiUTQ1PsRcdYLqxOceTVSh9HwU ZlA4fPfuGowAhxCjjA/vu605MXnPKDkq8naipDAjGSnOCSm94QwowPAazsh4DDtx N1NVN2IOoyN9im1utCbC7BZJnF5Yr2RDND7KnpuokYgnMZgFeIxfOPBkTQCMHV+I V2aZ84cSreo4dedzpWCh1zqW/0fOqplt3Sm34ped/Wg8G/4ffKJgve3u+d7gPORQ nESm0kNI0/2y51cpqCBJOnKy6NL1zTeW1mTeoiD/piTX/uzUr8GaKwrg== 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 qs3s8Bp0CuyF; Tue, 17 Apr 2012 19:35:07 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.16.190]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 26E1F171473; Tue, 17 Apr 2012 19:35:06 +0100 (IST) Message-ID: <4F8DB7D0.5040706@cs.tcd.ie> Date: Tue, 17 Apr 2012 19:34:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Samuel Erdtman References: <4F8C19E8.2010309@evolveum.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Radovan Semancik , scim@ietf.org Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 18:35:13 -0000 Just a question on one snippet: On 04/17/2012 06:09 AM, Samuel Erdtman wrote: >> > >> > The familyName and givenName attributes have culture-neutral names. This is >> > a nice take from FOAF. But the middleName is not that good. It enforces >> > "american" point of view to the schema. Maybe "additionalName" would be more >> > appropriate. > I do not thing that middleName/additionalName is a big deal but good > point. to be fully compliant with the global view might we also the > need to make it multiValued for situations where more then one is > common? Does this mean that scim intend to re-develop the equivalent of inetOrgPerson? That seems like an odd idea. Why is it necessary? Note - I'm not saying "use ldif" here, but wondering why this putative WG would need to go re-do all that data modelling work, as would be implied by the quoted text above. S From michael.hammer@yaanatech.com Tue Apr 17 11:50: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 4AD8D21F852B for ; Tue, 17 Apr 2012 11:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=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 u8m3NlbBPboN for ; Tue, 17 Apr 2012 11:50:41 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 969B821F8533 for ; Tue, 17 Apr 2012 11:50:41 -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; Tue, 17 Apr 2012 11:50:38 -0700 From: Michael Hammer To: "kelly.grizzle@sailpoint.com" , "radovan.semancik@evolveum.com" , "scim@ietf.org" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQ Date: Tue, 17 Apr 2012 18:50:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0137_01CD1CA9.72522810" MIME-Version: 1.0 Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 18:50:46 -0000 ------=_NextPart_000_0137_01CD1CA9.72522810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kelly, I am not sure I like the definitions you have for role. Another international spec I looked over recently defines role as a set of entitlements. That makes more sense to me. Group=set of Users Role=set of Entitlements The name of the role would give one an idea what entitlements to assign that role. Powers get inherited down the line: Entitlement -> Role -> Group -> User Pointers can be set in the opposite direction of the arrows. And of course, leaving a role or group or both out of the chain is permitted. Mike Sense? Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle Sent: Tuesday, April 17, 2012 2:12 PM To: Radovan Semancik; scim@ietf.org Subject: Re: [scim] SCIM Issues Radovan, Thanks for all of the excellent feedback. You have brought up some great points! > I have noticed that optional attributes are explicitly marked, but the > "externalId" is not marked in any way. Maybe this is just an unclear wording? This is supposed to be optional. I agree that the spec should be explicit about this. Regarding externalId-per-consumer, this topic came up at IIW in October. One thought was to allow this be multi-valued and have the type specify some sort of URN for the consumer. The discussion ended there, though. > We have done a lot of IDM deployments in last 10 years and requirement > to change usernames was there in a vast majority of them. I agree. In Active Directory, it seems like samAccountName (which is mutable) would be modeled as the SCIM userName. I don't see any problem in dropping the immutability requirement from the spec. > The problem with a very large groups is that the list of returned > members is huge. This is not efficient to retrieve every time. This is issue 43 in the issue tracker. Hopefully this can get fixed in SCIM 2.0. http://code.google.com/p/scim/issues/detail?id=43 > However, all changes have to be made to the "members" attribute of the > group, which is a bit confusing. It can also be a critical problem for > applications that require at least one group to create a user. Such > applications just cannot be provisioned with SCIM currently. Making > "groups" (in user) read-write may really help here. I believe that when we first bumped into this at IIW in October, we proposed an extension to the User schema that allows specifying the default group upon creation. If this is a common case (requiring a group upon creation), it should be considered in the core spec rather than just as a workaround. > Adding a group membership to a user can be passed together with > "create user" operation. This "batch" can be used by server to "recompose" > the operation to a create operation that includes a group membership > if that is needed. And it does not affect the protocol too much. > However, this approach is somehow incompatible with REST. SCIM has a /Bulk endpoint that can be used for batching, but the spec says that ordering is not guaranteed. Perhaps this could be used if the service provider is smart enough, but it could be difficult to implement efficiently. > I see that the presence of PATCH operation can make this efficient. > But does SCIM rely on the fact that every protocol will have this > efficient way of attribute modification? PATCH support is not required by the spec, but I would imagine that any service provider that has large data (eg - a directory server) would strive to implement it for their own good. I'm not sure how this would be done in different protocols, though. This needs more thought for non-REST protocols. > Maybe it is worth to think if there is a way that will still allows > the "delta logic" as a primary mechanism but will not be that > confusing and difficult to implement for legacy systems. E.g. > reflecting group membership to a read-write user attribute can make > "PUT" feasible as the conflicts on large groups will be avoided and a > (concurrency) conflict on a single user is unlikely (and hence the optimistic locking may be efficient). A read-write groups attribute on the User has been discussed quite a bit. I agree that it is much easier to manipulate group membership via the user than the other way around. As Samuel pointed out, the groups attribute contains groups that are not only directly assigned, inherited, or dynamically calculated. As such, it is difficult to allow modification of this attribute since some groups (eg - dynamic) cannot be removed or added. Various ideas were considered to allow this (splitting dynamic and nested groups into a separate attribute, etc...), but they all had their own complications. Because of this we decided to stick with the "edit membership via the group" philosophy. > And most importantly: I think there should be a clear and uniform way > how to deal with assignment of the things that user belongs to. I call > them "entitlements" but I see that SCIM has a slightly different > terminology and does not have a common concept that unifies SCIM > groups, roles and other entitlements. And I think this is the missing > piece that is one of the causes of this confusion. You are right that a group can be considered an entitlement and there is some confusion here. Concrete examples may help. This is how I think about the three: - Entitlements: These are individual low-level access grants that are assigned directly to a user. An example granting a user the "Write" right on a resource called DevWiki. This might be modeled as "write:DevWiki" or something. - Roles: These describe what roles or job functions the user holds within the organization (eg - Developer, Sales Executive, Student, etc...). In some systems, having a role might cause a user to be granted individual entitlements or group memberships. These relationships are not specified in SCIM since roles are opaque. - Groups: These are groupings of users that may support nesting. In some cases they are used for access control (security groups) and in other cases they are used for other purposes (eg - distribution groups). Security groups may be able to grant entitlements to a user. I think that there is merit in keeping these concepts separated. I can conceive of future extensions to expose /Entitlements and /Roles endpoints that allow reading and updating an entitlement catalog and role model. There has been some confusion around these three attributes, so it is probably worth trying to clean this up in the spec. >> Minor issue: Canonical types for members are capitalizes while other >> types start with lowercase letter. > > Good catch, it might be a legacy from the time when the endpoints > where called User and Group and not Users and Groups. It is probably legacy. There are actually currently some discussions around this wrt allowing the group members to be dereferenced. "User" and "Group" match the name in the resource schema (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-s chema) and it may be worth keeping these to allow dereferencing. > Should not authenticationSchema be outside of the SCIM core schema? > Schema defines no transport protocol and the authentication types > clearly depend on transport protocols. Maybe a binding specificiation > is a better place for authenticationSchema definition? This is defined in the ServiceProviderConfig, which regardless of the transport protocol should be available. You're right that this assumes the REST protocol. Perhaps authenticationSchemas should have a sub-attribute that specifies the applicable protocol? > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite > inconsistent and makes if difficult to support uniform representation > of "objects" in the underlying SCIM implementation. Maybe Group could use name instead of displayName? I kind of like displayName because this might be different from a raw name (eg - Super Users vs. cn=Super Users,dc=foo,...). This doesn't seem like much of an issue to me. Looking at the confusion between userName, displayName, formattedName is worthwhile, though. > Resource Schema has description, but user and groups does not? > Description may come handy in any object. I could see this for groups but haven't ever really seen this for users. > The attributes/type definition in Resource Schema does not specify > whether the value is URL or QName or plain string. If a plain string > (which seems to be the case by looking at the examples) how to map > that string to XSD QNames? Are only XSD data types possible? The > specification says "SHOULD not" not "MUST NOT", therefore an extension > mechanism should be specified here. Yes these are based on XSD data types and are not currently extensible. Are there any data types that are not currently covered by the spec? >>> If the type is mandatory for every multi-valued attribute (is "hardcoded" >>> in the core schema specification), is there any point to define it >>> explicitly in all the resource schemas? >> Could you be more specific around hardcoded? > > The "type" attribute is explicitly defined for any multi-valued > attributes in the specification (section 3.2). Therefore it is a part > of the meta-schema rather than schema. May there be a multi-valued > attribute that does not have "type"? If yes then the "type" should be > marked as optional in the specification. If not then there is no point > of specifying "type" in every run-time schema because it just must always be there. I believe that the type sub-attribute is optional. I believe that generally in the schema spec if an attribute doesn't say REQUIRED than it is implied to be optional. This should be made more explicit. >>> Is ordering of multi-value attribute values significant? No, >>> multivalued >>attributes are unordered. This has made mapping to e.g. SAML harder. > > That is a crucial point that should be documented in the schema. I was > explicitly looking for that and haven't found it. I agree. > Oh. This "encapsulating" of extensions into a specific parts of the > JSON structure somehow eluded me. Anyway, there is still a problem > with future schema extensions. E.g. if a future version of SCIM > defines new user attribute "ext1" it can break valid existing > "documents" and therefore is a risk for compatibility. Maybe it would > be a good idea to adopt the XML "best practice" of quarantining extensibility points into dedicated elements? > E.g. it can look like this in JSON: > > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "extension": { > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } } Extensions are actually defined with URNs (eg - urn:scim:schemas:extension:enterprise:1.0), so it is pretty unlikely that there will be conflicts. See an example in the JSON representation of an enterprise user here: http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. > I hope that the authors of SCIM will try to correct the obvious > problems of the specification and focus on proving that it works > before going any further. The only reasonable way to go is: working > software first, standards second. Implementations have been developed in parallel with the spec, and there were 9 of them that worked (at least to some extent) together just a few weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (myself included) have always had an eye toward making something that is practical, useful, and actually works. As you have found, there are definitely some holes and warts that need to be addressed. I really appreciate your feedback and will make sure that some of these issues make it into the issue tracker. --Kelly _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0137_01CD1CA9.72522810 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE4NTAzNVowIwYJKoZIhvcNAQkEMRYEFFZs5HSPSZJlsERFtvpn7J16a6meMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAmzhYfEDTRHFmyumnP9wUhsRCoaSIPr5kqz5RFKi5SYLt RuheuRWixGUnfsyI1PzQPWrBMfKHrBZgnMUQN5iRfRrMAErccai+6M+icff9raiacQfnnh199UrR ttbbC9mcXzMfFEpuKV/XkoRyqL3lPL/wrqkkFsJfyuopP2TmQAcAAAAAAAA= ------=_NextPart_000_0137_01CD1CA9.72522810-- From kelly.grizzle@sailpoint.com Tue Apr 17 14:03: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 B197A11E80C7 for ; Tue, 17 Apr 2012 14:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=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 DUVsT7Lo-8kk for ; Tue, 17 Apr 2012 14:03:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id A775B11E80BD for ; Tue, 17 Apr 2012 14:03:17 -0700 (PDT) Received: from mail23-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 21:03:16 +0000 Received: from mail23-am1 (localhost [127.0.0.1]) by mail23-am1-R.bigfish.com (Postfix) with ESMTP id 64DCE603F5; Tue, 17 Apr 2012 21:03:16 +0000 (UTC) X-SpamScore: -37 X-BigFish: PS-37(zz9371I1b0aL146fI542M1432N1418Izz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail23-am1: 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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail23-am1 (localhost.localdomain [127.0.0.1]) by mail23-am1 (MessageSwitch) id 1334696593766866_31093; Tue, 17 Apr 2012 21:03:13 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.228]) by mail23-am1.bigfish.com (Postfix) with ESMTP id B676522004B; Tue, 17 Apr 2012 21:03:13 +0000 (UTC) Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 21:03:11 +0000 Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.250]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Tue, 17 Apr 2012 21:03:04 +0000 From: Kelly Grizzle To: Michael Hammer , "radovan.semancik@evolveum.com" , "scim@ietf.org" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KHRKCGtgTVFU2m9SlJj7fm7paeePcAgACkeQCAADVNoIAAC5KAgAAaUTA= Date: Tue, 17 Apr 2012 21:03:04 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.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] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 21:03:22 -0000 This makes sense to me. However, I have seen roles be used for more than t= his. A common example is using roles to define separation of duty policies= , such as disallowing a person from being a "Vendor Creator" and "Payment A= pprover". Often these role have entitlements under them, but not always. I have also seen roles be split into different types - business roles and I= T roles. A business role is simply something that describes who a person i= s within their organization. This can be assigned directly to the user or = can be dynamically assigned by some sort of a matching rule (eg - "if your = title is 'Sales Level III' you get 'Sales Engineer' role). An IT role is m= ore like what you are describing, a group of entitlements. These different= types of roles can be related to each other through various relationships.= For example, a "Developer" business role might give default access to (or= require) the "Developer Version Control" IT role and permit access to (but= not require) the "Developer Data Modeling" IT role. Also, if a role is nothing more than a set of entitlements, how is this dif= ferent from a group? Security groups are generally granted some set of ent= itlements and then users are added as group members to be granted those ent= itlements. All of this to say that while roles are often a set of entitlements, I don'= t think that this is always the case. --Kelly -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Tuesday, April 17, 2012 1:51 PM To: Kelly Grizzle; radovan.semancik@evolveum.com; scim@ietf.org Subject: RE: [scim] SCIM Issues Kelly, I am not sure I like the definitions you have for role. Another international spec I looked over recently defines role as a set of entitlements. That makes more sense to me. Group=3Dset of Users Role=3Dset of Entitlements The name of the role would give one an idea what entitlements to assign tha= t role. Powers get inherited down the line: Entitlement -> Role -> Group -> User Pointers can be set in the opposite direction of the arrows. And of course, leaving a role or group or both out of the chain is permitted. Mike Sense? Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle Sent: Tuesday, April 17, 2012 2:12 PM To: Radovan Semancik; scim@ietf.org Subject: Re: [scim] SCIM Issues Radovan, Thanks for all of the excellent feedback. You have brought up some great points! > I have noticed that optional attributes are explicitly marked, but the=20 > "externalId" is not marked in any way. Maybe this is just an unclear wording? This is supposed to be optional. I agree that the spec should be explicit about this. Regarding externalId-per-consumer, this topic came up at IIW i= n October. One thought was to allow this be multi-valued and have the type specify som= e sort of URN for the consumer. The discussion ended there, though. > We have done a lot of IDM deployments in last 10 years and requirement=20 > to change usernames was there in a vast majority of them. I agree. In Active Directory, it seems like samAccountName (which is mutable) would be modeled as the SCIM userName. I don't see any problem in dropping the immutability requirement from the spec. > The problem with a very large groups is that the list of returned=20 > members is huge. This is not efficient to retrieve every time. This is issue 43 in the issue tracker. Hopefully this can get fixed in SCI= M 2.0. http://code.google.com/p/scim/issues/detail?id=3D43 > However, all changes have to be made to the "members" attribute of the=20 > group, which is a bit confusing. It can also be a critical problem for=20 > applications that require at least one group to create a user. Such=20 > applications just cannot be provisioned with SCIM currently. Making=20 > "groups" (in user) read-write may really help here. I believe that when we first bumped into this at IIW in October, we propose= d an extension to the User schema that allows specifying the default group upon creation. If this is a common case (requiring a group upon creation), it should be considered in the core spec rather than just as a workaround. > Adding a group membership to a user can be passed together with=20 > "create user" operation. This "batch" can be used by server to "recompose= " > the operation to a create operation that includes a group membership=20 > if that is needed. And it does not affect the protocol too much.=20 > However, this approach is somehow incompatible with REST. SCIM has a /Bulk endpoint that can be used for batching, but the spec says that ordering is not guaranteed. Perhaps this could be used if the service provider is smart enough, but it could be difficult to implement efficiently. > I see that the presence of PATCH operation can make this efficient.=20 > But does SCIM rely on the fact that every protocol will have this=20 > efficient way of attribute modification? PATCH support is not required by the spec, but I would imagine that any service provider that has large data (eg - a directory server) would strive to implement it for their own good. I'm not sure how this would be done in different protocols, though. This needs more thought for non-REST protocols. > Maybe it is worth to think if there is a way that will still allows=20 > the "delta logic" as a primary mechanism but will not be that=20 > confusing and difficult to implement for legacy systems. E.g. =20 > reflecting group membership to a read-write user attribute can make=20 > "PUT" feasible as the conflicts on large groups will be avoided and a=20 > (concurrency) conflict on a single user is unlikely (and hence the optimistic locking may be efficient). A read-write groups attribute on the User has been discussed quite a bit. = I agree that it is much easier to manipulate group membership via the user than the other way around. As Samuel pointed out, the groups attribute contains groups that are not only directly assigned, inherited, or dynamically calculated. As such, it is difficult to allow modification of this attribute since some groups (eg - dynamic) cannot be removed or added. Various ideas were considered to allow this (splitting dynamic and nested groups into a separate attribute, etc...), but they all had their own complications. Because of this we decided to stick with the "edit membership via the group" philosophy. > And most importantly: I think there should be a clear and uniform way=20 > how to deal with assignment of the things that user belongs to. I call=20 > them "entitlements" but I see that SCIM has a slightly different=20 > terminology and does not have a common concept that unifies SCIM=20 > groups, roles and other entitlements. And I think this is the missing=20 > piece that is one of the causes of this confusion. You are right that a group can be considered an entitlement and there is some confusion here. Concrete examples may help. This is how I think abou= t the three: - Entitlements: These are individual low-level access grants that are assigned directly to a user. An example granting a user the "Write" right on a resource called DevWiki. This might be modeled as "write:DevWiki" or something. - Roles: These describe what roles or job functions the user holds within the organization (eg - Developer, Sales Executive, Student, etc...). In som= e systems, having a role might cause a user to be granted individual entitlements or group memberships. These relationships are not specifie= d in SCIM since roles are opaque. - Groups: These are groupings of users that may support nesting. In some cases they are used for access control (security groups) and in other cases they are used for other purposes (eg - distribution groups). Security groups may be able to grant entitlements to a user. I think that there is merit in keeping these concepts separated. I can conceive of future extensions to expose /Entitlements and /Roles endpoints that allow reading and updating an entitlement catalog and role model. There has been some confusion around these three attributes, so it is probably worth trying to clean this up in the spec. >> Minor issue: Canonical types for members are capitalizes while other=20 >> types start with lowercase letter. > > Good catch, it might be a legacy from the time when the endpoints=20 > where called User and Group and not Users and Groups. It is probably legacy. There are actually currently some discussions aroun= d this wrt allowing the group members to be dereferenced. "User" and "Group" match the name in the resource schema (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-= s chema) and it may be worth keeping these to allow dereferencing. > Should not authenticationSchema be outside of the SCIM core schema?=20 > Schema defines no transport protocol and the authentication types=20 > clearly depend on transport protocols. Maybe a binding specificiation=20 > is a better place for authenticationSchema definition? This is defined in the ServiceProviderConfig, which regardless of the transport protocol should be available. You're right that this assumes the REST protocol. Perhaps authenticationSchemas should have a sub-attribute that specifies the applicable protocol? > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite=20 > inconsistent and makes if difficult to support uniform representation=20 > of "objects" in the underlying SCIM implementation. Maybe Group could use name instead of displayName? I kind of like displayName because this might be different from a raw name (eg - Super Users vs. cn=3DSuper Users,dc=3Dfoo,...). This doesn't seem like much of a= n issue to me. Looking at the confusion between userName, displayName, formattedName is worthwhile, though. > Resource Schema has description, but user and groups does not?=20 > Description may come handy in any object. I could see this for groups but haven't ever really seen this for users. > The attributes/type definition in Resource Schema does not specify=20 > whether the value is URL or QName or plain string. If a plain string=20 > (which seems to be the case by looking at the examples) how to map=20 > that string to XSD QNames? Are only XSD data types possible? The=20 > specification says "SHOULD not" not "MUST NOT", therefore an extension=20 > mechanism should be specified here. Yes these are based on XSD data types and are not currently extensible. Ar= e there any data types that are not currently covered by the spec? >>> If the type is mandatory for every multi-valued attribute (is "hardcoded" >>> in the core schema specification), is there any point to define it=20 >>> explicitly in all the resource schemas? >> Could you be more specific around hardcoded? >=20 > The "type" attribute is explicitly defined for any multi-valued=20 > attributes in the specification (section 3.2). Therefore it is a part=20 > of the meta-schema rather than schema. May there be a multi-valued=20 > attribute that does not have "type"? If yes then the "type" should be=20 > marked as optional in the specification. If not then there is no point=20 > of specifying "type" in every run-time schema because it just must always be there. I believe that the type sub-attribute is optional. I believe that generall= y in the schema spec if an attribute doesn't say REQUIRED than it is implied to be optional. This should be made more explicit. >>> Is ordering of multi-value attribute values significant? No,=20 >>> multivalued >>attributes are unordered. This has made mapping to e.g. SAML harder. >=20 > That is a crucial point that should be documented in the schema. I was=20 > explicitly looking for that and haven't found it. I agree. > Oh. This "encapsulating" of extensions into a specific parts of the=20 > JSON structure somehow eluded me. Anyway, there is still a problem=20 > with future schema extensions. E.g. if a future version of SCIM=20 > defines new user attribute "ext1" it can break valid existing=20 > "documents" and therefore is a risk for compatibility. Maybe it would=20 > be a good idea to adopt the XML "best practice" of quarantining extensibility points into dedicated elements? > E.g. it can look like this in JSON: >=20 > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "extension": { > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } } Extensions are actually defined with URNs (eg - urn:scim:schemas:extension:enterprise:1.0), so it is pretty unlikely that there will be conflicts. See an example in the JSON representation of an enterprise user here: http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. > I hope that the authors of SCIM will try to correct the obvious=20 > problems of the specification and focus on proving that it works=20 > before going any further. The only reasonable way to go is: working=20 > software first, standards second. Implementations have been developed in parallel with the spec, and there were 9 of them that worked (at least to some extent) together just a few weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (myself included) have always had an eye toward making something that is practical, useful, and actually works. As you have found, there are definitely some holes and warts that need to be addressed. I really appreciate your feedback and will make sure that some of these issues make it into the issue tracker. --Kelly _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Tue Apr 17 14:59: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 5DC6511E80E0 for ; Tue, 17 Apr 2012 14:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=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 dVCUMSTmwI60 for ; Tue, 17 Apr 2012 14:59:43 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0939611E80D6 for ; Tue, 17 Apr 2012 14:59:43 -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; Tue, 17 Apr 2012 14:59:42 -0700 From: Michael Hammer To: "kelly.grizzle@sailpoint.com" , "radovan.semancik@evolveum.com" , "scim@ietf.org" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQAD//4ylAA== Date: Tue, 17 Apr 2012 21:59:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A02F2@EX2K10MB1.corp.yaanatech.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018E_01CD1CC3.DC975C80" MIME-Version: 1.0 Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 21:59:48 -0000 ------=_NextPart_000_018E_01CD1CC3.DC975C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with you that loosely defined usage and habit can lead to very muddy waters. The way I rationalized this for myself was to dig deeper. Is someone says that a user or group is assigned a role, what does that mean? If my role is IT wizard, it usually means I have powers (tokens?) that allow me to do X, Y, and Z, which are atomic or binary permissions. I either get to do it or not. Having both entitlements and roles allows an M:N mapping. A role is a collection of powers versus having to repeat a laundry least each time. This allow later the subsequent ability to assign a set of permissions to a User or Group. (M:X, M:Y, N:X, N:Y mappings) I saw role and group as distinct in that those sets parallel the What versus Who of the more atomic Entitlement and User. Again the User and Group allow X:Y mapping so one person can belong to different groups. Similarly, the actions of ascertaining Identity is conducted first (who), followed by application of access rules (what you can then do). The alternative IMHO is that if there is no distinction, and if role, entitlement, and group are synonyms, you could then eliminate one or more redundant terms without loss and have only Users and Entitlements (or whichever term you select to keep). (N:Y mappings only) So, I guess this boils down to whether there is need to have zero, one, or two types of sets. If one, is that a set of entitlements (aka role) that gets assigned one by one to each User? Or, is that a set of Users that gets assigned one by one to each Entitlement? (Note, I think you use role and group as synonymous.) My thinking was that having more levels of indirection/aggregation would provide more flexibility. Wonder what others are thinking? Mike -----Original Message----- From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Tuesday, April 17, 2012 5:03 PM To: Michael Hammer; radovan.semancik@evolveum.com; scim@ietf.org Subject: RE: [scim] SCIM Issues This makes sense to me. However, I have seen roles be used for more than this. A common example is using roles to define separation of duty policies, such as disallowing a person from being a "Vendor Creator" and "Payment Approver". Often these role have entitlements under them, but not always. I have also seen roles be split into different types - business roles and IT roles. A business role is simply something that describes who a person is within their organization. This can be assigned directly to the user or can be dynamically assigned by some sort of a matching rule (eg - "if your title is 'Sales Level III' you get 'Sales Engineer' role). An IT role is more like what you are describing, a group of entitlements. These different types of roles can be related to each other through various relationships. For example, a "Developer" business role might give default access to (or require) the "Developer Version Control" IT role and permit access to (but not require) the "Developer Data Modeling" IT role. Also, if a role is nothing more than a set of entitlements, how is this different from a group? Security groups are generally granted some set of entitlements and then users are added as group members to be granted those entitlements. All of this to say that while roles are often a set of entitlements, I don't think that this is always the case. --Kelly -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Tuesday, April 17, 2012 1:51 PM To: Kelly Grizzle; radovan.semancik@evolveum.com; scim@ietf.org Subject: RE: [scim] SCIM Issues Kelly, I am not sure I like the definitions you have for role. Another international spec I looked over recently defines role as a set of entitlements. That makes more sense to me. Group=set of Users Role=set of Entitlements The name of the role would give one an idea what entitlements to assign that role. Powers get inherited down the line: Entitlement -> Role -> Group -> User Pointers can be set in the opposite direction of the arrows. And of course, leaving a role or group or both out of the chain is permitted. Mike Sense? Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle Sent: Tuesday, April 17, 2012 2:12 PM To: Radovan Semancik; scim@ietf.org Subject: Re: [scim] SCIM Issues Radovan, Thanks for all of the excellent feedback. You have brought up some great points! > I have noticed that optional attributes are explicitly marked, but the > "externalId" is not marked in any way. Maybe this is just an unclear wording? This is supposed to be optional. I agree that the spec should be explicit about this. Regarding externalId-per-consumer, this topic came up at IIW in October. One thought was to allow this be multi-valued and have the type specify some sort of URN for the consumer. The discussion ended there, though. > We have done a lot of IDM deployments in last 10 years and requirement > to change usernames was there in a vast majority of them. I agree. In Active Directory, it seems like samAccountName (which is mutable) would be modeled as the SCIM userName. I don't see any problem in dropping the immutability requirement from the spec. > The problem with a very large groups is that the list of returned > members is huge. This is not efficient to retrieve every time. This is issue 43 in the issue tracker. Hopefully this can get fixed in SCIM 2.0. http://code.google.com/p/scim/issues/detail?id=43 > However, all changes have to be made to the "members" attribute of the > group, which is a bit confusing. It can also be a critical problem for > applications that require at least one group to create a user. Such > applications just cannot be provisioned with SCIM currently. Making > "groups" (in user) read-write may really help here. I believe that when we first bumped into this at IIW in October, we proposed an extension to the User schema that allows specifying the default group upon creation. If this is a common case (requiring a group upon creation), it should be considered in the core spec rather than just as a workaround. > Adding a group membership to a user can be passed together with > "create user" operation. This "batch" can be used by server to "recompose" > the operation to a create operation that includes a group membership > if that is needed. And it does not affect the protocol too much. > However, this approach is somehow incompatible with REST. SCIM has a /Bulk endpoint that can be used for batching, but the spec says that ordering is not guaranteed. Perhaps this could be used if the service provider is smart enough, but it could be difficult to implement efficiently. > I see that the presence of PATCH operation can make this efficient. > But does SCIM rely on the fact that every protocol will have this > efficient way of attribute modification? PATCH support is not required by the spec, but I would imagine that any service provider that has large data (eg - a directory server) would strive to implement it for their own good. I'm not sure how this would be done in different protocols, though. This needs more thought for non-REST protocols. > Maybe it is worth to think if there is a way that will still allows > the "delta logic" as a primary mechanism but will not be that > confusing and difficult to implement for legacy systems. E.g. > reflecting group membership to a read-write user attribute can make > "PUT" feasible as the conflicts on large groups will be avoided and a > (concurrency) conflict on a single user is unlikely (and hence the optimistic locking may be efficient). A read-write groups attribute on the User has been discussed quite a bit. I agree that it is much easier to manipulate group membership via the user than the other way around. As Samuel pointed out, the groups attribute contains groups that are not only directly assigned, inherited, or dynamically calculated. As such, it is difficult to allow modification of this attribute since some groups (eg - dynamic) cannot be removed or added. Various ideas were considered to allow this (splitting dynamic and nested groups into a separate attribute, etc...), but they all had their own complications. Because of this we decided to stick with the "edit membership via the group" philosophy. > And most importantly: I think there should be a clear and uniform way > how to deal with assignment of the things that user belongs to. I call > them "entitlements" but I see that SCIM has a slightly different > terminology and does not have a common concept that unifies SCIM > groups, roles and other entitlements. And I think this is the missing > piece that is one of the causes of this confusion. You are right that a group can be considered an entitlement and there is some confusion here. Concrete examples may help. This is how I think about the three: - Entitlements: These are individual low-level access grants that are assigned directly to a user. An example granting a user the "Write" right on a resource called DevWiki. This might be modeled as "write:DevWiki" or something. - Roles: These describe what roles or job functions the user holds within the organization (eg - Developer, Sales Executive, Student, etc...). In some systems, having a role might cause a user to be granted individual entitlements or group memberships. These relationships are not specified in SCIM since roles are opaque. - Groups: These are groupings of users that may support nesting. In some cases they are used for access control (security groups) and in other cases they are used for other purposes (eg - distribution groups). Security groups may be able to grant entitlements to a user. I think that there is merit in keeping these concepts separated. I can conceive of future extensions to expose /Entitlements and /Roles endpoints that allow reading and updating an entitlement catalog and role model. There has been some confusion around these three attributes, so it is probably worth trying to clean this up in the spec. >> Minor issue: Canonical types for members are capitalizes while other >> types start with lowercase letter. > > Good catch, it might be a legacy from the time when the endpoints > where called User and Group and not Users and Groups. It is probably legacy. There are actually currently some discussions around this wrt allowing the group members to be dereferenced. "User" and "Group" match the name in the resource schema (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-s chema) and it may be worth keeping these to allow dereferencing. > Should not authenticationSchema be outside of the SCIM core schema? > Schema defines no transport protocol and the authentication types > clearly depend on transport protocols. Maybe a binding specificiation > is a better place for authenticationSchema definition? This is defined in the ServiceProviderConfig, which regardless of the transport protocol should be available. You're right that this assumes the REST protocol. Perhaps authenticationSchemas should have a sub-attribute that specifies the applicable protocol? > User has userName, displayName and name/formatted. Group has displayName. > Resource has name as string. It is confusing. It is also quite > inconsistent and makes if difficult to support uniform representation > of "objects" in the underlying SCIM implementation. Maybe Group could use name instead of displayName? I kind of like displayName because this might be different from a raw name (eg - Super Users vs. cn=Super Users,dc=foo,...). This doesn't seem like much of an issue to me. Looking at the confusion between userName, displayName, formattedName is worthwhile, though. > Resource Schema has description, but user and groups does not? > Description may come handy in any object. I could see this for groups but haven't ever really seen this for users. > The attributes/type definition in Resource Schema does not specify > whether the value is URL or QName or plain string. If a plain string > (which seems to be the case by looking at the examples) how to map > that string to XSD QNames? Are only XSD data types possible? The > specification says "SHOULD not" not "MUST NOT", therefore an extension > mechanism should be specified here. Yes these are based on XSD data types and are not currently extensible. Are there any data types that are not currently covered by the spec? >>> If the type is mandatory for every multi-valued attribute (is "hardcoded" >>> in the core schema specification), is there any point to define it >>> explicitly in all the resource schemas? >> Could you be more specific around hardcoded? > > The "type" attribute is explicitly defined for any multi-valued > attributes in the specification (section 3.2). Therefore it is a part > of the meta-schema rather than schema. May there be a multi-valued > attribute that does not have "type"? If yes then the "type" should be > marked as optional in the specification. If not then there is no point > of specifying "type" in every run-time schema because it just must > always be there. I believe that the type sub-attribute is optional. I believe that generally in the schema spec if an attribute doesn't say REQUIRED than it is implied to be optional. This should be made more explicit. >>> Is ordering of multi-value attribute values significant? No, >>> multivalued >>attributes are unordered. This has made mapping to e.g. SAML harder. > > That is a crucial point that should be documented in the schema. I was > explicitly looking for that and haven't found it. I agree. > Oh. This "encapsulating" of extensions into a specific parts of the > JSON structure somehow eluded me. Anyway, there is still a problem > with future schema extensions. E.g. if a future version of SCIM > defines new user attribute "ext1" it can break valid existing > "documents" and therefore is a risk for compatibility. Maybe it would > be a good idea to adopt the XML "best practice" of quarantining extensibility points into dedicated elements? > E.g. it can look like this in JSON: > > { > "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], > "userName": "kalle", > "extension": { > "ext1": { > employeeNumber: "abc123" > }, > "ext2": { > employeeNumber: "123abc" > } > } } Extensions are actually defined with URNs (eg - urn:scim:schemas:extension:enterprise:1.0), so it is pretty unlikely that there will be conflicts. See an example in the JSON representation of an enterprise user here: http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. > I hope that the authors of SCIM will try to correct the obvious > problems of the specification and focus on proving that it works > before going any further. The only reasonable way to go is: working > software first, standards second. Implementations have been developed in parallel with the spec, and there were 9 of them that worked (at least to some extent) together just a few weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (myself included) have always had an eye toward making something that is practical, useful, and actually works. As you have found, there are definitely some holes and warts that need to be addressed. I really appreciate your feedback and will make sure that some of these issues make it into the issue tracker. --Kelly _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_018E_01CD1CC3.DC975C80 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzIxNTk0MFowIwYJKoZIhvcNAQkEMRYEFPufXqpJ8kY82gVPqEB9zFk7KV7NMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGABYYH6TM1RyeIWxNTHsRemQMTGkpIE4v/E52fBe4LFVJw WyWLqLsdrm39QMk1dt5xMbLSUquTiks7JfiNrjb4ZUFA6Oavepkk7UABDuQKjt5W4lnTy59a6yh6 5OR38bGnoUAfmPtW3KGLhspYs7w8JnsT2w59XKeN4j+2C0jJ+CcAAAAAAAA= ------=_NextPart_000_018E_01CD1CC3.DC975C80-- From phil.hunt@oracle.com Tue Apr 17 15:06: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 6976021F8453 for ; Tue, 17 Apr 2012 15:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.622 X-Spam-Level: X-Spam-Status: No, score=-9.622 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=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 EiQTx4Lckzfk for ; Tue, 17 Apr 2012 15:05:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id EC58621F844C for ; Tue, 17 Apr 2012 15:05:56 -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 q3HM5p79028215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2012 22:05:52 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 q3HM5oNA002817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 22:05:51 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3HM5nDv030015; Tue, 17 Apr 2012 17:05:49 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Apr 2012 15:05:49 -0700 References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A02F2@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A02F2@EX2K10MB1.corp.yaanatech.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Tue, 17 Apr 2012 15:06:39 -0700 To: Michael Hammer X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090202.4F8DE941.004F,ss=1,re=-2.300,fgs=0 Cc: "radovan.semancik@evolveum.com" , "scim@ietf.org" , "kelly.grizzle@sailpoint.com" Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 17 Apr 2012 22:06:01 -0000 More flexibility in this case leads to interpretation, mapping and interop i= ssues. Better to define and have clear meaning so outliers can at least map to the m= odel.=20 Phil On 2012-04-17, at 14:59, Michael Hammer wrote= : > I agree with you that loosely defined usage and habit can lead to very mud= dy > waters. >=20 > The way I rationalized this for myself was to dig deeper. Is someone says= > that a user or group is assigned a role, what does that mean? > If my role is IT wizard, it usually means I have powers (tokens?) that all= ow > me to do X, Y, and Z, which are atomic or binary permissions. > I either get to do it or not. Having both entitlements and roles allows a= n > M:N mapping. =20 > A role is a collection of powers versus having to repeat a laundry least > each time. >=20 > This allow later the subsequent ability to assign a set of permissions to a= > User or Group. (M:X, M:Y, N:X, N:Y mappings) >=20 > I saw role and group as distinct in that those sets parallel the What vers= us > Who of the more atomic Entitlement and User. =20 > Again the User and Group allow X:Y mapping so one person can belong to > different groups. > Similarly, the actions of ascertaining Identity is conducted first (who), > followed by application of access rules (what you can then do). >=20 > The alternative IMHO is that if there is no distinction, and if role, > entitlement, and group are synonyms,=20 > you could then eliminate one or more redundant terms without loss and have= > only Users and Entitlements=20 > (or whichever term you select to keep). (N:Y mappings only) >=20 > So, I guess this boils down to whether there is need to have zero, one, or= > two types of sets. > If one, is that a set of entitlements (aka role) that gets assigned one by= > one to each User? > Or, is that a set of Users that gets assigned one by one to each > Entitlement? > (Note, I think you use role and group as synonymous.) >=20 > My thinking was that having more levels of indirection/aggregation would > provide more flexibility. > Wonder what others are thinking? >=20 > Mike >=20 >=20 > -----Original Message----- > From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 > Sent: Tuesday, April 17, 2012 5:03 PM > To: Michael Hammer; radovan.semancik@evolveum.com; scim@ietf.org > Subject: RE: [scim] SCIM Issues >=20 > This makes sense to me. However, I have seen roles be used for more than > this. A common example is using roles to define separation of duty > policies, such as disallowing a person from being a "Vendor Creator" and > "Payment Approver". Often these role have entitlements under them, but no= t > always. >=20 > I have also seen roles be split into different types - business roles and I= T > roles. A business role is simply something that describes who a person is= > within their organization. This can be assigned directly to the user or c= an > be dynamically assigned by some sort of a matching rule (eg - "if your tit= le > is 'Sales Level III' you get 'Sales Engineer' role). An IT role is more > like what you are describing, a group of entitlements. These different > types of roles can be related to each other through various relationships.= > For example, a "Developer" business role might give default access to (or > require) the "Developer Version Control" IT role and permit access to (but= > not require) the "Developer Data Modeling" IT role. >=20 > Also, if a role is nothing more than a set of entitlements, how is this > different from a group? Security groups are generally granted some set of= > entitlements and then users are added as group members to be granted those= > entitlements. >=20 > All of this to say that while roles are often a set of entitlements, I don= 't > think that this is always the case. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: Michael Hammer [mailto:michael.hammer@yaanatech.com] > Sent: Tuesday, April 17, 2012 1:51 PM > To: Kelly Grizzle; radovan.semancik@evolveum.com; scim@ietf.org > Subject: RE: [scim] SCIM Issues >=20 > Kelly, >=20 > I am not sure I like the definitions you have for role. > Another international spec I looked over recently defines role as a set of= > entitlements. > That makes more sense to me. >=20 > Group=3Dset of Users > Role=3Dset of Entitlements >=20 > The name of the role would give one an idea what entitlements to assign th= at > role. > Powers get inherited down the line: >=20 > Entitlement -> Role -> Group -> User >=20 > Pointers can be set in the opposite direction of the arrows. > And of course, leaving a role or group or both out of the chain is > permitted. >=20 > Mike Sense? >=20 > Mike >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of > Kelly Grizzle > Sent: Tuesday, April 17, 2012 2:12 PM > To: Radovan Semancik; scim@ietf.org > Subject: Re: [scim] SCIM Issues >=20 > Radovan, >=20 > Thanks for all of the excellent feedback. You have brought up some great > points! >=20 >=20 >> I have noticed that optional attributes are explicitly marked, but the=20= >> "externalId" is not marked in any way. Maybe this is just an unclear > wording? >=20 > This is supposed to be optional. I agree that the spec should be explicit= > about this. Regarding externalId-per-consumer, this topic came up at IIW i= n > October. > One thought was to allow this be multi-valued and have the type specify so= me > sort of URN for the consumer. The discussion ended there, though. >=20 >=20 >> We have done a lot of IDM deployments in last 10 years and requirement=20= >> to change usernames was there in a vast majority of them. >=20 > I agree. In Active Directory, it seems like samAccountName (which is > mutable) would be modeled as the SCIM userName. I don't see any problem i= n > dropping the immutability requirement from the spec. >=20 >=20 >> The problem with a very large groups is that the list of returned=20 >> members is huge. This is not efficient to retrieve every time. >=20 > This is issue 43 in the issue tracker. Hopefully this can get fixed in SC= IM > 2.0. http://code.google.com/p/scim/issues/detail?id=3D43 >=20 >=20 >> However, all changes have to be made to the "members" attribute of the=20= >> group, which is a bit confusing. It can also be a critical problem for=20= >> applications that require at least one group to create a user. Such=20 >> applications just cannot be provisioned with SCIM currently. Making=20 >> "groups" (in user) read-write may really help here. >=20 > I believe that when we first bumped into this at IIW in October, we propos= ed > an extension to the User schema that allows specifying the default group > upon creation. If this is a common case (requiring a group upon creation)= , > it should be considered in the core spec rather than just as a workaround.= >=20 >=20 >> Adding a group membership to a user can be passed together with=20 >> "create user" operation. This "batch" can be used by server to "recompose= " >> the operation to a create operation that includes a group membership=20 >> if that is needed. And it does not affect the protocol too much. >> However, this approach is somehow incompatible with REST. >=20 > SCIM has a /Bulk endpoint that can be used for batching, but the spec says= > that ordering is not guaranteed. Perhaps this could be used if the servic= e > provider is smart enough, but it could be difficult to implement > efficiently. >=20 >=20 >> I see that the presence of PATCH operation can make this efficient.=20 >> But does SCIM rely on the fact that every protocol will have this=20 >> efficient way of attribute modification? >=20 > PATCH support is not required by the spec, but I would imagine that any > service provider that has large data (eg - a directory server) would striv= e > to implement it for their own good. I'm not sure how this would be done i= n > different protocols, though. This needs more thought for non-REST > protocols. >=20 >=20 >> Maybe it is worth to think if there is a way that will still allows=20 >> the "delta logic" as a primary mechanism but will not be that=20 >> confusing and difficult to implement for legacy systems. E.g. >> reflecting group membership to a read-write user attribute can make=20 >> "PUT" feasible as the conflicts on large groups will be avoided and a >> (concurrency) conflict on a single user is unlikely (and hence the > optimistic locking may be efficient). >=20 > A read-write groups attribute on the User has been discussed quite a bit. = I > agree that it is much easier to manipulate group membership via the user > than the other way around. As Samuel pointed out, the groups attribute > contains groups that are not only directly assigned, inherited, or > dynamically calculated. As such, it is difficult to allow modification of= > this attribute since some groups (eg - dynamic) cannot be removed or added= . > Various ideas were considered to allow this (splitting dynamic and nested > groups into a separate attribute, etc...), but they all had their own > complications. Because of this we decided to stick with the "edit > membership via the group" philosophy. >=20 >=20 >> And most importantly: I think there should be a clear and uniform way=20 >> how to deal with assignment of the things that user belongs to. I call=20= >> them "entitlements" but I see that SCIM has a slightly different=20 >> terminology and does not have a common concept that unifies SCIM=20 >> groups, roles and other entitlements. And I think this is the missing=20 >> piece that is one of the causes of this confusion. >=20 > You are right that a group can be considered an entitlement and there is > some confusion here. Concrete examples may help. This is how I think abo= ut > the > three: >=20 > - Entitlements: These are individual low-level access grants that are > assigned > directly to a user. An example granting a user the "Write" right on a > resource called DevWiki. This might be modeled as "write:DevWiki" or > something. >=20 > - Roles: These describe what roles or job functions the user holds within > the > organization (eg - Developer, Sales Executive, Student, etc...). In som= e > systems, having a role might cause a user to be granted individual > entitlements or group memberships. These relationships are not specifie= d > in > SCIM since roles are opaque. >=20 > - Groups: These are groupings of users that may support nesting. In some > cases > they are used for access control (security groups) and in other cases > they > are used for other purposes (eg - distribution groups). Security groups= > may > be able to grant entitlements to a user. >=20 > I think that there is merit in keeping these concepts separated. I can > conceive of future extensions to expose /Entitlements and /Roles endpoints= > that allow reading and updating an entitlement catalog and role model. > There has been some confusion around these three attributes, so it is > probably worth trying to clean this up in the spec. >=20 >=20 >>> Minor issue: Canonical types for members are capitalizes while other=20 >>> types start with lowercase letter. >>=20 >> Good catch, it might be a legacy from the time when the endpoints=20 >> where called User and Group and not Users and Groups. >=20 > It is probably legacy. There are actually currently some discussions arou= nd > this wrt allowing the group members to be dereferenced. "User" and "Group= " > match the name in the resource schema > (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource= -s > chema) > and it may be worth keeping these to allow dereferencing. >=20 >=20 >> Should not authenticationSchema be outside of the SCIM core schema?=20 >> Schema defines no transport protocol and the authentication types=20 >> clearly depend on transport protocols. Maybe a binding specificiation=20 >> is a better place for authenticationSchema definition? >=20 > This is defined in the ServiceProviderConfig, which regardless of the > transport protocol should be available. You're right that this assumes th= e > REST protocol. Perhaps authenticationSchemas should have a sub-attribute > that specifies the applicable protocol? >=20 >=20 >> User has userName, displayName and name/formatted. Group has displayName.= >> Resource has name as string. It is confusing. It is also quite=20 >> inconsistent and makes if difficult to support uniform representation=20 >> of "objects" in the underlying SCIM implementation. >=20 > Maybe Group could use name instead of displayName? I kind of like > displayName because this might be different from a raw name (eg - Super > Users vs. cn=3DSuper Users,dc=3Dfoo,...). This doesn't seem like much of a= n > issue to me. Looking at the confusion between userName, displayName, > formattedName is worthwhile, though. >=20 >=20 >> Resource Schema has description, but user and groups does not?=20 >> Description may come handy in any object. >=20 > I could see this for groups but haven't ever really seen this for users. >=20 >=20 >> The attributes/type definition in Resource Schema does not specify=20 >> whether the value is URL or QName or plain string. If a plain string=20 >> (which seems to be the case by looking at the examples) how to map=20 >> that string to XSD QNames? Are only XSD data types possible? The=20 >> specification says "SHOULD not" not "MUST NOT", therefore an extension=20= >> mechanism should be specified here. >=20 > Yes these are based on XSD data types and are not currently extensible. A= re > there any data types that are not currently covered by the spec? >=20 >=20 >>>> If the type is mandatory for every multi-valued attribute (is > "hardcoded" >>>> in the core schema specification), is there any point to define it=20 >>>> explicitly in all the resource schemas? >>> Could you be more specific around hardcoded? >>=20 >> The "type" attribute is explicitly defined for any multi-valued=20 >> attributes in the specification (section 3.2). Therefore it is a part=20 >> of the meta-schema rather than schema. May there be a multi-valued=20 >> attribute that does not have "type"? If yes then the "type" should be=20 >> marked as optional in the specification. If not then there is no point=20= >> of specifying "type" in every run-time schema because it just must=20 >> always > be there. >=20 > I believe that the type sub-attribute is optional. I believe that general= ly > in the schema spec if an attribute doesn't say REQUIRED than it is implied= > to be optional. This should be made more explicit. >=20 >=20 >>>> Is ordering of multi-value attribute values significant? No,=20 >>>> multivalued >>> attributes are unordered. This has made mapping to e.g. SAML harder. >>=20 >> That is a crucial point that should be documented in the schema. I was=20= >> explicitly looking for that and haven't found it. >=20 > I agree. >=20 >=20 >> Oh. This "encapsulating" of extensions into a specific parts of the=20 >> JSON structure somehow eluded me. Anyway, there is still a problem=20 >> with future schema extensions. E.g. if a future version of SCIM=20 >> defines new user attribute "ext1" it can break valid existing=20 >> "documents" and therefore is a risk for compatibility. Maybe it would=20 >> be a good idea to adopt the XML "best practice" of quarantining > extensibility points into dedicated elements? >> E.g. it can look like this in JSON: >>=20 >> { >> "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], >> "userName": "kalle", >> "extension": { >> "ext1": { >> employeeNumber: "abc123" >> }, >> "ext2": { >> employeeNumber: "123abc" >> } >> } } >=20 > Extensions are actually defined with URNs (eg - > urn:scim:schemas:extension:enterprise:1.0), > so it is pretty unlikely that there will be conflicts. See an example in > the JSON representation of an enterprise user here: > http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. >=20 >=20 >> I hope that the authors of SCIM will try to correct the obvious=20 >> problems of the specification and focus on proving that it works=20 >> before going any further. The only reasonable way to go is: working=20 >> software first, standards second. >=20 > Implementations have been developed in parallel with the spec, and there > were 9 of them that worked (at least to some extent) together just a few > weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent). The > authors (myself > included) have always had an eye toward making something that is practical= , > useful, and actually works. As you have found, there are definitely some > holes and warts that need to be addressed. >=20 > I really appreciate your feedback and will make sure that some of these > issues make it into the issue tracker. >=20 > --Kelly >=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 radovan.semancik@evolveum.com Wed Apr 18 02:16: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 399B421F8603 for ; Wed, 18 Apr 2012 02:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 USkj9HYBT+cY for ; Wed, 18 Apr 2012 02:16:11 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id D1DD321F85F2 for ; Wed, 18 Apr 2012 02:16:10 -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 54A8CA43E4F for ; Wed, 18 Apr 2012 11:16:07 +0200 (CEST) Message-ID: <4F8E8655.3050706@evolveum.com> Date: Wed, 18 Apr 2012 11:16:05 +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: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 18 Apr 2012 09:16:15 -0000 Hi, >> I hope that the authors of SCIM will try to correct the obvious problems of >> the specification and focus on proving that it works before going any >> further. The only reasonable way to go is: working software first, standards >> second. > Implementations have been developed in parallel with the spec, and there were 9 > of them that worked (at least to some extent) together just a few weeks ago > (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (myself > included) have always had an eye toward making something that is practical, > useful, and actually works. As you have found, there are definitely some holes > and warts that need to be addressed. The problem is that some holes cannot be uncovered by just looking at the spec. I have tried my best but I'm quite sure that I have missed some. Interop event is also not a definitive answer. I really appreciate that such events happen, but these are still more-or-less laboratory environment. And interoperability is not the only issue here. Interop events cannot tell if the protocol is sufficiently complete to be practical. If the protocol is not complete, implementers will create their own extensions to cover the missing parts. And such extensions are very likely to be incompatible. This is what happened to X.509 and also to HTML in the early days. I guess that SCIM is now validated considerably better than SPML. But that is till not enough. The protocol should be tried in several real deployments before it is standardized. Reality always has a bunch of unexpected surprises for engineers. -- Radovan Semancik Software Architect evolveum.com From radovan.semancik@evolveum.com Wed Apr 18 02:44: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 D20C421F8621 for ; Wed, 18 Apr 2012 02:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 NsLoD9VrLA-W for ; Wed, 18 Apr 2012 02:44:21 -0700 (PDT) Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6433721F861D for ; Wed, 18 Apr 2012 02:44:21 -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 6B706A43E43 for ; Wed, 18 Apr 2012 11:44:20 +0200 (CEST) Message-ID: <4F8E8CF3.50407@evolveum.com> Date: Wed, 18 Apr 2012 11:44:19 +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 CC: "scim@ietf.org" References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 18 Apr 2012 09:44:25 -0000 I have few remarks to the "roles" discussion: If a role is a collection of entitlements, what about hierarchical roles (roles that container roles)? Do we need to broaden the definition to "collection of entitlements and roles"? Or do we just assume that a role is an entitlement? But there is a more important question: are we going into too much detail here? A target system ("resource" in IDM speak) may work with really rich and complex roles represented by intricate structure of the subject-action-object triples, sub-roles of various types, bound to the organizational structure and all that spiced up with temporal constraints and other decorations. But the IDM systems usually know nothing about this. They don't need to. They only see such role as yet another entitlement and assign it to the user (and actually most IDM systems just see it as yet another (string) value of some account attribute). The roles in the IDM system are much higher abstraction than the roles in the resource. These are actually quite a different kinds of animal. What I see here is a attempt to encompass both concepts into a single framework/definition. I don't think that is feasible right now. Is the scope of SCIM management of roles/groups/whateverEntitilementThereMayBe? Or is the scope only assigning such things to users? If it is the latter case than maybe we do not need to see the difference between group, role, entitlement, organizational unit, team, project, privilege, etc. Just define a class of "assignable" entities and provide a way how to assign them to users. That should be enough. -- Radovan Semancik Software Architect evolveum.com On 04/17/2012 11:03 PM, Kelly Grizzle wrote: > This makes sense to me. However, I have seen roles be used for more than this. A common example is using roles to define separation of duty policies, such as disallowing a person from being a "Vendor Creator" and "Payment Approver". Often these role have entitlements under them, but not always. > > I have also seen roles be split into different types - business roles and IT roles. A business role is simply something that describes who a person is within their organization. This can be assigned directly to the user or can be dynamically assigned by some sort of a matching rule (eg - "if your title is 'Sales Level III' you get 'Sales Engineer' role). An IT role is more like what you are describing, a group of entitlements. These different types of roles can be related to each other through various relationships. For example, a "Developer" business role might give default access to (or require) the "Developer Version Control" IT role and permit access to (but not require) the "Developer Data Modeling" IT role. > > Also, if a role is nothing more than a set of entitlements, how is this different from a group? Security groups are generally granted some set of entitlements and then users are added as group members to be granted those entitlements. > > All of this to say that while roles are often a set of entitlements, I don't think that this is always the case. > > --Kelly From trey.drake@unboundid.com Wed Apr 18 03:04: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 CD1ED21F860B for ; Wed, 18 Apr 2012 03:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 XehhwP0TV6m3 for ; Wed, 18 Apr 2012 03:04:53 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0525E21F864C for ; Wed, 18 Apr 2012 03:04:52 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4950500wgb.13 for ; Wed, 18 Apr 2012 03:04:52 -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=su4/oPzD1pcih+cogTb0dWgiJzE72taqF99cbTUG05A=; b=T+CoEnjYCVXYS76Ui70f+OoduTPtG12FAnWD5GWbZhemHPXJnbQ9/P+xM6jIICKkJB QPbDaNWO+n9rzRNJ8JPAJF+ivrASMaR159jbsSrhexG4yTittqhRF1uUQ+Vy/SG7t4FP K0B1s2n6FVp2lVO80Uaw9M0i3cXwjPp0t9lV71dTydsQ/0rzIfHx084pYiSd+vi+j9Y8 taXZBUNWiAw8aZCiY9fe3YA2J/yOtYjGHNn7khlwKMXLh18FAzHa8Lha5LyFPgiiveWg YXagWPW53WEJgT+WOPLlTv3ESoLHoc1OhSFyKRa+qC/At7UEaW8qEwDcX9WzkNh/qLpH r5lA== Received: by 10.180.91.168 with SMTP id cf8mr4770272wib.0.1334743491962; Wed, 18 Apr 2012 03:04:51 -0700 (PDT) Received: from surfer-30-10-237.surfnet.iacbox (nat-LX.gw2.ush2.tnib.de. [86.110.65.59]) by mx.google.com with ESMTPS id h8sm53710464wix.4.2012.04.18.03.04.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 03:04:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_E84A87D0-8A9A-40BE-95D5-15307C33266C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Trey Drake In-Reply-To: <4F8E8655.3050706@evolveum.com> Date: Wed, 18 Apr 2012 12:04:48 +0200 Message-Id: <505C62A4-9BC3-4A06-9B66-CDEA5B955D55@unboundid.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F8E8655.3050706@evolveum.com> To: Radovan Semancik X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnCPISoNLspUMEnHPhw+7li1swP6TB1YFif4cYKXQNSyp7vMAPDmRQpopY7IMo2lX6tuEFg Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 18 Apr 2012 10:04:57 -0000 --Apple-Mail=_E84A87D0-8A9A-40BE-95D5-15307C33266C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Radovan, I'm not sure what you're looking for - SCIM, in its current form, has = been presented to the IETF as a standards track specification. The = intent of doing so is to widen the audience so as to improve the = specification, formalize governance, and all the usual goodness SDOs = provide. If the SCIM WG is approved the effort has just begun. In the = meantime, we're rev'ing the spec, holding interops and gaining = operational experience. Yes, IDM vendors and SaaS providers alike are = rolling out SCIM implementations as SCIM is addressing a pain point = today. Like it or not this is common practice. I don't see this as a = negative, rather its a positive - implementors are at least attempting = to build off a spec that has a chance of interop vs rolling their own. =20= Thanks, Trey On Apr 18, 2012, at 11:16 AM, Radovan Semancik wrote: > Hi, >=20 >>> I hope that the authors of SCIM will try to correct the obvious = problems of >>> the specification and focus on proving that it works before going = any >>> further. The only reasonable way to go is: working software first, = standards >>> second. >> Implementations have been developed in parallel with the spec, and = there were 9 >> of them that worked (at least to some extent) together just a few = weeks ago >> (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors = (myself >> included) have always had an eye toward making something that is = practical, >> useful, and actually works. As you have found, there are definitely = some holes >> and warts that need to be addressed. >=20 > The problem is that some holes cannot be uncovered by just looking at = the spec. I have tried my best but I'm quite sure that I have missed = some. Interop event is also not a definitive answer. I really appreciate = that such events happen, but these are still more-or-less laboratory = environment. And interoperability is not the only issue here. Interop = events cannot tell if the protocol is sufficiently complete to be = practical. If the protocol is not complete, implementers will create = their own extensions to cover the missing parts. And such extensions are = very likely to be incompatible. This is what happened to X.509 and also = to HTML in the early days. >=20 > I guess that SCIM is now validated considerably better than SPML. But = that is till not enough. The protocol should be tried in several real = deployments before it is standardized. Reality always has a bunch of = unexpected surprises for engineers. >=20 > --=20 >=20 > Radovan Semancik > Software Architect > evolveum.com >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_E84A87D0-8A9A-40BE-95D5-15307C33266C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM9jCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGujCCBaKg AwIBAgIDAopvMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNTEzMTY1MjQ5WhcNMTIwNTEzMDU0NzU2WjBLMSAwHgYDVQQNExc0MjU3NjEteUxidzRqMkwy Z0FqSG92UzEnMCUGCSqGSIb3DQEJARYYdHJleS5kcmFrZUB1bmJvdW5kaWQuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqid9tc427LEtBahNAplYUQztLpGRwt7J1hxi3mHkMBzr s3LxhGspxGij4JZogkqolFpIhu0amwHXsDv7DbkET1O8TN2S2ttetn2o/gQMhAlXp7MP4SfHnIHL awiDyKZ96l49FFuOt107G9SYpOceuY+AfBssNfxVpTfzqvBzQ/zdbGwqg+ndyPmsWZCYc036/dHV VWDPpLbohj8GmtoNp8p2LjXe4hOvOfxNnlg6hRlHwiPkudSpEaHwW5dlQUjtcBNvowCq2uq2fbQq 5jyswWRGRIQINo4UgSsyDAB5SfagyGMx32EUGrx1NJWOHWK3eqPknuYdgtU2nJZ+aTtBpQIDAQAB o4IDYzCCA18wCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBTFEY17wcVFokE4T9NZv3jxliACzjAfBgNVHSMEGDAWgBRTcu2SnODa ywFcfH6WNU7y1LhRgjAjBgNVHREEHDAagRh0cmV5LmRyYWtlQHVuYm91bmRpZC5jb20wggHRBgNV HSAEggHIMIIBxDCCAcAGCysGAQQBgbU3AQICMIIBrzAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCCAUUGCCsGAQUFBwICMIIBNzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoIBClRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IHBvbGljeSBhbmQgbWF5IGJlIHJlbGllZCB1cG9u IG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGFuZCBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLiBMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3Ns LmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNz bC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAfcC87DDCF7sIIY5qIDIS7MmSAJjr GlCfGP11cJrO88bsQiSgtJYYeIATEUsH1r78aJOzU8p8P/lOrSoDr3kxVlUaOam6xIvlW9Uv6AUN DBjYeDUMaEIwPl/Eox0tvZPas4JwW1K+N085ya1IKCK/l7x2K97JQqQhE44ymJ873mcEbBNz6HOo JtyNMc204G0mREpQs4RSb7vsT9x93QUs6QpP/Mn/w+HaXQQzgs4HmfgL8z+qlH4vX4S/rKvwv95m fdCIrdSBAeSKBco9hHTIny9XpkTR2qk1Uq0eqSk1LtufDoQy9c5KKQKINCKrjioMseRufmAY/0Nu VbekcRMyIDGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKKbzAJ BgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x MjA0MTgxMDA0NDlaMCMGCSqGSIb3DQEJBDEWBBQob0IgQhMKPjmrGO9M53aLjjoFjjCBpQYJKwYB BAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKKbzCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAopvMA0GCSqGSIb3DQEB AQUABIIBAEOobndN40JBqvWCcjzEdVguuX0mmKmZQn45S6eDLRCsCK4+g8b65DyTCsmvXyBnqnGZ B5Z7j9QUWO3hEnmOQmpspikW0wsajXor5wAULtXWgGC2yA/q3PFD9V9+5kVGDLBHF4TspEIP5gOQ X2wTh8zq+UbiXUhGt+kXpwkOCFmAwRv+JY4Xu7QMO26HiU5deycFaqx44dQQDpFJbaY1mSkkaHrU +xw/FjV0Js5dJWENyXYDZu1Z2O2mFj55dZYMAMOKR0J9VXspty/25qLg457pCmoyUpmc6b4WYY1g kxPaPDR4zGmepgGU10M0KLh3aZroYn8dfo3eA504F/SneWUAAAAAAAA= --Apple-Mail=_E84A87D0-8A9A-40BE-95D5-15307C33266C-- From michael.hammer@yaanatech.com Wed Apr 18 07:15: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 CAF8221F859B for ; Wed, 18 Apr 2012 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=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 i9fI1wb+XwAp for ; Wed, 18 Apr 2012 07:15:28 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0621F8597 for ; Wed, 18 Apr 2012 07:15:28 -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; Wed, 18 Apr 2012 07:15:27 -0700 From: Michael Hammer To: "phil.hunt@oracle.com" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQAD//4ylAIAAhR+AgACZPnA= Date: Wed, 18 Apr 2012 14:15:26 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0B9E@EX2K10MB1.corp.yaanatech.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A02F2@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004D_01CD1D4C.2BF74DC0" MIME-Version: 1.0 Cc: "radovan.semancik@evolveum.com" , "scim@ietf.org" , "kelly.grizzle@sailpoint.com" Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 18 Apr 2012 14:15:32 -0000 ------=_NextPart_000_004D_01CD1D4C.2BF74DC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Good point. That is the trade-off. Mike -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, April 17, 2012 6:07 PM To: Michael Hammer Cc: kelly.grizzle@sailpoint.com; radovan.semancik@evolveum.com; scim@ietf.org Subject: Re: [scim] SCIM Issues More flexibility in this case leads to interpretation, mapping and interop issues. Better to define and have clear meaning so outliers can at least map to the model. Phil On 2012-04-17, at 14:59, Michael Hammer wrote: > I agree with you that loosely defined usage and habit can lead to very > muddy waters. > > The way I rationalized this for myself was to dig deeper. Is someone > says that a user or group is assigned a role, what does that mean? > If my role is IT wizard, it usually means I have powers (tokens?) that > allow me to do X, Y, and Z, which are atomic or binary permissions. > I either get to do it or not. Having both entitlements and roles > allows an M:N mapping. > A role is a collection of powers versus having to repeat a laundry > least each time. > > This allow later the subsequent ability to assign a set of permissions > to a User or Group. (M:X, M:Y, N:X, N:Y mappings) > > I saw role and group as distinct in that those sets parallel the What > versus Who of the more atomic Entitlement and User. > Again the User and Group allow X:Y mapping so one person can belong to > different groups. > Similarly, the actions of ascertaining Identity is conducted first > (who), followed by application of access rules (what you can then do). > > The alternative IMHO is that if there is no distinction, and if role, > entitlement, and group are synonyms, you could then eliminate one or > more redundant terms without loss and have only Users and Entitlements > (or whichever term you select to keep). (N:Y mappings only) > > So, I guess this boils down to whether there is need to have zero, > one, or two types of sets. > If one, is that a set of entitlements (aka role) that gets assigned > one by one to each User? > Or, is that a set of Users that gets assigned one by one to each > Entitlement? > (Note, I think you use role and group as synonymous.) > > My thinking was that having more levels of indirection/aggregation > would provide more flexibility. > Wonder what others are thinking? > > Mike > > > -----Original Message----- > From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] > Sent: Tuesday, April 17, 2012 5:03 PM > To: Michael Hammer; radovan.semancik@evolveum.com; scim@ietf.org > Subject: RE: [scim] SCIM Issues > > This makes sense to me. However, I have seen roles be used for more > than this. A common example is using roles to define separation of > duty policies, such as disallowing a person from being a "Vendor > Creator" and "Payment Approver". Often these role have entitlements > under them, but not always. > > I have also seen roles be split into different types - business roles > and IT roles. A business role is simply something that describes who > a person is within their organization. This can be assigned directly > to the user or can be dynamically assigned by some sort of a matching > rule (eg - "if your title is 'Sales Level III' you get 'Sales > Engineer' role). An IT role is more like what you are describing, a > group of entitlements. These different types of roles can be related to each other through various relationships. > For example, a "Developer" business role might give default access to > (or > require) the "Developer Version Control" IT role and permit access to > (but not require) the "Developer Data Modeling" IT role. > > Also, if a role is nothing more than a set of entitlements, how is > this different from a group? Security groups are generally granted > some set of entitlements and then users are added as group members to > be granted those entitlements. > > All of this to say that while roles are often a set of entitlements, I > don't think that this is always the case. > > --Kelly > > > -----Original Message----- > From: Michael Hammer [mailto:michael.hammer@yaanatech.com] > Sent: Tuesday, April 17, 2012 1:51 PM > To: Kelly Grizzle; radovan.semancik@evolveum.com; scim@ietf.org > Subject: RE: [scim] SCIM Issues > > Kelly, > > I am not sure I like the definitions you have for role. > Another international spec I looked over recently defines role as a > set of entitlements. > That makes more sense to me. > > Group=set of Users > Role=set of Entitlements > > The name of the role would give one an idea what entitlements to > assign that role. > Powers get inherited down the line: > > Entitlement -> Role -> Group -> User > > Pointers can be set in the opposite direction of the arrows. > And of course, leaving a role or group or both out of the chain is > permitted. > > Mike Sense? > > Mike > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf > Of Kelly Grizzle > Sent: Tuesday, April 17, 2012 2:12 PM > To: Radovan Semancik; scim@ietf.org > Subject: Re: [scim] SCIM Issues > > Radovan, > > Thanks for all of the excellent feedback. You have brought up some > great points! > > >> I have noticed that optional attributes are explicitly marked, but >> the "externalId" is not marked in any way. Maybe this is just an >> unclear > wording? > > This is supposed to be optional. I agree that the spec should be > explicit about this. Regarding externalId-per-consumer, this topic > came up at IIW in October. > One thought was to allow this be multi-valued and have the type > specify some sort of URN for the consumer. The discussion ended there, though. > > >> We have done a lot of IDM deployments in last 10 years and >> requirement to change usernames was there in a vast majority of them. > > I agree. In Active Directory, it seems like samAccountName (which is > mutable) would be modeled as the SCIM userName. I don't see any > problem in dropping the immutability requirement from the spec. > > >> The problem with a very large groups is that the list of returned >> members is huge. This is not efficient to retrieve every time. > > This is issue 43 in the issue tracker. Hopefully this can get fixed > in SCIM 2.0. http://code.google.com/p/scim/issues/detail?id=43 > > >> However, all changes have to be made to the "members" attribute of >> the group, which is a bit confusing. It can also be a critical >> problem for applications that require at least one group to create a >> user. Such applications just cannot be provisioned with SCIM >> currently. Making "groups" (in user) read-write may really help here. > > I believe that when we first bumped into this at IIW in October, we > proposed an extension to the User schema that allows specifying the > default group upon creation. If this is a common case (requiring a > group upon creation), it should be considered in the core spec rather than just as a workaround. > > >> Adding a group membership to a user can be passed together with >> "create user" operation. This "batch" can be used by server to "recompose" >> the operation to a create operation that includes a group membership >> if that is needed. And it does not affect the protocol too much. >> However, this approach is somehow incompatible with REST. > > SCIM has a /Bulk endpoint that can be used for batching, but the spec > says that ordering is not guaranteed. Perhaps this could be used if > the service provider is smart enough, but it could be difficult to > implement efficiently. > > >> I see that the presence of PATCH operation can make this efficient. >> But does SCIM rely on the fact that every protocol will have this >> efficient way of attribute modification? > > PATCH support is not required by the spec, but I would imagine that > any service provider that has large data (eg - a directory server) > would strive to implement it for their own good. I'm not sure how > this would be done in different protocols, though. This needs more > thought for non-REST protocols. > > >> Maybe it is worth to think if there is a way that will still allows >> the "delta logic" as a primary mechanism but will not be that >> confusing and difficult to implement for legacy systems. E.g. >> reflecting group membership to a read-write user attribute can make >> "PUT" feasible as the conflicts on large groups will be avoided and a >> (concurrency) conflict on a single user is unlikely (and hence the > optimistic locking may be efficient). > > A read-write groups attribute on the User has been discussed quite a > bit. I agree that it is much easier to manipulate group membership > via the user than the other way around. As Samuel pointed out, the > groups attribute contains groups that are not only directly assigned, > inherited, or dynamically calculated. As such, it is difficult to > allow modification of this attribute since some groups (eg - dynamic) cannot be removed or added. > Various ideas were considered to allow this (splitting dynamic and > nested groups into a separate attribute, etc...), but they all had > their own complications. Because of this we decided to stick with the > "edit membership via the group" philosophy. > > >> And most importantly: I think there should be a clear and uniform way >> how to deal with assignment of the things that user belongs to. I >> call them "entitlements" but I see that SCIM has a slightly different >> terminology and does not have a common concept that unifies SCIM >> groups, roles and other entitlements. And I think this is the missing >> piece that is one of the causes of this confusion. > > You are right that a group can be considered an entitlement and there > is some confusion here. Concrete examples may help. This is how I > think about the > three: > > - Entitlements: These are individual low-level access grants that are > assigned > directly to a user. An example granting a user the "Write" right on a > resource called DevWiki. This might be modeled as "write:DevWiki" or > something. > > - Roles: These describe what roles or job functions the user holds > within the > organization (eg - Developer, Sales Executive, Student, etc...). In some > systems, having a role might cause a user to be granted individual > entitlements or group memberships. These relationships are not > specified in > SCIM since roles are opaque. > > - Groups: These are groupings of users that may support nesting. In > some cases > they are used for access control (security groups) and in other > cases they > are used for other purposes (eg - distribution groups). Security > groups may > be able to grant entitlements to a user. > > I think that there is merit in keeping these concepts separated. I > can conceive of future extensions to expose /Entitlements and /Roles > endpoints that allow reading and updating an entitlement catalog and role model. > There has been some confusion around these three attributes, so it is > probably worth trying to clean this up in the spec. > > >>> Minor issue: Canonical types for members are capitalizes while other >>> types start with lowercase letter. >> >> Good catch, it might be a legacy from the time when the endpoints >> where called User and Group and not Users and Groups. > > It is probably legacy. There are actually currently some discussions > around this wrt allowing the group members to be dereferenced. "User" and "Group" > match the name in the resource schema > (http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#reso > urce-s > chema) > and it may be worth keeping these to allow dereferencing. > > >> Should not authenticationSchema be outside of the SCIM core schema? >> Schema defines no transport protocol and the authentication types >> clearly depend on transport protocols. Maybe a binding specificiation >> is a better place for authenticationSchema definition? > > This is defined in the ServiceProviderConfig, which regardless of the > transport protocol should be available. You're right that this > assumes the REST protocol. Perhaps authenticationSchemas should have > a sub-attribute that specifies the applicable protocol? > > >> User has userName, displayName and name/formatted. Group has displayName. >> Resource has name as string. It is confusing. It is also quite >> inconsistent and makes if difficult to support uniform representation >> of "objects" in the underlying SCIM implementation. > > Maybe Group could use name instead of displayName? I kind of like > displayName because this might be different from a raw name (eg - > Super Users vs. cn=Super Users,dc=foo,...). This doesn't seem like > much of an issue to me. Looking at the confusion between userName, > displayName, formattedName is worthwhile, though. > > >> Resource Schema has description, but user and groups does not? >> Description may come handy in any object. > > I could see this for groups but haven't ever really seen this for users. > > >> The attributes/type definition in Resource Schema does not specify >> whether the value is URL or QName or plain string. If a plain string >> (which seems to be the case by looking at the examples) how to map >> that string to XSD QNames? Are only XSD data types possible? The >> specification says "SHOULD not" not "MUST NOT", therefore an >> extension mechanism should be specified here. > > Yes these are based on XSD data types and are not currently > extensible. Are there any data types that are not currently covered by the spec? > > >>>> If the type is mandatory for every multi-valued attribute (is > "hardcoded" >>>> in the core schema specification), is there any point to define it >>>> explicitly in all the resource schemas? >>> Could you be more specific around hardcoded? >> >> The "type" attribute is explicitly defined for any multi-valued >> attributes in the specification (section 3.2). Therefore it is a part >> of the meta-schema rather than schema. May there be a multi-valued >> attribute that does not have "type"? If yes then the "type" should be >> marked as optional in the specification. If not then there is no >> point of specifying "type" in every run-time schema because it just >> must always > be there. > > I believe that the type sub-attribute is optional. I believe that > generally in the schema spec if an attribute doesn't say REQUIRED than > it is implied to be optional. This should be made more explicit. > > >>>> Is ordering of multi-value attribute values significant? No, >>>> multivalued >>> attributes are unordered. This has made mapping to e.g. SAML harder. >> >> That is a crucial point that should be documented in the schema. I >> was explicitly looking for that and haven't found it. > > I agree. > > >> Oh. This "encapsulating" of extensions into a specific parts of the >> JSON structure somehow eluded me. Anyway, there is still a problem >> with future schema extensions. E.g. if a future version of SCIM >> defines new user attribute "ext1" it can break valid existing >> "documents" and therefore is a risk for compatibility. Maybe it would >> be a good idea to adopt the XML "best practice" of quarantining > extensibility points into dedicated elements? >> E.g. it can look like this in JSON: >> >> { >> "schemas":["urn:scim:schemas:core:1.0", ext1, ext2], >> "userName": "kalle", >> "extension": { >> "ext1": { >> employeeNumber: "abc123" >> }, >> "ext2": { >> employeeNumber: "123abc" >> } >> } } > > Extensions are actually defined with URNs (eg - > urn:scim:schemas:extension:enterprise:1.0), > so it is pretty unlikely that there will be conflicts. See an example > in the JSON representation of an enterprise user here: > http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9. > > >> I hope that the authors of SCIM will try to correct the obvious >> problems of the specification and focus on proving that it works >> before going any further. The only reasonable way to go is: working >> software first, standards second. > > Implementations have been developed in parallel with the spec, and > there were 9 of them that worked (at least to some extent) together > just a few weeks ago > (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors > (myself > included) have always had an eye toward making something that is > practical, useful, and actually works. As you have found, there are > definitely some holes and warts that need to be addressed. > > I really appreciate your feedback and will make sure that some of > these issues make it into the issue tracker. > > --Kelly > > _______________________________________________ > 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_004D_01CD1D4C.2BF74DC0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx ODE0MTUyNVowIwYJKoZIhvcNAQkEMRYEFGvY6PhRg6GQKVcKntyQ1i7OV7n1MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGApVnnBq2Rxqq/sGW7bAgedeeAk782wx7R88a3WjRcd4Ls RCosGZHKNkSdDrm9CMXK6SMkjrVtRzHBldONICrBOg61Gn1sBtXH+yTyGmMiNrk8xizGIcpn6tto TyQak7TEruZp28/1gCBJhYj28lTwAT/MOEC+JvRaAdP8c4CUx38AAAAAAAA= ------=_NextPart_000_004D_01CD1D4C.2BF74DC0-- From michael.hammer@yaanatech.com Wed Apr 18 07:37: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 EFC0021F85CC for ; Wed, 18 Apr 2012 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 OLTh8y12z6IF for ; Wed, 18 Apr 2012 07:36: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 50CE821F85CF for ; Wed, 18 Apr 2012 07:36: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; Wed, 18 Apr 2012 07:36:56 -0700 From: Michael Hammer To: "radovan.semancik@evolveum.com" Thread-Topic: [scim] SCIM Issues Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQACAANSxgP//2QRg Date: Wed, 18 Apr 2012 14:36:55 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0BED@EX2K10MB1.corp.yaanatech.com> References: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A00FF@EX2K10MB1.corp.yaanatech.com> <56C3C758F9D6534CA3778EAA1E0C34371C683A31@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F8E8CF3.50407@evolveum.com> In-Reply-To: <4F8E8CF3.50407@evolveum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01CD1D4F.2C09BCF0" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.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, 18 Apr 2012 14:37:01 -0000 ------=_NextPart_000_0052_01CD1D4F.2C09BCF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Radovan, Probably. I think you can simplify it, but need to keep a distinction between the subject and the adjectives here. So, you could lump the roles/entitlements (privileges to be assigned) in one bin, leaving the atomic/aggregate question aside. And the User/Group (what privileges are assigned to) in another bin, also leaving that atomic/aggregate question aside. Pick the key terms (e.g. User and Role) to label the bins, and let the explanation hand-wave over the complications. :) Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Radovan Semancik Sent: Wednesday, April 18, 2012 5:44 AM Cc: scim@ietf.org Subject: Re: [scim] SCIM Issues I have few remarks to the "roles" discussion: If a role is a collection of entitlements, what about hierarchical roles (roles that container roles)? Do we need to broaden the definition to "collection of entitlements and roles"? Or do we just assume that a role is an entitlement? But there is a more important question: are we going into too much detail here? A target system ("resource" in IDM speak) may work with really rich and complex roles represented by intricate structure of the subject-action-object triples, sub-roles of various types, bound to the organizational structure and all that spiced up with temporal constraints and other decorations. But the IDM systems usually know nothing about this. They don't need to. They only see such role as yet another entitlement and assign it to the user (and actually most IDM systems just see it as yet another (string) value of some account attribute). The roles in the IDM system are much higher abstraction than the roles in the resource. These are actually quite a different kinds of animal. What I see here is a attempt to encompass both concepts into a single framework/definition. I don't think that is feasible right now. Is the scope of SCIM management of roles/groups/whateverEntitilementThereMayBe? Or is the scope only assigning such things to users? If it is the latter case than maybe we do not need to see the difference between group, role, entitlement, organizational unit, team, project, privilege, etc. Just define a class of "assignable" entities and provide a way how to assign them to users. That should be enough. -- Radovan Semancik Software Architect evolveum.com On 04/17/2012 11:03 PM, Kelly Grizzle wrote: > This makes sense to me. However, I have seen roles be used for more than this. A common example is using roles to define separation of duty policies, such as disallowing a person from being a "Vendor Creator" and "Payment Approver". Often these role have entitlements under them, but not always. > > I have also seen roles be split into different types - business roles and IT roles. A business role is simply something that describes who a person is within their organization. This can be assigned directly to the user or can be dynamically assigned by some sort of a matching rule (eg - "if your title is 'Sales Level III' you get 'Sales Engineer' role). An IT role is more like what you are describing, a group of entitlements. These different types of roles can be related to each other through various relationships. For example, a "Developer" business role might give default access to (or require) the "Developer Version Control" IT role and permit access to (but not require) the "Developer Data Modeling" IT role. > > Also, if a role is nothing more than a set of entitlements, how is this different from a group? Security groups are generally granted some set of entitlements and then users are added as group members to be granted those entitlements. > > All of this to say that while roles are often a set of entitlements, I don't think that this is always the case. > > --Kelly _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0052_01CD1D4F.2C09BCF0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx ODE0MzY1NFowIwYJKoZIhvcNAQkEMRYEFARFXCY+SWDXJJGA4BIqGStIE3AtMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAGTCU07jgrJDeA9QDpBqRy94cfI1KHyHbA+zuAgqsPxRz 0v28QDsWw5HwJGxEepplBJ4vE+IhcngzngZjdR9ROsmkvpq5vJE3apqibt2axhuqD0PHeMBqpkXH Ec6npZy69es/B5beVOWGGPXerhLiw275X/z0qucwHjNV8/sjrwMAAAAAAAA= ------=_NextPart_000_0052_01CD1D4F.2C09BCF0-- From igor.faynberg@alcatel-lucent.com Wed Apr 18 09:29: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 91CA321F8575 for ; Wed, 18 Apr 2012 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 Gou1uBmhxjY5 for ; Wed, 18 Apr 2012 09:29:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 245EC21F859B for ; Wed, 18 Apr 2012 09:29:15 -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 q3IGTEN2012494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 11:29:14 -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 q3IGTDx4015156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Apr 2012 11:29:14 -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 q3IGTDAH002390; Wed, 18 Apr 2012 11:29:13 -0500 (CDT) Message-ID: <4F8EEBD9.1010208@alcatel-lucent.com> Date: Wed, 18 Apr 2012 12:29:13 -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: <4F8C19E8.2010309@evolveum.com> <4F8D8512.7030404@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34371C68392C@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F8E8655.3050706@evolveum.com> <505C62A4-9BC3-4A06-9B66-CDEA5B955D55@unboundid.com> In-Reply-To: <505C62A4-9BC3-4A06-9B66-CDEA5B955D55@unboundid.com> Content-Type: multipart/alternative; boundary="------------000904010005060809070708" 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] SCIM Issues X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:29:31 -0000 This is a multi-part message in MIME format. --------------000904010005060809070708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And this is also how many successful technologies that were eventually standardised by the IETF had been developed! In fact, the real sign of a good technology is that people embrace it and contribute toward developing it without waiting for Godot (or for any formal SDO action). To this end, running code is the best possible proof of technology, and it is also the kernel around which consensus is building. Yet I do hope that soon we will have a group, and the structure Trey mentions will be in place. Still, even then I expect people to keep implementing from Internet Drafts (this happened with SIP, MPLS, and OAuth, just to give a few examples. Igor On 4/18/2012 6:04 AM, Trey Drake wrote: > Radovan, > > I'm not sure what you're looking for - SCIM, in its current form, has been presented to the IETF as a standards track specification. The intent of doing so is to widen the audience so as to improve the specification, formalize governance, and all the usual goodness SDOs provide. If the SCIM WG is approved the effort has just begun. In the meantime, we're rev'ing the spec, holding interops and gaining operational experience. Yes, IDM vendors and SaaS providers alike are rolling out SCIM implementations as SCIM is addressing a pain point today. Like it or not this is common practice. I don't see this as a negative, rather its a positive - implementors are at least attempting to build off a spec that has a chance of interop vs rolling their own. > > Thanks, > Trey > > On Apr 18, 2012, at 11:16 AM, Radovan Semancik wrote: > >> Hi, >> >>>> I hope that the authors of SCIM will try to correct the obvious problems of >>>> the specification and focus on proving that it works before going any >>>> further. The only reasonable way to go is: working software first, standards >>>> second. >>> Implementations have been developed in parallel with the spec, and there were 9 >>> of them that worked (at least to some extent) together just a few weeks ago >>> (http://code.google.com/p/scim/wiki/FirstInteropEvent). The authors (myself >>> included) have always had an eye toward making something that is practical, >>> useful, and actually works. As you have found, there are definitely some holes >>> and warts that need to be addressed. >> The problem is that some holes cannot be uncovered by just looking at the spec. I have tried my best but I'm quite sure that I have missed some. Interop event is also not a definitive answer. I really appreciate that such events happen, but these are still more-or-less laboratory environment. And interoperability is not the only issue here. Interop events cannot tell if the protocol is sufficiently complete to be practical. If the protocol is not complete, implementers will create their own extensions to cover the missing parts. And such extensions are very likely to be incompatible. This is what happened to X.509 and also to HTML in the early days. >> >> I guess that SCIM is now validated considerably better than SPML. But that is till not enough. The protocol should be tried in several real deployments before it is standardized. Reality always has a bunch of unexpected surprises for engineers. >> >> -- >> >> Radovan Semancik >> Software Architect >> evolveum.com >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------000904010005060809070708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And this is also how many successful technologies that were eventually standardised by the IETF had been developed!  In fact, the real sign of a good technology is that people embrace it and contribute toward developing it without waiting for Godot (or for any formal SDO action). 

To this end, running code is the best possible proof of technology, and it is also the kernel around which consensus is building.

Yet I do hope that soon we will have a group, and the structure Trey mentions will be in place.  Still, even then I expect people to keep implementing from Internet Drafts (this happened with SIP, MPLS, and OAuth, just to give a few examples.

Igor

On 4/18/2012 6:04 AM, Trey Drake wrote: 
Radovan,

I'm not sure what you're looking for - SCIM, in its current form, has been presented to the IETF as a standards track specification.  The intent of doing so is to widen the audience so as to improve the specification,  formalize governance, and all the usual goodness  SDOs provide.  If the SCIM WG is approved the effort has just begun.  In the meantime, we're rev'ing the spec, holding interops and gaining operational experience.  Yes, IDM vendors and SaaS providers alike are rolling out SCIM implementations as SCIM is addressing a pain point today.   Like it or not this is common practice.  I don't see this as a negative, rather its a positive - implementors are at least attempting to build off a spec that has a chance of interop vs rolling their own.  

Thanks,
Trey

On Apr 18, 2012, at 11:16 AM, Radovan Semancik wrote:


Hi,


I hope that the authors of SCIM will try to correct the obvious problems of
the specification and focus on proving that it works before going any
further. The only reasonable way to go is: working software first, standards
second.

Implementations have been developed in parallel with the spec, and there were 9
of them that worked (at least to some extent) together just a few weeks ago
(http://code.google.com/p/scim/wiki/FirstInteropEvent).  The authors (myself
included) have always had an eye toward making something that is practical,
useful, and actually works.  As you have found, there are definitely some holes
and warts that need to be addressed.

The problem is that some holes cannot be uncovered by just looking at the spec. I have tried my best but I'm quite sure that I have missed some. Interop event is also not a definitive answer. I really appreciate that such events happen, but these are still more-or-less laboratory environment. And interoperability is not the only issue here. Interop events cannot tell if the protocol is sufficiently complete to be practical. If the protocol is not complete, implementers will create their own extensions to cover the missing parts. And such extensions are very likely to be incompatible. This is what happened to X.509 and also to HTML in the early days.

I guess that SCIM is now validated considerably better than SPML. But that is till not enough. The protocol should be tried in several real deployments before it is standardized. Reality always has a bunch of unexpected surprises for engineers.

-- 

                                          Radovan Semancik
                                         Software Architect
                                            evolveum.com

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


      

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


    

  


--------------000904010005060809070708--

From Chris.Phillips@canarie.ca  Wed Apr 18 11:23: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 C9E9A21F8474 for ; Wed, 18 Apr 2012 11:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 t3rO6tg0+eSV for ; Wed, 18 Apr 2012 11:23:16 -0700 (PDT)
Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id D8EDE21F8476 for ; Wed, 18 Apr 2012 11:23:14 -0700 (PDT)
Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Wed, 18 Apr 2012 14:23:14 -0400
From: Chris Phillips 
To: "scim@ietf.org" 
Date: Wed, 18 Apr 2012 14:23:14 -0400
Thread-Topic: [scim] SCIM Issues
Thread-Index: Ac0dkFEJ7EvUnt4GQySNQlRZcsDSdg==
Message-ID: 
In-Reply-To: <4F8E8CF3.50407@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 18 Apr 2012 18:23:16 -0000

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and
access management model and is a reliable and consistent transport for
information about a persona and related control infrastructure elements
for CRUD/batch activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona
information with care toward maintaining untainted/untransformed
attributes to minimize data massaging at the end points.


To this end, there are no conditions to use a certain privilege or access
management model to use SCIM. The most popular models (group based, RBAC,
x.509, and entitlement based) are capable of being contained in SCIM 1.0
schema and are free to co-habitate, even conflict or duplicate each other
in various ways, or be absent. The strength of being able to contain most
any model outweighs enforcing certain behaviours which would sideline
people or services who don't subscribe to the philosophy, whatever it may
be. =20

This Lego like building block approach keeps SCIM 'simple' but not
simplistic.

I think the more rigidity that is folded into SCIM needs to be done with
care and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around
unique id management or  other key areas of identity provisioning and how
it lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect
the spirit in which SCIM has evolved so far.  I am interested in the IETF
community's thoughts around governance strategies that would be available
in this area and how it would be shepherded forward in the IETF as a
starter topic.=20


Chris.



On 12-04-18 5:44 AM, "Radovan Semancik" 
wrote:

>Is the scope of SCIM management of
>roles/groups/whateverEntitilementThereMayBe? Or is the scope only
>assigning such things to users? If it is the latter case than maybe we
>do not need to see the difference between group, role, entitlement,
>organizational unit, team, project, privilege, etc. Just define a class
>of "assignable" entities and provide a way how to assign them to users.
>That should be enough.


From kelly.grizzle@sailpoint.com  Wed Apr 18 14:15: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 CB82311E8097 for ; Wed, 18 Apr 2012 14:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.289
X-Spam-Level: 
X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=1.310,  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 6u6OTzzfUb+b for ; Wed, 18 Apr 2012 14:15:36 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id B674311E8094 for ; Wed, 18 Apr 2012 14:15:36 -0700 (PDT)
Received: from mail63-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 21:15:35 +0000
Received: from mail63-tx2 (localhost [127.0.0.1])	by mail63-tx2-R.bigfish.com (Postfix) with ESMTP id AFA311C050A; Wed, 18 Apr 2012 21:15:35 +0000 (UTC)
X-SpamScore: -32
X-BigFish: PS-32(zz9371I936eK542M98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail63-tx2: 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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; 
Received: from mail63-tx2 (localhost.localdomain [127.0.0.1]) by mail63-tx2 (MessageSwitch) id 1334783734313949_27006; Wed, 18 Apr 2012 21:15:34 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.237])	by mail63-tx2.bigfish.com (Postfix) with ESMTP id 47A7634004A; Wed, 18 Apr 2012 21:15:34 +0000 (UTC)
Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 21:15:31 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.195]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Wed, 18 Apr 2012 21:15:29 +0000
From: Kelly Grizzle 
To: Chris Phillips , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNG9KHRKCGtgTVFU2m9SlJj7fm7paeePcAgACkeQCAADVNoIAAC5KAgAAaUTCAAN9hgIAAkPwAgAAsWiA=
Date: Wed, 18 Apr 2012 21:15:28 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>
References: <4F8E8CF3.50407@evolveum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.226.147.242]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sailpoint.com
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 18 Apr 2012 21:15:40 -0000

I agree with Chris that the agnostic privilege management nature of SCIM is=
 a good thing.  Entitlements, roles, groups, and their relationships with e=
ach other can get complex quickly.  As Radovan pointed out, trying to model=
 exactly what these mean is different than just being able to assign and de=
assign them on a user.  I could eventually see /Roles and /Entitlements end=
points as extensions.  Minimally they could just contain descriptions and a=
llow listing all of the possible values.  On the other end of spectrum, the=
y could have a full model that describes in detail what they mean and how t=
hey relate to each other.  I don't think we should go there without a lot o=
f thought.

Having had this discussion, it seems like we should review the language in =
the schema spec to make sure that the descriptions of these attributes make=
 sense or if we should tighten them up a bit.  Radovan's initial comment th=
at "group membership is also an entitlement" is valid, and should probably =
be clarified in the spec.  Phil also makes a good point that "flexibility l=
eads to interpretation, mapping, and interop issues".  The descriptions of =
these attributes should be clear enough in the spec that service providers =
and clients have a clear understanding of how these concepts map into their=
 worlds.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chr=
is Phillips
Sent: Wednesday, April 18, 2012 1:23 PM
To: scim@ietf.org
Subject: Re: [scim] SCIM Issues

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and acces=
s management model and is a reliable and consistent transport for informati=
on about a persona and related control infrastructure elements for CRUD/bat=
ch activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona infor=
mation with care toward maintaining untainted/untransformed attributes to m=
inimize data massaging at the end points.


To this end, there are no conditions to use a certain privilege or access m=
anagement model to use SCIM. The most popular models (group based, RBAC, x.=
509, and entitlement based) are capable of being contained in SCIM 1.0 sche=
ma and are free to co-habitate, even conflict or duplicate each other in va=
rious ways, or be absent. The strength of being able to contain most any mo=
del outweighs enforcing certain behaviours which would sideline people or s=
ervices who don't subscribe to the philosophy, whatever it may be. =20

This Lego like building block approach keeps SCIM 'simple' but not simplist=
ic.

I think the more rigidity that is folded into SCIM needs to be done with ca=
re and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around =
unique id management or  other key areas of identity provisioning and how i=
t lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect =
the spirit in which SCIM has evolved so far.  I am interested in the IETF c=
ommunity's thoughts around governance strategies that would be available in=
 this area and how it would be shepherded forward in the IETF as a starter =
topic.=20


Chris.



On 12-04-18 5:44 AM, "Radovan Semancik" 
wrote:

>Is the scope of SCIM management of
>roles/groups/whateverEntitilementThereMayBe? Or is the scope only=20
>assigning such things to users? If it is the latter case than maybe we=20
>do not need to see the difference between group, role, entitlement,=20
>organizational unit, team, project, privilege, etc. Just define a class=20
>of "assignable" entities and provide a way how to assign them to users.
>That should be enough.

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



From michael.hammer@yaanatech.com  Wed Apr 18 17:05: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 F388211E8097 for ; Wed, 18 Apr 2012 17:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.681
X-Spam-Level: 
X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 9wagwR6lC5eb for ; Wed, 18 Apr 2012 17:05:17 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6011E809F for ; Wed, 18 Apr 2012 17:05:17 -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; Wed, 18 Apr 2012 17:05:17 -0700
From: Michael Hammer 
To: "kelly.grizzle@sailpoint.com" , "Chris.Phillips@canarie.ca" , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQACAANSxgIAAkPwAgAAwHwD//7g6cA==
Date: Thu, 19 Apr 2012 00:05:17 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.17.88.24]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01CD1D9E.92067F30"
MIME-Version: 1.0
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 19 Apr 2012 00:05:22 -0000

------=_NextPart_000_0004_01CD1D9E.92067F30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hmmm....

A corporation is a group.  Can you assign entitlements to that?
A user is a group with membership of one.
For example rights to vote in SDOs, independent of what individual?
Put another way, can an entitlement be an attribute to another entitlement,
with zero subjects to attach it to?
Seems like all adjectives and no nouns here.
That is my last comment.
Enjoy.  :)

Mike

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Kelly Grizzle
Sent: Wednesday, April 18, 2012 5:15 PM
To: Chris Phillips; scim@ietf.org
Subject: Re: [scim] SCIM Issues

I agree with Chris that the agnostic privilege management nature of SCIM is
a good thing.  Entitlements, roles, groups, and their relationships with
each other can get complex quickly.  As Radovan pointed out, trying to model
exactly what these mean is different than just being able to assign and
deassign them on a user.  I could eventually see /Roles and /Entitlements
endpoints as extensions.  Minimally they could just contain descriptions and
allow listing all of the possible values.  On the other end of spectrum,
they could have a full model that describes in detail what they mean and how
they relate to each other.  I don't think we should go there without a lot
of thought.

Having had this discussion, it seems like we should review the language in
the schema spec to make sure that the descriptions of these attributes make
sense or if we should tighten them up a bit.  Radovan's initial comment that
"group membership is also an entitlement" is valid, and should probably be
clarified in the spec.  Phil also makes a good point that "flexibility leads
to interpretation, mapping, and interop issues".  The descriptions of these
attributes should be clear enough in the spec that service providers and
clients have a clear understanding of how these concepts map into their
worlds.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Chris Phillips
Sent: Wednesday, April 18, 2012 1:23 PM
To: scim@ietf.org
Subject: Re: [scim] SCIM Issues

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and access
management model and is a reliable and consistent transport for information
about a persona and related control infrastructure elements for CRUD/batch
activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona
information with care toward maintaining untainted/untransformed attributes
to minimize data massaging at the end points.


To this end, there are no conditions to use a certain privilege or access
management model to use SCIM. The most popular models (group based, RBAC,
x.509, and entitlement based) are capable of being contained in SCIM 1.0
schema and are free to co-habitate, even conflict or duplicate each other in
various ways, or be absent. The strength of being able to contain most any
model outweighs enforcing certain behaviours which would sideline people or
services who don't subscribe to the philosophy, whatever it may be.  

This Lego like building block approach keeps SCIM 'simple' but not
simplistic.

I think the more rigidity that is folded into SCIM needs to be done with
care and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around
unique id management or  other key areas of identity provisioning and how it
lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect
the spirit in which SCIM has evolved so far.  I am interested in the IETF
community's thoughts around governance strategies that would be available in
this area and how it would be shepherded forward in the IETF as a starter
topic. 


Chris.



On 12-04-18 5:44 AM, "Radovan Semancik" 
wrote:

>Is the scope of SCIM management of
>roles/groups/whateverEntitilementThereMayBe? Or is the scope only 
>assigning such things to users? If it is the latter case than maybe we 
>do not need to see the difference between group, role, entitlement, 
>organizational unit, team, project, privilege, etc. Just define a class 
>of "assignable" entities and provide a way how to assign them to users.
>That should be enough.

_______________________________________________
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_0004_01CD1D9E.92067F30
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
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx
OTAwMDUxNVowIwYJKoZIhvcNAQkEMRYEFOiEhdWYXces4nrgcV0Ma8cdgQjrMIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGADNp94GWnJc9ZrFQY/dZPI55N45h0UFhr7pZPvEW/AYtG
P3Lb20xMWORFw7f9MtPK9M66BcKO6GHHYqwKS0wKOTuhgEz77YlRGC6UeVFeqK+Qr8Z5Ni/ZTur+
TJxe4sUqV05U9zD5eB0fTxXcFH8Y1gGx4autQEu/8wELiRsCuOIAAAAAAAA=

------=_NextPart_000_0004_01CD1D9E.92067F30--

From melinda.shore@gmail.com  Wed Apr 18 21:28: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 5609C11E80B0 for ; Wed, 18 Apr 2012 21:28: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=[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 H53dzSqvJTq7 for ; Wed, 18 Apr 2012 21:28:04 -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 9F2B211E8089 for ; Wed, 18 Apr 2012 21:28:04 -0700 (PDT)
Received: by pbbrp16 with SMTP id rp16so7693028pbb.31 for ; Wed, 18 Apr 2012 21:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=C/wPJjll4etDidFo/H0s3K56RPYda0ruBnMD7twglIk=; b=FSuPNZ3KSm5HLUdoV5m83SQix7fiqHMb12yKvW1hix1SHTpJge6FBqWxxAMO67EMDB /DeUAwqmD8rDCpRLuJNJnPggQfrlqEOiJfOjFll3nmDkinlQJU28uLdO20VSp3M+uhGt vqESAvF6RP985HoOCB97cnx/q0vTktxchUJNLq+wjGqUukuLL3KJzlrNXXG/kGiQfNQP yhzHYWzwAgpkxl09C2GXYleVbMBRfhAXxmD5xWGCJ+kEuMGFSPhsbOwWzV4vNsxBUjKt YbAvsPDvamXWaEh+GthEwrrqsUOxuuj8xSOZykJy5j1qcm7TCOyyt2OJy8f4TEoniDgh IBeA==
Received: by 10.68.194.1 with SMTP id hs1mr1964785pbc.6.1334809684463; Wed, 18 Apr 2012 21:28:04 -0700 (PDT)
Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id i8sm1091496pbi.47.2012.04.18.21.28.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 21:28:03 -0700 (PDT)
Message-ID: <4F8F9451.4030703@gmail.com>
Date: Wed, 18 Apr 2012 20:28:01 -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: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 19 Apr 2012 04:28:05 -0000

On 4/18/12 4:05 PM, Michael Hammer wrote:
> Seems like all adjectives and no nouns here.

I see your point but I don't think it's necessary for it
to be the case.  Corporations and individuals are both entities.

Melinda

From michael.hammer@yaanatech.com  Thu Apr 19 06:13: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 5DDCF21F8573 for ; Thu, 19 Apr 2012 06:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Level: 
X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 q1nKD5WhkNDN for ; Thu, 19 Apr 2012 06:13:13 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7F21F85C3 for ; Thu, 19 Apr 2012 06:13:13 -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; Thu, 19 Apr 2012 06:13:12 -0700
From: Michael Hammer 
To: "melinda.shore@gmail.com" , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQACAANSxgIAAkPwAgAAwHwD//7g6cIAAwKCAgAAdO0A=
Date: Thu, 19 Apr 2012 13:13:11 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com>
In-Reply-To: <4F8F9451.4030703@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.25]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01CD1E0C.A21FDB50"
MIME-Version: 1.0
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 19 Apr 2012 13:13:17 -0000

------=_NextPart_000_0004_01CD1E0C.A21FDB50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In any case, let us move on and see how it goes.

Mike


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Melinda Shore
Sent: Thursday, April 19, 2012 12:28 AM
To: scim@ietf.org
Subject: Re: [scim] SCIM Issues

On 4/18/12 4:05 PM, Michael Hammer wrote:
> Seems like all adjectives and no nouns here.

I see your point but I don't think it's necessary for it to be the case.
Corporations and individuals are both entities.

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

------=_NextPart_000_0004_01CD1E0C.A21FDB50
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
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx
OTEzMTMwN1owIwYJKoZIhvcNAQkEMRYEFE+mpYcCtthNfUHYBOD8zBXbaJu3MIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAkkuIJHmTmqTo/lEgZ7Pbf/R99WFNQnw9jYB4NW+8PuLM
ROkZhLlAR3QOu1+J9tXETu1ro5tN2eX4I42jhMy/Bn1cX9Nh6Ps7yOU3QCHzFyTlLgiMbxi/ED7C
hptEqr51tme3ISgojpj3efMe35igneiyPyHRtGQaz4rmXujecxEAAAAAAAA=

------=_NextPart_000_0004_01CD1E0C.A21FDB50--

From barryleiba.mailing.lists@gmail.com  Fri Apr 20 12:58: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 15BAC21F8638 for ; Fri, 20 Apr 2012 12:58:20 -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 8uSz9vwVO5jB for ; Fri, 20 Apr 2012 12:58:19 -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 27BC021F8637 for ; Fri, 20 Apr 2012 12:58:19 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so6244779ghb.31 for ; Fri, 20 Apr 2012 12:58:18 -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=OlaIqAtlwP5TII2QQlrrBsuUkChUmOOaJwYBelEE0i4=; b=HMAen1FIVO9R+EEW9f+4d1eznUAXe/8HsN9wDJIgkPXYQShu25M7AQ99gL75ivqyqR 8wtBGN1F2NDsmhDpx7Wd8BrQJ8C3hif0dC703ge7qOdCIaj115bQy3lgLmB47Ahx6P+J 8lcxQAWXW4w4a20MBkRrHN/O5B0wIVwaklCtw5r+5lhg8HPbEGqGLSKBHlfWysrgrna2 8XkKIlZMI2m925mLC6ih0g3PDSiRUxRWYsQbnsEhlooykaUW+/V9OZGYx4MLXIARINLD w6d5zqsc5pknKYexdj9cV8+PJHAF+eRXBXz4L5t964TxJCvRvqsxnKv8NbvWVAw2JXGt A3XA==
MIME-Version: 1.0
Received: by 10.236.154.35 with SMTP id g23mr7072185yhk.107.1334951898808; Fri, 20 Apr 2012 12:58:18 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Fri, 20 Apr 2012 12:58:18 -0700 (PDT)
In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com>
References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F86686D.8010609@gmail.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com>
Date: Fri, 20 Apr 2012 15:58:18 -0400
X-Google-Sender-Auth: Xk5fccr8U049kFvLmv-v3nT5iAg
Message-ID: 
From: Barry Leiba 
To: "Morteza Ansari (moransar)" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 20 Apr 2012 19:58:20 -0000

It's been several days without any further discussion of the charter.
There's active conversation about the specs, and that's a nice thing.
Since the charter comments seem to have settled, why don't you post
another version of the charter with the recent comments (since v7)
incorporated?

Barry

From stephen.farrell@cs.tcd.ie  Fri Apr 20 18:55: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 5ACCA11E8080 for ; Fri, 20 Apr 2012 18:55:02 -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 ka4tR+6NNdR4 for ; Fri, 20 Apr 2012 18:54:55 -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 DEB7B11E8073 for ; Fri, 20 Apr 2012 18:54:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8FEFD17147C; Sat, 21 Apr 2012 02:54:52 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:in-reply-to:references:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1334973288; bh=p1hsGvT6FFznZLuia2WYAGAI y2F1UEBJGqpTwvMwKnk=; b=kAVCtaGLh5V3uTG5B/e3JTQ4h4wXQxZcH1EZ8qb9 glphtZ/+2npcoDAzDeGMnKsWj9bQLcZOmpfnBqoenWF/aanuGzgPuJ50jdhx/ZO3 JoBtmTV9Ra7r0xpWpMLkySr4LMk98yNy9ytWVsRcmw5/ParX+DiVT3DIp0hLBVeq 2nXW+Wktz6mlWPS5hUQSB+BmkClGKYHjdFrtHHSPNGX6QwEEyDVJpYr+IFXrQTOi 7i8TS8/BPhEvsOGEMjB0PhCkKEh/vkgiuQkBjXuhdLKQ1ngHgcd03gjThHkxHhCn 7x3wyMwJNpN7F9ywutCXIjIqvhGvx+zZ/2DtEer3U9zigA==
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 uNn1lMnxyglZ; Sat, 21 Apr 2012 02:54:48 +0100 (IST)
Received: from [1.202.85.154] (unknown [1.202.85.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4259A171474; Sat, 21 Apr 2012 02:54:42 +0100 (IST)
Message-ID: <4F92134E.4050009@cs.tcd.ie>
Date: Sat, 21 Apr 2012 02:54:22 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com> <4F86686D.8010609@gmail.com> <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 1.4
Content-Type: multipart/mixed; boundary="------------070801010604090903000807"
Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" 
Subject: Re: [scim] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 21 Apr 2012 01:55:02 -0000

This is a multi-part message in MIME format.
--------------070801010604090903000807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


I'm not sure if my question (attached) is charter related
or not, but it might be, depending on the answer. I've not
seen an answer so far.

Ta,
S

On 04/20/2012 08:58 PM, Barry Leiba wrote:
> It's been several days without any further discussion of the charter.
> There's active conversation about the specs, and that's a nice thing.
> Since the charter comments seem to have settled, why don't you post
> another version of the charter with the recent comments (since v7)
> incorporated?
> 
> Barry
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
> 

--------------070801010604090903000807
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message"

X-Mozilla-Keys: 
Return-Path: 
X-Original-To: stephen.farrell@cs.tcd.ie
Delivered-To: stephen.farrell@cs.tcd.ie
Received: from localhost (localhost [127.0.0.1])
	by hermes.scss.tcd.ie (Postfix) with ESMTP id 4D95E171477
	for ; Tue, 17 Apr 2012 19:35:21 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level: 
X-Spam-Status: No, score=-4.999 required=5 tests=[AWL=0.600, BAYES_00=-2.599,
	DKIM_VALID=1, DKIM_VERIFIED=-0.1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Authentication-Results: scss.tcd.ie (amavisd-new); dkim=pass
	header.i=@ietf.org
Authentication-Results: scss.tcd.ie (amavisd-new); dkim=softfail (fail,
	message has been altered) header.i=@cs.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1])
	by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id ZczhcbkExrzW for ;
	Tue, 17 Apr 2012 19:35:17 +0100 (IST)
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e])
	by smtp.scss.tcd.ie (Postfix) with ESMTP id BA0C2171476
	for ; Tue, 17 Apr 2012 19:35:16 +0100 (IST)
Received: from ietfa.amsl.com (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id CFBD521F854D;
	Tue, 17 Apr 2012 11:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1334687715; bh=X9n247E1/uewWzf6HCidPOhNQPo6L2j1sEgVEmkjgdQ=;
	h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender;
	b=RaQcKObFErNjHJE6R0/xtm/a/4z3Fwj3GovFOCM2m9MYpaNTovszEIYZ9ZurSFqrr
	 avtQxU0GmkCekt5fW/ypAmyQjZlzxttGe8+i3xKANc+t8bczWLuIZe5sLToxHmoAyp
	 I+isH8K2xgQzBvgtsj8s1KgJOA9rk/DOQfwlBvO4=
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id A0B1221F84F8
	for ; Tue, 17 Apr 2012 11:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 MKGrpd-lA+s7 for ;
	Tue, 17 Apr 2012 11:35:09 -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 1418621F84EE
	for ; Tue, 17 Apr 2012 11:35:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by hermes.scss.tcd.ie (Postfix) with ESMTP id DD426171476;
	Tue, 17 Apr 2012 19:35:07 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=
	content-transfer-encoding:content-type:in-reply-to:references
	:subject:mime-version:user-agent:from:date:message-id:received
	:received:x-virus-scanned; s=cs; t=1334687707; bh=M45ffDGasChe9m
	qt7N0IWHv+UnZzPLKjBr1tqLjvPLY=; b=z36XmTcBh5RTfkEh71mf/KD+u6XjEz
	T4jUIWvAnZsmYDxvi4XobqwJnnHTpC4UKEtbTTNiUTQ1PsRcdYLqxOceTVSh9HwU
	ZlA4fPfuGowAhxCjjA/vu605MXnPKDkq8naipDAjGSnOCSm94QwowPAazsh4DDtx
	N1NVN2IOoyN9im1utCbC7BZJnF5Yr2RDND7KnpuokYgnMZgFeIxfOPBkTQCMHV+I
	V2aZ84cSreo4dedzpWCh1zqW/0fOqplt3Sm34ped/Wg8G/4ffKJgve3u+d7gPORQ
	nESm0kNI0/2y51cpqCBJOnKy6NL1zTeW1mTeoiD/piTX/uzUr8GaKwrg==
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 qs3s8Bp0CuyF; Tue, 17 Apr 2012 19:35:07 +0100 (IST)
Received: from [10.87.48.3] (unknown [86.46.16.190])
	by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 26E1F171473;
	Tue, 17 Apr 2012 19:35:06 +0100 (IST)
Message-ID: <4F8DB7D0.5040706@cs.tcd.ie>
Date: Tue, 17 Apr 2012 19:34:56 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Samuel Erdtman 
References: <4F8C19E8.2010309@evolveum.com>
	
In-Reply-To: 
X-Enigmail-Version: 1.4
Cc: Radovan Semancik , scim@ietf.org
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: scim-bounces@ietf.org
Errors-To: scim-bounces@ietf.org


Just a question on one snippet:

On 04/17/2012 06:09 AM, Samuel Erdtman wrote:
>> >
>> > The familyName and givenName attributes have culture-neutral names. This is
>> > a nice take from FOAF. But the middleName is not that good. It enforces
>> > "american" point of view to the schema. Maybe "additionalName" would be more
>> > appropriate.
> I do not thing that middleName/additionalName is a big deal but good
> point. to be fully compliant with the global view might we also the
> need to make it multiValued for situations where more then one is
> common?

Does this mean that scim intend to re-develop the equivalent of
inetOrgPerson?

That seems like an odd idea. Why is it necessary?

Note - I'm not saying "use ldif" here, but wondering why this
putative WG would need to go re-do all that data modelling work,
as would be implied by the quoted text above.

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


--------------070801010604090903000807--

From samuel@erdtman.se  Tue Apr 24 03:37: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 732F421F865E for ; Tue, 24 Apr 2012 03:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 ZKCExCv30Vek for ; Tue, 24 Apr 2012 03:37:16 -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 EB08421F869E for ; Tue, 24 Apr 2012 03:37:13 -0700 (PDT)
Received: by lagj5 with SMTP id j5so409295lag.31 for ; Tue, 24 Apr 2012 03:37:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=o0KUKW5bYzqzQcA+p9XPtjnhFhyZiA4BZnjxdXXgsKU=; b=h3lj34hMpOluKzx1huiYgQohw9spo27vvsILf+vmdn5zVnec+F38wSEBD7jTjdiZek hBfP7kw1zAQc0nFDVmZFqNai2kG5phhCoIcW3UReX+Zub5LwpeckL7wmDkIFjlR0Zi4d QrzhCKG4Q5k5mH7a8JelTYymtOs1G+jE+sZPIc70FwectPwEpn4FHfr7lzEeNYkJQ4LQ 5ltj3Pul72+lwu4zS+aGuKzjZrFTqrpZKv20C8B5lFQFLSoe6g+2RVEnOwj5gbkMBooU 40IOTLFrZuA/8DPm/IFunrL/MP/HYxE6radzPuKFL2pWC3nqJJ6g34Rdg49CEHRbB5ky xhwA==
MIME-Version: 1.0
Received: by 10.152.145.1 with SMTP id sq1mr18792419lab.22.1335263832494; Tue, 24 Apr 2012 03:37:12 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:37:12 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:37:12 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQl9twhaHAjj864Xm472Aq9Ie0xASE09d/WrGNtjNbZwoyBRtOFstT4WLLbyLGhS9iZqCslY
Subject: [scim] Addressing SCIM issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:37:17 -0000

The long and much appreciated email from Radovan contained lots of
good stuff (http://www.ietf.org/mail-archive/web/scim/current/msg00235.html).
Some things to consider for SCIM 2.0 and some thins that needs to be
clarify in SCIM 1.0 specification.
I have read through the conversation in an attempt to find concrete
action that should be easy to consider. To make each issue easy to
address I will send them in several separate emails so that none is
forgotten.

I send these emails on the IETF mailing list since the issues where
brought up here, even thug the SCIM 1.0 issues might be better suited
on the old list. I am sorry for any inconvenience.

Cheers
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:38:10 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BED21F869E for ; Tue, 24 Apr 2012 03:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 uJseqnT9f1NA for ; Tue, 24 Apr 2012 03:38:10 -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 87EAF21F8663 for ; Tue, 24 Apr 2012 03:38:09 -0700 (PDT)
Received: by lagj5 with SMTP id j5so409837lag.31 for ; Tue, 24 Apr 2012 03:38:08 -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 :content-type:content-transfer-encoding:x-gm-message-state; bh=ulRz/vIOOs4Z4bMXD2FptVLC6QID05NfQR9lXvyD3dw=; b=BvqZ7zGxlsYpzw+2SaHBzkqdOVI+VaQf63I9OeLFm+ubZ1ilS7M/rLMK3Z6wY4fszs hDrgsPBeCcazVYrUI4p/BblO/QuPdCd0bgWJYjzZwo5TPsrIbXJJd/Aveh65dgoUFIWW TP5tWCeg7hmVZKTT3BYVh5pSnyVN5txqnzZP5L4Qx5k7SHmJ8TwNosu5Qc7v8YWTJK/k iRgnFHoco8+s2ka7lRbNYD+5Qxu/go9WCwUsNwpxP489nLhvgZLRTD5xoZG9djnyUS+k qYtvLI9cW0Nmzi9i8+JIymNRSEYOpo5FR/wXR48vtZWHZFebza4JheOZINLwZQBl+51g Oq+Q==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18627436lab.8.1335263888465; Tue, 24 Apr 2012 03:38:08 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:38:08 -0700 (PDT)
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com> <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>
Date: Tue, 24 Apr 2012 12:38:08 +0200
Message-ID: 
From: Samuel Erdtman 
To: "scim@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmWXmY1y6GXYpo5J0Jt/Czo/ejJ/qh1M3E2Jvw2kIFGXhDxfje8E6aRuwUuczMnfPU6SLaF
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:38:10 -0000

When reading through this conversation one more time I see that the
following things has not yet been addressed. If I missed something
that has not been addressed please complement.


> Resource schema has name attribute that obviously points to the object ty=
pe. But it seems to be plain string. Namespace is not obvious here. If any =
SCIM extension adds a new object types (which seems likely) this may be ver=
y confusing. URL may be a better choice here

Could you give some more details and may be an example?

> The multiValuedAttributeChildName attribute and associated way how to rep=
resent data in XML seems to add to the redundancy of the data format. Stric=
tly speaking, this one is also quite specific to XML and should not be in t=
he generic core schema.

I might not be perfect but it works, and I cannot se what other
document to put it into? any suggestions?

> When defining an attribute in a resource schema, how is attribute schema =
used? Is it a namespace that applies to attribute type? Or to the attribute=
 name? Attribute has schema and sub-attribute does not? Why? Does it inheri=
t it from parent? The specification should make that clear.

Could you give some more details and may be an example?

> Does this mean that scim intend to re-develop the equivalent of inetOrgPe=
rson?

I=B4m not sure. Some one with more insight into the directory area might
be able to answer this question, e.g. Kelly, Trey or Morteza.


Cheers
//Samuel



On Thu, Apr 19, 2012 at 3:13 PM, Michael Hammer
 wrote:
> In any case, let us move on and see how it goes.
>
> Mike
>
>
> -----Original Message-----
> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
> Melinda Shore
> Sent: Thursday, April 19, 2012 12:28 AM
> To: scim@ietf.org
> Subject: Re: [scim] SCIM Issues
>
> On 4/18/12 4:05 PM, Michael Hammer wrote:
>> Seems like all adjectives and no nouns here.
>
> I see your point but I don't think it's necessary for it to be the case.
> Corporations and individuals are both entities.
>
> 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 samuel@erdtman.se  Tue Apr 24 03:39: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 0222C21F8665 for ; Tue, 24 Apr 2012 03:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.31
X-Spam-Level: 
X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-0.333,  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 eEdh5NAFs4Aq for ; Tue, 24 Apr 2012 03:39:03 -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 AD56A21F8663 for ; Tue, 24 Apr 2012 03:39:02 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so411978lbg.31 for ; Tue, 24 Apr 2012 03:39:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=v4345YObKstq/FdVtQhKK6o73T6KEQHviStcVdOuhDs=; b=oS+yYJldelSEr4dcUEuxHBclWginriSyQqHJC2/pPnhF6qpUClYG2IRw04TEiIaoFe sXXk4SLYOd/3cxp7/KQF34tAciHdIMAXQUd3FgJteFUDYdkU+8K961Z32JUGaUwtpY7C kLwd0N3v74zys1bipuAk2ryI4nGQhRnKtJNxF8/osVxfXvBddVmQb1dCeTKN+0/e2Pf2 6InPd/fNA6mBrdlvJx6L65Dzy2WfDodxsnb9PBaJMXESu0DSeGlrsuFBLGredlw4gZtN y96FycC1xeTG//o9CbRpll9JaA9x1PF61cS75g6HHIZ8lv6AM4qZ1rIx+NBYYwpat78o Uerw==
MIME-Version: 1.0
Received: by 10.152.145.1 with SMTP id sq1mr18797697lab.22.1335263940324; Tue, 24 Apr 2012 03:39:00 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:39:00 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:39:00 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQl04gckNytfJNiyH6Mw+nt5WipGmjdh1ZM6mNV6vGV6dvbpbefog+FWyVYH4I9pqazY8Syj
Subject: [scim] Details on externalId (SCIM 1.0 clarification)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:39:05 -0000

externalId is defined as a common attribute here
http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor2.
It is defined as one of the attributes required for each new
resource-type to implement. However it needs to be clarified that even
if all resource need to have the attribute it is not mandatory to set
it on each resource.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
// Samuel

From samuel@erdtman.se  Tue Apr 24 03:39: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 551FF21F86AD for ; Tue, 24 Apr 2012 03:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level: 
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 WsFcRSIOHWmk for ; Tue, 24 Apr 2012 03:39: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 6B77021F86E0 for ; Tue, 24 Apr 2012 03:39:30 -0700 (PDT)
Received: by lagj5 with SMTP id j5so410614lag.31 for ; Tue, 24 Apr 2012 03:39:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=uDge9n/gFl/S1nbXCY9I0kN2df+w9mM11lCeaRXhEMo=; b=iFcSX6gp3iTryylkBiNvGTsOEL+hKmhd1jbp3zVJlrEqLUIVBa1oVnsSVXoA0LbAxW rWXD7wneaDuCUOYzIgLnq057DaI444Y92zTlLuKBkYlqiKIAz4+bQMNX3gsH0MtbXt5C LvIVih/g8QSDBIqgW1MjYThU7Ag9KMwA4xrZZoxws2dsXGc8C0tpHFLl+KhE3457ecId PLRv64lM74dHgUIPliFIna3trs/jtAaF2KjifL9VDt2qLovCAXD1if9V74nK3IPYBR1+ OK2NN36hVQ5GbJstYiPOPcyaSEPUyk1XXPIsRgQtIPNJOA5rOy7kBx7z/JzuF5gpKRog 3mSw==
MIME-Version: 1.0
Received: by 10.152.127.163 with SMTP id nh3mr18618300lab.15.1335263967005; Tue, 24 Apr 2012 03:39:27 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:39:26 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:39:26 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnAGig1g82zvd0SKKZWVlo1KOIsKMeCtU6yhpLiIF2PFG2tULeIXX+YU3mhAp4RoyX4H9vl
Subject: [scim] Making userName mutable (SCIM 1.0 improvement)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 10:39:31 -0000

Currently userName is defined as an immutable attribute
(http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor3)
but as Radovan points out userName might change overtime and Kelly
points out that if mapping userName to samaccountname this would not
be a problem. And if considering interoperability it would be not
problem to change the language on this making it mutable.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:40:07 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277CE21F86A7 for ; Tue, 24 Apr 2012 03:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.177
X-Spam-Level: 
X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 NQRCp5IUgbMh for ; Tue, 24 Apr 2012 03:40:05 -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 4CEEC21F8665 for ; Tue, 24 Apr 2012 03:40:05 -0700 (PDT)
Received: by lagj5 with SMTP id j5so411025lag.31 for ; Tue, 24 Apr 2012 03:40:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ou0LsnfuVHVSn8NftxMo3IYBxDovkOTJimHBfjY7TsQ=; b=FA1JkfYFHIMLMkUlafoLASekvqaS8ziVHE5MiMt2maDearVTxujbEH/lafTqRa/BZH XJ97J/UJ9EM3gKfXlhkLNLG84xBIsNNhXg5acGgwxdPIfcKzV0lTgvXNWTgMqqWOuTMf 5/WSLQtgYJP50n7AApm/iDVgXdsN2ocrOWwKi9DW1azfAQDwK8BEjRjpvBhNmTSOAnts 5BhMTtduHnDD8l3MtPpy1Endwbmj85/knjCEOJ+EJ15zm8LDIoIM185sP89MvnAtEV2C tOe9xvrf6S3x6kNAt5p165aMvSLdRpW8Y0lfnvBzJ0pAtoOqjInhZdEBEnkc9deIsHDh X1ow==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18633062lab.8.1335264004303; Tue, 24 Apr 2012 03:40:04 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:40:04 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:40:04 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmlWrUX03PzOrZ/FYKf3tmt0nr6n3NsMCpbOO2bMBcdwMEv/0yLySmKM7CXrk8a9MHThCGN
Subject: [scim] phoneNumbers format (SCIM 1.0 improvement)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 10:40:07 -0000

To improve interoperability Radovan suggest that phoneNumbers should
have a common format. One suggestion would be E.164

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:40: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 5939321F86A7 for ; Tue, 24 Apr 2012 03:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.144
X-Spam-Level: 
X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=0.833,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 Ak6shwLOQEvs for ; Tue, 24 Apr 2012 03:40:36 -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 193CF21F8667 for ; Tue, 24 Apr 2012 03:40:35 -0700 (PDT)
Received: by mail-lpp01m010-f44.google.com with SMTP id j5so411025lag.31 for ; Tue, 24 Apr 2012 03:40:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=w/nS02Z0BpU9EmlK1z77BcRI1E8Ab8UWxUcb1ybr0uI=; b=p4bmoHBAkbTfhAX8tYIpHnFL2En9WFZKoH3OPZYGynt5VQ4LBYM0iBHADheB3/xF8b oPTF1Y9HpUCy4b5N7FL2AEl2rpoZCc/YvMMS8SEP4/LI2Lrl449UtjknJvv2+wToWj7L HAH+CyUYisx28mFGWJqdPImKFHiw+WePQGmZpT6X8MgoqQ7qIqC6qg54rl5hzJt5EuwT rSfe1WUFyiOadQI+QtrVAuSf16TrDTMvLwiL+eHMQd1NZDyFPq+oRtYOadBvN+LZHxwO YNr/0PPj70eJ85xk5F5dAI7ODJP6bXdnGgxtoxAeKhl2PNhebeYtbkfB103f9fdMCYhr 0G2g==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18634640lab.8.1335264035749; Tue, 24 Apr 2012 03:40:35 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:40:35 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:40:35 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlgY+EC8SPT+ylipN7h24fm6hWCR1DNTwCnRsZyV+fmcPp+v1cZxAv1SPKbipfVmZWeY1eu
Subject: [scim] Canonical groups types (SCIM 1.0 cleanup)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:40:37 -0000

The Canonical types for groups attribute begins with capital letter,
but all other are lowercase. just a simple change.

//Samuel

From samuel@erdtman.se  Tue Apr 24 03:41:10 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614221F858E for ; Tue, 24 Apr 2012 03:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.263
X-Spam-Level: 
X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 tAcMQKcysWNO for ; Tue, 24 Apr 2012 03:41:09 -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 45F9C21F8584 for ; Tue, 24 Apr 2012 03:41:09 -0700 (PDT)
Received: by lagj5 with SMTP id j5so411746lag.31 for ; Tue, 24 Apr 2012 03:41:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=bZvwTb0c0YWGAgw4Ucr/Dfe0SNKk0dXGVPXLsSBOABo=; b=Wf4TJi/iH+JpDFKW0Z5sL2HG+7rc/qpz6x37R81WmV8rsw0//Sos68SqCJSq8SCrxN FfdDNV5wWTqkwHU8C4tA9A6pDSfkO9J6En1RiqkPHK19d/q6tP8a+joqjYBKn5UpuhXP B0+zrXuCd8rTu6aqBWfCxgbrN8G8yo8YGF6J/vpgeGnlVxucsqwL7rRyvTzChI0OZF/g NbXVUFOlLnWm36Yw5l975adMNiHb1Q2YcZOEjgMYQvYw6gSNfOmLYKuPGmqVgs8dZd76 FDSi5E23h8O+Fs56D0GyKrrzS2aoJCIKqvg4h4J9/seeUyh8DlzP90FcSVhNEC/NpkVx Lo7A==
MIME-Version: 1.0
Received: by 10.112.38.36 with SMTP id d4mr3188846lbk.72.1335264068261; Tue, 24 Apr 2012 03:41:08 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:41:08 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:41:08 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmSF3VQpThEBhmHAVeRryzILbFK7WU4Fechu5cF73f+IE1c+Ema/4OiAf6DbxZ2CyR2AhHc
Subject: [scim] authenticationSchema in core (SCIM 1.0 improvement)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 10:41:10 -0000

In answer to the question "Should not authenticationSchema be outside
of the SCIM core schema?" Kelly wrote
"This is defined in the ServiceProviderConfig, which regardless of the
transport protocol should be available. You're right that this assumes
the REST protocol. Perhaps authenticationSchemas should have a
sub-attribute that specifies the applicable protocol?"

Thoughts? Is this something that we want to have?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:41:46 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180D21F85A2 for ; Tue, 24 Apr 2012 03:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level: 
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 BUGsTKhOh4Rs for ; Tue, 24 Apr 2012 03:41:46 -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 B15E621F858E for ; Tue, 24 Apr 2012 03:41:45 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so413941lbg.31 for ; Tue, 24 Apr 2012 03:41:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=wFQ1wZUyxdhTEFLlffWn6TZTRfj7JHWGYLfAwri9DkE=; b=lempLQ1xuNrF/gjVKV2sBn/ydpaLgiZ0uAPrGyhxPhdv5LO/h3ytyCYMIhrhx3H/f+ Sx6jFh2H2JDZpgRYLWdiswwfXwr07dlC8VSg/paB3f0YSUW+cHgtdBk2P6bUdSIhEmii yfXUUw/6WIAf0V6p5CAiDg9ef5U8atri8CI+dtvbtJy+16MRoqqe5QbfoDFTp6lD+PRD DYzxX6W5kN5RnUDnruCgcDIVvpqviozVyJOfJxNnK+NixMmkmDOes8MUk9KbN9RdwK9R n3ZGPu6CVuMwrjASVDIqadvWYH51vYhQ/e+IfdunxqhW2O0TkaH8drLJ1naaxcjVgGr2 Fscw==
MIME-Version: 1.0
Received: by 10.152.127.163 with SMTP id nh3mr18625053lab.15.1335264104650; Tue, 24 Apr 2012 03:41:44 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:41:44 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:41:44 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmXlvYjKgtnKNyV3IKQ8Uj8Gw/1nEkYhCeBEHw8qII92i45/mzkfatKoL5Ba6ayowY6V+pX
Subject: [scim] Multi-valued attributes are unordered (SCIM 1.0 clarification)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:41:46 -0000

Multi-valued attributes are unordered but it is not clearly described,
so some text needs to be added, I would suggest to add it here
http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor4

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:42: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 C379021F864A for ; Tue, 24 Apr 2012 03:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level: 
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 IyLADnQsdp9e for ; Tue, 24 Apr 2012 03:42: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 022FD21F85A2 for ; Tue, 24 Apr 2012 03:42:26 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so414447lbg.31 for ; Tue, 24 Apr 2012 03:42:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=9C7BiBs/gLdeIBW0Ehen2of9X0ZWQ2IyDLpA0vpeamo=; b=j71U0XnDW0pRoPlCmoDFcttwOLOYDC3dd0+ZJzlh/WQK2u6DZV88H1nmfipYybZyTr qN/umcTclwm3YXu6cCP5Hw7KtGpRPnMm0Abx7eSNrrspDeso8ILQtwNi4jqTLevA5Dwm tbeTvs2T3wpjPxfX55pmQCuEtHFW5h8Tg3zhOAVqn1EV2z9QJzUELDRz08Mavuz8IAmf vU5F7ZawAFvZP49P4JjzS+THFWwvOLZ1hUnvR8L5xBvSdbIS0ER9WQhzb1W3OcSOxqSM 2mn12mUriZurswlNxOE8G5LlZcBUuOSaSF3i3OJfAMeTfmBzjrTa6j2602GvK0qYbDh0 Umsw==
MIME-Version: 1.0
Received: by 10.152.112.100 with SMTP id ip4mr18838723lab.1.1335264145975; Tue, 24 Apr 2012 03:42:25 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:42:25 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:42:25 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnmKnEbz339Ey2N5S6nQgOyzSzLGK6heVkSX/og184CKE6YZTiaj286azRTGysjnPvR7UOv
Subject: [scim] Multi-valued type attribute is optional (SCIM 1.0 clarification)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:42:27 -0000

Add language that says type on multi-valued attributes are optional
(http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#multi-value-types)

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:42: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 6213021F865A for ; Tue, 24 Apr 2012 03:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.177
X-Spam-Level: 
X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 wvZ5QIkDtcT8 for ; Tue, 24 Apr 2012 03:42:50 -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 8E3E621F85A2 for ; Tue, 24 Apr 2012 03:42:50 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id c1so414447lbg.31 for ; Tue, 24 Apr 2012 03:42:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=7Z47rrhTLoTcKFs13kcJW7lDkffAZTVqEvI7Klfi4X4=; b=Ubf6WyzpXj/gtyLjwg3iYbmBqPRxoVRVsHKvTklxkzPl9q0LJPS+CJqUnY8AUL3q4I xyWjTJajt7feyEskC1p6emtLGb4hEKT+T9LHZSjN2RQe4+WIpk38dNOu5lhqx1SbCDez wu8BiT+G73bs9W9PyBH5hCpTBgihWE61qExFa3KndN+Ck7PJ2KXACpW3pYj6fWY2UBoJ nkzk75KlwwZhLXnbnNylarfgbSj3jW0RVTa6W7nJSOmthRDcS0W8A+gLIRT05ScqFPaE s9AXKr1zCsce2ftcKPF8kluGUb7DvhxAW9ePdlaY2U8MLD62QWxeTFMgmb40GHYRk5iN qv6Q==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18641179lab.8.1335264170210; Tue, 24 Apr 2012 03:42:50 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:42:50 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:42:50 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkQUu0RLQ5ag3xCUrcf83kQmdONsXpDxCkLtJzlOJHGUpxEbA4EiebI7uh9Qe1qd8hzthqH
Subject: [scim] Change middleName to additionalName (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, 24 Apr 2012 10:42:51 -0000

To be more internationally correct Radovan suggested to change
middleName to additionalName in the name attribute. I have put this as
something to consider for SCIM 2.0 since changing it in SCIM 1.0 would
efficiently break interoperability, however it might still be an
option.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:43: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 A9E5021F864A for ; Tue, 24 Apr 2012 03:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.159
X-Spam-Level: 
X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 noKIJdUdYtuC for ; Tue, 24 Apr 2012 03:43:15 -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 323CF21F85A2 for ; Tue, 24 Apr 2012 03:43:15 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id c1so414447lbg.31 for ; Tue, 24 Apr 2012 03:43:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=GjCye770rsGeug5X687xy4ck7ZiMMEbWLu4thhV77YA=; b=E91CxU/Kvh+uA86qCTZ1rIRoLJM643r1NqV6OiL0IYsXTojlP5Llg2C/6GJSHY/Tno 7EPypAdJ7MV2ycM3qSWYJbwKKMeVD6fBst3vkoPIaCJLo72oLG8rRF8NEJakY1dSEik1 JjUhvBst8vmgSNPZ8899c22Z/H5Ro327ryVJ46sSs1+KAh1A4AA925ZoOShLePIDsQiS DKq5ptkaNYqqZzMFKtg4kv8rVXrbidC73pRJh0XMFmfz17vXgtBBF+YDO+qz3CnDt0pS khbH9pDivC9I7RTppT3xKrUhsdAq4B7Spoyoq8+rKfe0IMBdJRfhkoi+BL2Gi+AdrMdq g8vg==
MIME-Version: 1.0
Received: by 10.112.26.197 with SMTP id n5mr9419584lbg.58.1335264194832; Tue, 24 Apr 2012 03:43:14 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:43:14 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:43:14 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkJdyIvf3nWXWY2nFKDlD7aOH0WQQM/UrPDGZHjjgf7RnoGEcJ1m/YO+kOxB4bTpUh1FDPD
Subject: [scim] Name confusion (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, 24 Apr 2012 10:43:16 -0000

There are several attribute with similar meaning e.g. displayName,
userName and name.formatted. Radovan calls this an LDAP anti-pattern.
should we considering eliminating some of them in SCIM 2.0?

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:43: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 76E1821F8661 for ; Tue, 24 Apr 2012 03:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.144
X-Spam-Level: 
X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 txdJjNNnfyrV for ; Tue, 24 Apr 2012 03:43:44 -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 A8A4021F865F for ; Tue, 24 Apr 2012 03:43:43 -0700 (PDT)
Received: by lagj5 with SMTP id j5so413494lag.31 for ; Tue, 24 Apr 2012 03:43:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=eX5aK1mrNh8+DIneIaQmFZ4bUb0GTTmL1gqqDridOT0=; b=ms+433wAYxtcQXBf6XLyCsrt2ZcBFTWCMOp7puw8UfOa8Gxl3m4saO2Ys4A9W91uJ8 ch4s418i6//W6yJQsr8UZItngQuM2VXpADbAkgnrm/t3M54+UBRIGwKhs+/dJtNxEGi+ J18ZNUhf1usQSAZc+UFhr2HUsLd1drpTXR+nN/Qy0MkBXUyL7NPxMe+XyyN9nmCeHnIe hDXm3ou4xTUXIlKMYzhuoTIThiSNTLAAReYNEgT3BwTH/q/r027wn4Y+wG4v0BVXn06r 7vGSbNT9oLb1XjbrLv7gMWw2rT31W1qS64cavGqrfm+7IjAfY3FelT97XJkby85JNyil mRaA==
MIME-Version: 1.0
Received: by 10.112.23.100 with SMTP id l4mr4061447lbf.100.1335264222664; Tue, 24 Apr 2012 03:43:42 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:43:42 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:43:42 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmt7d5WnN2tDhYCB28DcjJSQTeDjWBig4LlRFfZ110c4CybIDDTxY7tdQk7i6sVLEMGtKe7
Subject: [scim] Move nickname into name attribute (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, 24 Apr 2012 10:43:45 -0000

Would nickname fit better into the name, than being on its own as it
is today. I have put this as something to consider for SCIM 2.0 since
changing it in SCIM 1.0 would efficiently break interoperability,
however it might still be an option.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:44: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 BC4BB21F864B for ; Tue, 24 Apr 2012 03:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level: 
X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 j67SBSVx0fPY for ; Tue, 24 Apr 2012 03:44:06 -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 0FC0121F864A for ; Tue, 24 Apr 2012 03:44:05 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so415685lbg.31 for ; Tue, 24 Apr 2012 03:44:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=RNUVuHlH6MtGy6HOemV4HPzdYwzWlsBjmNOEpGRhsPs=; b=f0IYLlAOijXp3F0BiRI5lrLu92q8y1y1RuYT9ukUyqudB9qttwIhU1m4yt3aoPQAW3 GDcFVjqRXiWNNe/UvPjwYmTysUYSf3o2u1dZYvhjDPZex4h40Qo4pxyJd6fqTUL+ROx2 2jKRCFqkhvEXTdHZE04K8JXVSjFTLBVjrYgbSbhJQszCAuVNSO4QVY/ahWoAcj+GGEum oo4jzeM0ZCfg0dEoPnecp6bBaAiOAIAxYBQtApfCd2fj++qBd+I4llDBLTSXaQRcre5v JvbUCbCGFd7ioW6eT6Uyx5nPKRg+v2MU1J4YJKEchqy2GBbVsiSuLKWgC+3heNPBqWdP RIkw==
MIME-Version: 1.0
Received: by 10.112.38.36 with SMTP id d4mr3193207lbk.72.1335264244938; Tue, 24 Apr 2012 03:44:04 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:44:04 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:44:04 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmZ+XlMu9zhaKB+F5ULBwEfriq1HKy0sWIyslU08bDnbszu6ht+e7926TJYX1JQh9ddsK+0
Subject: [scim] Move title and userType to enterprise extension (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, 24 Apr 2012 10:44:06 -0000

Would title and userType fit better in a enterprise extension? I have
put this as something to consider for SCIM 2.0 since changing it in
SCIM 1.0 would efficiently break interoperability, however it might
still be an option.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:44: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 76F9521F865A for ; Tue, 24 Apr 2012 03:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level: 
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.143,  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 gRYVicyq4TYP for ; Tue, 24 Apr 2012 03:44:29 -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 AB4BA21F864A for ; Tue, 24 Apr 2012 03:44:28 -0700 (PDT)
Received: by lagj5 with SMTP id j5so414003lag.31 for ; Tue, 24 Apr 2012 03:44:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=U1DgpyKZ5xaSQ5jpFM/GwB8VnIcIRNp8tfWBWusgvuQ=; b=WMiR7IVQhrvvUEqKDbZjiP0FN5tvr9AdxssOlbCZee+r7OPwwWZI/yWZu6ge2mgefy b2B0PvFKMRdWgjNFwaUoGFEu++sjqba9ka8ys9N0K5BuPu0sP8zT1hr2q2gE2Tbgxtrk CploUTVlLPJETFYcbUk6K0qMqixYi2hBsoxJ4dST03WYAplcrEaX49dydoUH6NX+qrvH Ls5mQ749hSSjbuQeQIu2rKMvjylOdcTXHaGkO4sRCckzPWpGb2x4/sDnXWAZEKUn+Uo5 1HYqyL083l7jXhWsAlDtSRPYlCarwzYdwzKCKxUWgYoegkNSoG0t8vKyRR+/wDVLUrYK 20Fg==
MIME-Version: 1.0
Received: by 10.152.112.100 with SMTP id ip4mr18844559lab.1.1335264267639; Tue, 24 Apr 2012 03:44:27 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:44:27 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:44:27 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlSOYNSiRhZZaFQmmUvB1PKI9v8g/SA77kwzhNGLWnMqNst9D7jia3hbCxKR1s/BWbG5MQ9
Subject: [scim] Groups, Entitlement, Roles (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, 24 Apr 2012 10:44:29 -0000

Should we have them all? Should we have detailed language on how to
handle the different once and there relationship to each other? Or
should we include them but not tell implementors how to use the
different once?

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:44: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 51F7D21F864B for ; Tue, 24 Apr 2012 03:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.11
X-Spam-Level: 
X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=-0.133,  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 ju9jsppUpm-H for ; Tue, 24 Apr 2012 03:44:56 -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 8439921F865F for ; Tue, 24 Apr 2012 03:44:56 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so416255lbg.31 for ; Tue, 24 Apr 2012 03:44:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ggdQpSmIJ9NiyO+GdV7d7mnuj6lumAUzkyxwmO/OvdA=; b=fpLrTrcQOTs+JHhGbspf9ahb7pYBa7HOXI9BPihW0ozGA7wvNh3/9kmqXrlveHIHEZ hq+T3cZOoK5+uxNaKmsFLM1QmUrhjCKh1MEotIeMPu+K4y9atjgJIDYnbHpJrT1hkFFM HTBUSE72Meu4UAGe9nSsf31hYBpSuiFt14AQ6CCMvGEVbQ8Euvij7+TWHBNrZqFZRfKN vuR08bO/BNwpSUtlTfOzaIhb+bp9ZZV6YesnXfWZr5PfUBw6CrNVWDCyVkUCnWnxAN+o AxR5AG2jbgABGceGZdMiUQ/TDJNV6+LyhzYDKvmfgTzT6pm2vfahOZcSEXKCu7BFdZsp HiDQ==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18647038lab.8.1335264293357; Tue, 24 Apr 2012 03:44:53 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:44:53 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:44:53 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkyl9rnPDEnQ/XuKjVs65e5A48GNavodexKxD2184ZEvlUC44UaEvUB2ETJbqS/xbl+IQjt
Subject: [scim] Writable groups on user (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, 24 Apr 2012 10:44:57 -0000

It has been considered before, the problem is that the groups
attribute on the user may contain dynamic and inherited groups which
makes removal of group membership through the user hard.
As I see it the arguments for managing group membership directly on
the user are:
* Easier to manage very large groups if membership can be changed from
the user object.
* Systems that require group membership when creating a user.

Thoughts? should we consider a writable groups attribute on the user
in SCIM 2.0?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:45: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 9356421F8661 for ; Tue, 24 Apr 2012 03:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 T4V0VHU+bzpg for ; Tue, 24 Apr 2012 03:45:20 -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 DE5CC21F864B for ; Tue, 24 Apr 2012 03:45:19 -0700 (PDT)
Received: by lagj5 with SMTP id j5so414581lag.31 for ; Tue, 24 Apr 2012 03:45:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=CMzd0f/tVbAPK73BQ5cWYNexMieVf4cu/yW0HlaZRFg=; b=cpYe1EhLFiWiw3EFyKa1LDai09GWdINoXmEFsMAYQCokp1+NvGnWQ08VAV3PmBdGk6 KzOGxaSVK2x8y9yTrAETdEvErtjWi6knhNlpRrmR9qohHXQNjA/kzJ4VrhfFw6pGAQIi tZygxf6M9g+0muQZmZwu276Rm08uB3XI3Y+sVIk9bfrkyH1nmZHPRH23H/TDQ8ZYa90L Mh9cQLn1ITWK/jENJwNqCaW7yHNe1/KEiYnD1NlW1XEGP9gwU6E52RV94PpNC7TAlvIF ca2cjgWx+u/aD5ZcBgI/5gRsjkPmztcwV187YBnB3ookaq3OtWfevbQg3I7EZZAAJrrx kITQ==
MIME-Version: 1.0
Received: by 10.152.127.163 with SMTP id nh3mr18635210lab.15.1335264318918; Tue, 24 Apr 2012 03:45:18 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:45:18 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:45:18 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQn/8vS0yO/GOKQF/MdLYHYInhURdpgGeAkqn7LX9g6LOGZyD8dCZV3IyDt9FNvFPxxZ7UCi
Subject: [scim] BaseUrl vs. absolute url (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, 24 Apr 2012 10:45:20 -0000

In SCIM 1.0 all endpoints are refereed from a baseUrl this might be a
problem if e.g. endpoints are located on different domains. Would it
be better to use absolute URL:s instead when referring endpoints (see
http://www.w3.org/2001/tag/doc/alternatives-discovery.html)

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:45: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 03D8B21F865F for ; Tue, 24 Apr 2012 03:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Level: 
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 9DrXW0nGfv53 for ; Tue, 24 Apr 2012 03:45: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 4130A21F8661 for ; Tue, 24 Apr 2012 03:45:43 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so416795lbg.31 for ; Tue, 24 Apr 2012 03:45:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=n1i6DC59iqGpfnwpueOVXZNuj0lOXR428pnd7TC6nEc=; b=iJcUUh/5MqqV6pgjMzfmafZvIN8LlJyE+Dlxwx4s58ZVHHP/9kfCHWmOphw1MFD16D HiAKMLDF60iYt1O9Nvip2ubOb3qJg3p8g5YAEH/SdfajCbLL9y6q8AWUYfjSNIiR6oPL k4KAfPYj/b9caP8b3jn8+CznKX9WPMsD/aVqSog0G+77NGs2498kfG9HNfOgiwCtRd94 G3vHY6jcbADPbB1CEktTUjCx5H8lfUlBuSGSeFd/7v6VZWegxgQkd1qBh5N876wmF014 dDhIzADWeMotPfQ5Kp9GcipkBdLdDgEMts9iVcEiYNEmnvT3rCvteRRH799DBLRVGdWt ioVA==
MIME-Version: 1.0
Received: by 10.152.104.43 with SMTP id gb11mr18649353lab.8.1335264342111; Tue, 24 Apr 2012 03:45:42 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:45:42 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:45:42 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm9/vv904rW4Rxvv9nYC25PhhfqE4wDGj6l5jFSLL7LogMtXn/YcY5NT7jse/9lMV2qAD1N
Subject: [scim] Arbitrary attribute level (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, 24 Apr 2012 10:45:44 -0000

In SCIM 1.0 sub-attributes cannot have sub-attributes, according to
Radovan this was a strange limit. In my understanding he expected
either one level or arbitrary levels.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:46: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 8CD0821F8671 for ; Tue, 24 Apr 2012 03:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.071
X-Spam-Level: 
X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 NCM9UWfHOi34 for ; Tue, 24 Apr 2012 03:46:33 -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 BD41221F8667 for ; Tue, 24 Apr 2012 03:46:32 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so417319lbg.31 for ; Tue, 24 Apr 2012 03:46:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=q8AVGvP+gEysoBPfaNQOvVGMUSsQoMxB8uak3tUC/EA=; b=Qe74PPMIWvhElvjb8c+aoWThkwCZ0NGyPYU6uCX0y955xVuWhN3zkjJyos2vWZnfu5 ExFDFYRiv6q8+QYJDRG+ogBMCmwElFJaMxZsIj0VHpNxSYnKqoDwjDj2yYqZ0OKdtBg1 fJI0WeR2gFsCjz+FjFyvi6GC7/WrKmtYK2OskTE0gMkjQ9OJZywDTkuXfIvc5H/z5kK4 VC9LquDlP0o61EcB9E3GZA6FhzVMt80BflOM1CJO3eUxa9kQaefXaadh2r3ls91IqUPX xNokNYrtt3VYUXIcx4HjJOvwX4fePObVVGvxfhyrCHC3ZO1lMRgCcmOTc3D/J3yFEpOk hbsA==
MIME-Version: 1.0
Received: by 10.112.38.36 with SMTP id d4mr3196842lbk.72.1335264391763; Tue, 24 Apr 2012 03:46:31 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:46:31 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:46:31 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkQDltcL0894wXu4zHQipwKhWy8JBfrx29RvggWqCsjPXPT5ldjFNvKHoBbwbkTv5ezPdi3
Subject: [scim] URL for multi-valued attribute type (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, 24 Apr 2012 10:46:33 -0000

This is taken directly from Radovans email
The type meta-attribute in the multi-valued attributes is a plain
string. This is prone to conflicts, especially in ims and similar
"open" attributes. URL instead of plain string may be a better choice.

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:47: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 A0EC821F8671 for ; Tue, 24 Apr 2012 03:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level: 
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Rrxq2-6ASDAx for ; Tue, 24 Apr 2012 03:47:05 -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 B479E21F8667 for ; Tue, 24 Apr 2012 03:47:04 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so417654lbg.31 for ; Tue, 24 Apr 2012 03:47:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=cJQWkgUS7HIhl3UiGpivEtLnHd4ySWRZBSrI0eOHlrY=; b=ZMFovy1AXuq2mlitiSSBaJMVOs/IeoDvflZ90yqQO8jJrB41dRRsGseJKhTA+sC6bY 6jT84N9H1/wNPuJGXAl1xH3TkW26iidLnhwERVFsPeCGzSl/WQRS8J4NBiEpqhXkMPVb aZtK8R6Ko/0atDSJjQ7EykN4CRU6UPkz6BxDGB3FQn9gR+QHpHiawRVHYLRfg+CP3Vwp 1kvzkiQUIGdXHyn6oQSnSJWM64dIX1wuQAErQ2eKj9FN+smzuxt7VLzF0Tnh++J51XhB v6zoKzKRfyFuXxk1O0t4c3ir58ccGLF58VrcibDnehpXxxtagz7EauvOvjZ7IRvXm/ox 2yzw==
MIME-Version: 1.0
Received: by 10.112.85.103 with SMTP id g7mr9412684lbz.86.1335264423652; Tue, 24 Apr 2012 03:47:03 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:47:03 -0700 (PDT)
Date: Tue, 24 Apr 2012 12:47:03 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm+161lj51V4NiNOyTVPc5V6ggr6VWf6Z1Sj2zf1I8MunQ8AsSNYw2KlOcCkmr+MnsFS5mM
Subject: [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, 24 Apr 2012 10:47:05 -0000

Since extensions are not contained within an extension node there are
the possibility of conflicts with existing and future attributes.
Would it be desirable to put extensions within an extension node
(since extensions as Kelly mentioned are defined by URN:s conflicts
are in worst cases rare).
Today a user with two extensions could look like this
{
 "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1,
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
{
 "schemas":["urn:scim:schemas:core:1.0", ext1, ext2],
 "userName": "kalle",
 "extension": {
   "urn:scim:schemas:ext1": {
      employeeNumber: "abc123"
    },
   "urn:scim:schemas:ext2": {
     employeeNumber: "123abc"
   }
 }
}

Thoughts?
(for details see the thread
http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and
the http://www.simplecloud.info/ page)
//Samuel

From samuel@erdtman.se  Tue Apr 24 03:49:11 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89DA21F8671 for ; Tue, 24 Apr 2012 03:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level: 
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 L8ptf1e4Bwji for ; Tue, 24 Apr 2012 03:49:11 -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 0EECF21F8667 for ; Tue, 24 Apr 2012 03:49:10 -0700 (PDT)
Received: by lagj5 with SMTP id j5so417273lag.31 for ; Tue, 24 Apr 2012 03:49:10 -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 :content-type:x-gm-message-state; bh=2+tSfPpoIrN5SVcgjeS7NqSf5O3mRk8YcucXCLbfCDA=; b=PZ12TuuK7554QR8QduzE6Ssb24Cw69wougExMnEO1ComqqQWapht2RcF7BPkt1Lc93 23fthYR7baRldbWTprdOeBseUe2C1iQdr37npXeRTGJPHY8JiBBcXcx/XbYkn2Y7yPdt BWPYvVhupmknS6okUW/zasdgUpSEMN6SmEL/FCvJHUUE9UHNlU1Vdm+C+MP9R3ovGGL7 8CSCqMH7gZpFdi0uMTIsWyn/8A8dTmdIVUTXlnxX3CsAdeEwEJbaN/9DUwiv56XRxGyi HBGYiJzbsiT+kKBN7gkZF8jte7hxBCAKg3pQBgi+bD8pa7QdzdMXldQdwyeWuAyBDvah ULvQ==
MIME-Version: 1.0
Received: by 10.152.145.1 with SMTP id sq1mr18827409lab.22.1335264550042; Tue, 24 Apr 2012 03:49:10 -0700 (PDT)
Received: by 10.112.84.106 with HTTP; Tue, 24 Apr 2012 03:49:09 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 24 Apr 2012 12:49:09 +0200
Message-ID: 
From: Samuel Erdtman 
To: scim@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlwe8r5uqPEGCE3EhyK38ZnMiIAriMkBOQuGLrWKkSlKSMkjbdQ1PbKTOH8Y4RtjuPflbAY
Subject: Re: [scim] Addressing SCIM issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 10:49:11 -0000

Just noticed that i miss-spelled SCIM in lots of emails, could be an
argument for a name change :)

//Samuel

On Tue, Apr 24, 2012 at 12:37 PM, Samuel Erdtman  wrote:
> The long and much appreciated email from Radovan contained lots of
> good stuff (http://www.ietf.org/mail-archive/web/scim/current/msg00235.html).
> Some things to consider for SCIM 2.0 and some thins that needs to be
> clarify in SCIM 1.0 specification.
> I have read through the conversation in an attempt to find concrete
> action that should be easy to consider. To make each issue easy to
> address I will send them in several separate emails so that none is
> forgotten.
>
> I send these emails on the IETF mailing list since the issues where
> brought up here, even thug the SCIM 1.0 issues might be better suited
> on the old list. I am sorry for any inconvenience.
>
> Cheers
> //Samuel

From radovan.semancik@evolveum.com  Tue Apr 24 05:41: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 84CAD21F87C0 for ; Tue, 24 Apr 2012 05:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.658
X-Spam-Level: 
X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 iEE47x3Ru6uS for ; Tue, 24 Apr 2012 05:41:44 -0700 (PDT)
Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0E81D21F87F3 for ; Tue, 24 Apr 2012 05:41:43 -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 A3DCDA43B86 for ; Tue, 24 Apr 2012 14:41:41 +0200 (CEST)
Message-ID: <4F969F85.3030408@evolveum.com>
Date: Tue, 24 Apr 2012 14:41:41 +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: <4F8E8CF3.50407@evolveum.com>		<56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>	<00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>	<4F8F9451.4030703@gmail.com>	<00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 12:41:45 -0000

On 04/24/2012 12:38 PM, Samuel Erdtman wrote:
> Resource schema has name attribute that obviously points to the object type. But it seems to be plain string. Namespace is not obvious here. If any SCIM extension adds a new object types (which seems likely) this may be very confusing. URL may be a better choice here
> Could you give some more details and may be an example?

Resource schema has "name" attribute defined as:
'The Resource name. When applicable Service Providers MUST specify the 
name specified in the core schema specification; e.g., "User" or "Group".'

I guess that this is supposed to also contain user-defined types, not 
just the standard "User" and "Group" of SCIM core schema. So let's 
assume that I define a resource with name "Role" and create a custom 
resource schema for that. My concern was that this "Role" may be in 
conflict with future SCIM versions that could also define its own role. 
But now as I see that maybe the "schema" attribute was meant to define 
the namespace for the resource. I haven't realized that before and if 
that is really the case it should be clearly stated in the specification 
(and it also partially answers the other question regarding "schema" 
attribute below).

Anyway, there is still one issue. If I define my own "Role" in 
http://midpoint.evolveum.com/xml/ns/.... namespace and SCIM 1.1 defines 
"Role" in urn:scim:schemas:core:1.1 namespace, how could they be used 
together? Adding new standard object type is supposed to be a compatible 
change as far as I understand the principles. But only one of the Role 
types can have the "Role" name in the resource schema, is that correct? 
Even though the namespaces are different, only one of them can be used. 
This may prohibit existing deployments to use the new standard role 
mechanism while also keeping its own mechanism (maybe just for a 
migration period).

Also there is one more thing to consider: Should be SCIM 1.1 
backwards-compatible with SCIM 1.0? If that is the case, then maybe it 
is not a good idea to change the "urn:scim:schemas:core:1.0" to 
"urn:scim:schemas:core:1.1" for SCIM 1.1, as that would surely break 
existing implementations. If that is the case, then maybe 
"urn:scim:schemas:core:1" is sufficient as a namespace URI? It would 
also be less confusing if SCIM 1.1 uses the "urn:scim:schemas:core:1" 
namespace instead of "urn:scim:schemas:core:1.0".

>> The multiValuedAttributeChildName attribute and associated way how to represent data in XML seems to add to the redundancy of the data format. Strictly speaking, this one is also quite specific to XML and should not be in the generic core schema.
> I might not be perfect but it works, and I cannot se what other
> document to put it into? any suggestions?

We have used similar mechanism in midPoint. Instead of using this:


   ...
....
   ...

.....
.....

   ..


we use this:


   ...
....
   ...
...
...
   ...


Less elements means less overhead, we do not need to bother with the 
 vs  problem and there is less redundancy in the data 
format. And both formats can be conveniently expressed in XSD and both 
are well supported by JAXB and similar technologies. It is also much 
cleaner in the XSD schema as both single and mutli attributes are 
represented in the same way differentiated only by maxOccurs XSD attribute.

>> When defining an attribute in a resource schema, how is attribute schema used? Is it a namespace that applies to attribute type? Or to the attribute name? Attribute has schema and sub-attribute does not? Why? Does it inherit it from parent? The specification should make that clear.
> Could you give some more details and may be an example?

If the schema is represented like this:

{
   "id":"urn:scim:schemas:core:1.0:User",
   "name":"User",
   "description":"Core User",
   "schema":"urn:scim:schemas:core:1.0",
   "endpoint":"/Users",
   "attributes":[
     {
       "name":"id",
       "type":"string",
       "multiValued":false,
       "description":"Unique identifier for the SCIM resource as defined by the Service Provider. Each representation of the resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of resources. It MUST be a stable, non-reassignable identifier that does not change when the same resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. REQUIRED.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":true,
       "required":true,
       "caseExact":false
     },
     ....


Does it mean that the name "id" should be considered as part of the 
"urn:scim:schemas:core:1.0" schema/namespace? Or is it the type "string" 
to be considered as part of "urn:scim:schemas:core:1.0" 
schema/namespace? Or both of them?

And further below in the schema definition:

     ....
     {
       "name":"name",
       "type":"complex",
       "multiValued":false,
       "description":"The components of the user's real name. Providers MAY return just the full name as a single string in the formatted sub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":false,
       "required":false,
       "caseExact":false,
       "subAttributes":[
         {
           "name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, titles, and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J Jensen, III.)." ,
           "readOnly":false,
           "required":false,
           "caseExact":false
         },
     ....


The attribute "name" has a "schema" URI. But the sub-attribute 
"formatted" does not. Is it assumed that the sub-attribute inherits the 
schema specification from the attribute? I would guess so. But I haven't 
seen that mentioned in the specification.

But, wouldn't it be better if attribute and sub-attribute use the same 
structure to define them? E.g. if they both have "schema" specification, 
maybe as an optional part. In that way they can be represented by the 
same data structures during implemenations and processed by the same 
code. It may also allow specification of sub-attributes of 
sub-attributes which can easily resolve the (unnecessary) limitation of 
the current model.

>> Does this mean that scim intend to re-develop the equivalent of inetOrgPerson?
> I´m not sure. Some one with more insight into the directory area might
> be able to answer this question, e.g. Kelly, Trey or Morteza.

I would guess that the answer is both yes and no. SCIM schema defines 
something that is "almost, but not quite, entirely unlike 
inetOrgPerson". It is a schema that is supposed to be used to represent 
users/accounts in which it is similar to inetOrgPerson. But (at least 
from my point of view) it resolves some of the problems of inetOrgPerson 
such as multi-valued attributes ("uid", "cn", ...) that are almost never 
used as multivalued but their multivalueness complicates all 
implementations that take the specification seriously. It may also 
resolve the issues with LDAP groups and entitlements (e.g. groupOfNames 
vs groupOfUniqueNames vs dynamic groups vs (proprietary) roles). While 
inetOrgPerson is closely related to the storage of data in directories, 
SCIM should focus on external representation of that data. SCIM is also 
on a good way to provide Internet-compatible extensibility based on URIs 
rather than OIDs (which only a small part of engineers that ever used 
LDAP knows that it exists and even fewer applications really use it).

I guess that SCIM schema might be something like inetOrgPerson NG - but 
only if the serious issues of the SCIM schema are resolved.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com


From kelly.grizzle@sailpoint.com  Tue Apr 24 06:47: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 2EE2521F87F8 for ; Tue, 24 Apr 2012 06:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.561
X-Spam-Level: 
X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=1.038,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 Gb9z0v7ufgO6 for ; Tue, 24 Apr 2012 06:47:21 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8013B21F85ED for ; Tue, 24 Apr 2012 06:47:21 -0700 (PDT)
Received: from mail164-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 13:47:19 +0000
Received: from mail164-va3 (localhost [127.0.0.1])	by mail164-va3-R.bigfish.com (Postfix) with ESMTP id 1618EC011C; Tue, 24 Apr 2012 13:47:20 +0000 (UTC)
X-SpamScore: -26
X-BigFish: PS-26(zz9371I542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail164-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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; 
Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by mail164-va3 (MessageSwitch) id 1335275238541819_1968; Tue, 24 Apr 2012 13:47:18 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.254])	by mail164-va3.bigfish.com (Postfix) with ESMTP id 7DDB34C008F; Tue, 24 Apr 2012 13:47:18 +0000 (UTC)
Received: from BL2PRD0410HT002.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; Tue, 24 Apr 2012 13:47:15 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.81]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Tue, 24 Apr 2012 13:47:15 +0000
From: Kelly Grizzle 
To: Samuel Erdtman , "scim@ietf.org" 
Thread-Topic: [scim] Canonical groups types (SCIM 1.0 cleanup)
Thread-Index: AQHNIgaznbukQEnen0CyRNvQsRdd2Jap+wxw
Date: Tue, 24 Apr 2012 13:47:15 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C34371C689755@BL2PRD0410MB351.namprd04.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [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] Canonical groups types (SCIM 1.0 cleanup)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 13:47:22 -0000

There was recently a discussion about being able to dereference a group mem=
ber.  Since the members list can contain both groups and users we need some=
 way to distinguish the resource type.  For example:

{
  "members": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "type": "User"
    },
    {
      "value": "902c246b-6245-4190-8e05-00816be7344a",
      "type": "Group"
    }
]

It would be nice to be able to get the URL for the full representation for =
each of these members.  Since User and Group are the "name" attribute in th=
e schema, a client could look up the endpoint in the schema and construct a=
 URL (eg - https://www.example.com/scim/v1/Users/2819c223-7f76-453a-919d-41=
3861904646).

There is another proposal to just have each element contain the URL to full=
 representation.  In this case the canonical types could be lowercase, but =
I still kind of like the symmetry with the schema name.

In any case, this needs some more thought and might be worth adding to the =
issue tracker so we don't lose it.

--Kelly

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sam=
uel Erdtman
Sent: Tuesday, April 24, 2012 5:41 AM
To: scim@ietf.org
Subject: [scim] Canonical groups types (SCIM 1.0 cleanup)

The Canonical types for groups attribute begins with capital letter, but al=
l other are lowercase. just a simple change.

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



From stephen.farrell@cs.tcd.ie  Tue Apr 24 08: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 F015621F87E5 for ; Tue, 24 Apr 2012 08:12: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=[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 oQbjK6POD5cj for ; Tue, 24 Apr 2012 08:12:36 -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 E885921F87F3 for ; Tue, 24 Apr 2012 08:12:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E03271714DF; Tue, 24 Apr 2012 16:12:33 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335280353; bh=OBJioEyw+rTse7 IXOTRsISUTWY387Y2hoBVeEBypbHw=; b=3aYyauugG1N+IDAr++6bqE0a0Ik7L4 sM8Sjsbp6ziS9SRqVehy4D9OqFuY3Bdz07V1S5fDqVAXpAD9Ii+X3OPppbax73tx H8Ec68ofx6Z1gP87B+bnJgsG972h8tqMGf2yDR6a82JDwbdhJFfABcVclqH8Ft67 lBiLdz/FlYgcMpY5wvVSs/Cm53nwicC3+/eHyZqIdWiNYAXQ0V1b1mAZefIfiv7W f+TCknHowpTS+lbfyebCpGdgFupfhFXIJNebdu1PwMB63V/uq+WLR6ur7gGe8DBN 5nByUInf0OAweJhUGFDRmS1NpD2sa2Lm5xaDxYezBNJ76JJA10QXWuAg==
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 t6pHmYVoog1K; Tue, 24 Apr 2012 16:12:33 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7197F1714DC; Tue, 24 Apr 2012 16:12:33 +0100 (IST)
Message-ID: <4F96C2DE.30703@cs.tcd.ie>
Date: Tue, 24 Apr 2012 16:12:30 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Radovan Semancik 
References: <4F8E8CF3.50407@evolveum.com>		<56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>	<00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>	<4F8F9451.4030703@gmail.com>	<00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com>
In-Reply-To: <4F969F85.3030408@evolveum.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 15:12:37 -0000

On 04/24/2012 01:41 PM, Radovan Semancik wrote:
> On 04/24/2012 12:38 PM, Samuel Erdtman wrote:

>>> Does this mean that scim intend to re-develop the equivalent of
>>> inetOrgPerson?

That was my question I think, thanks for the answer.

>> I´m not sure. Some one with more insight into the directory area might
>> be able to answer this question, e.g. Kelly, Trey or Morteza.

So the other part of my question was: why do we *need*
to do that re-definition? What would not work if we just
used inetOrgPerson (or some other existing equivalent).
Doing the work for fun doesn't see appealing.

> I would guess that the answer is both yes and no. SCIM schema defines
> something that is "almost, but not quite, entirely unlike
> inetOrgPerson". 

Not quite a compelling answer to "why" so far - but I'm sure
it wasn't mean to be:-)

> It is a schema that is supposed to be used to represent
> users/accounts in which it is similar to inetOrgPerson. But (at least
> from my point of view) it resolves some of the problems of inetOrgPerson

You'd have to wonder though if it also introduces new equally
problematic things. I don't know that it does, but I'd bet a
beer that it will.

> such as multi-valued attributes ("uid", "cn", ...) that are almost never
> used as multivalued but their multivalueness complicates all
> implementations that take the specification seriously. 

One could profile that, e.g. say that when uid is used for SCIM
it MUST NOT have >1 value (or whatever).

> It may also
> resolve the issues with LDAP groups and entitlements (e.g. groupOfNames
> vs groupOfUniqueNames vs dynamic groups vs (proprietary) roles). 

I don't know that issue. Can you elaborate a bit?

> While
> inetOrgPerson is closely related to the storage of data in directories,
> SCIM should focus on external representation of that data. 

Hmmm. LDIF exists too. But regardless of the concrete encoding,
inetOrgPerson could be mapped to JSON or whatever is flavour of
the month right now.

> SCIM is also
> on a good way to provide Internet-compatible extensibility based on URIs
> rather than OIDs (which only a small part of engineers that ever used
> LDAP knows that it exists and even fewer applications really use it).

What'd be wrong with RFC 3061 there? (For "standard" types that is.)
The IETF can and do allocate OIDs for various things and making those
look like a URI is easy.

> I guess that SCIM schema might be something like inetOrgPerson NG - but
> only if the serious issues of the SCIM schema are resolved.

Right. That's the main concern - if the SCIM schema is currently
not-baked then maybe an existing one with known problems is better,
and maybe quicker as well and much more likely to map to directories
without problems.

Cheers,
S.

PS: Note, I'm not actually saying SCIM should use inetOrgPerson
or other LDAP classes, I'm trying to understand if or why it cannot.




> 

From michael.hammer@yaanatech.com  Tue Apr 24 09:55: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 CEFCE21E8015 for ; Tue, 24 Apr 2012 09:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level: 
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 vfy0LNuxLiBR for ; Tue, 24 Apr 2012 09:55:31 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A321E804D for ; Tue, 24 Apr 2012 09:55:31 -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; Tue, 24 Apr 2012 09:55:31 -0700
From: Michael Hammer 
To: "radovan.semancik@evolveum.com" , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQACAANSxgIAAkPwAgAAwHwD//7g6cIAAwKCAgAAdO0CACCXWAIAAIoWA///PmlA=
Date: Tue, 24 Apr 2012 16:55:30 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A2A06@EX2K10MB1.corp.yaanatech.com>
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com> <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com>
In-Reply-To: <4F969F85.3030408@evolveum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.17.88.8]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01CD2200.61D5FA50"
MIME-Version: 1.0
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 16:55:35 -0000

------=_NextPart_000_0009_01CD2200.61D5FA50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

           "name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, =
titles,
and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J
Jensen, III.)." ,

This looks more like a definition of a "display name"

ISTM that name is a composite of an ordered series of atomic attributes. =

Each atomic attribute could contain a sub-attribute binary flag that =
says
whether to display or not.
One could also include a sub-attribute that indicates the order =
preference
for display as well.

I am not sure why a given datum needs to be included twice.
Is there a reason for being more complicated than that?

Some of the discussion regarding mutability seems to be around the =
notion of
what is the true key to storing and retrieval of records.
Is this then some effort to achieve 3rd normal form or something =
similar?

Mike


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Radovan Semancik
Sent: Tuesday, April 24, 2012 5:42 AM
To: scim@ietf.org
Subject: Re: [scim] SCIM Issues

On 04/24/2012 12:38 PM, Samuel Erdtman wrote:
> Resource schema has name attribute that obviously points to the object =

> type. But it seems to be plain string. Namespace is not obvious here. =
If
any SCIM extension adds a new object types (which seems likely) this may =
be
very confusing. URL may be a better choice here Could you give some more
details and may be an example?

Resource schema has "name" attribute defined as:
'The Resource name. When applicable Service Providers MUST specify the =
name
specified in the core schema specification; e.g., "User" or "Group".'

I guess that this is supposed to also contain user-defined types, not =
just
the standard "User" and "Group" of SCIM core schema. So let's assume =
that I
define a resource with name "Role" and create a custom resource schema =
for
that. My concern was that this "Role" may be in conflict with future =
SCIM
versions that could also define its own role.=20
But now as I see that maybe the "schema" attribute was meant to define =
the
namespace for the resource. I haven't realized that before and if that =
is
really the case it should be clearly stated in the specification (and it
also partially answers the other question regarding "schema"=20
attribute below).

Anyway, there is still one issue. If I define my own "Role" in
http://midpoint.evolveum.com/xml/ns/.... namespace and SCIM 1.1 defines
"Role" in urn:scim:schemas:core:1.1 namespace, how could they be used
together? Adding new standard object type is supposed to be a compatible
change as far as I understand the principles. But only one of the Role =
types
can have the "Role" name in the resource schema, is that correct?=20
Even though the namespaces are different, only one of them can be used.=20
This may prohibit existing deployments to use the new standard role
mechanism while also keeping its own mechanism (maybe just for a =
migration
period).

Also there is one more thing to consider: Should be SCIM 1.1
backwards-compatible with SCIM 1.0? If that is the case, then maybe it =
is
not a good idea to change the "urn:scim:schemas:core:1.0" to
"urn:scim:schemas:core:1.1" for SCIM 1.1, as that would surely break
existing implementations. If that is the case, then maybe
"urn:scim:schemas:core:1" is sufficient as a namespace URI? It would =
also be
less confusing if SCIM 1.1 uses the "urn:scim:schemas:core:1"=20
namespace instead of "urn:scim:schemas:core:1.0".

>> The multiValuedAttributeChildName attribute and associated way how to
represent data in XML seems to add to the redundancy of the data format.
Strictly speaking, this one is also quite specific to XML and should not =
be
in the generic core schema.
> I might not be perfect but it works, and I cannot se what other=20
> document to put it into? any suggestions?

We have used similar mechanism in midPoint. Instead of using this:


   ...
....
   ...

.....
.....

   ..


we use this:


   ...
....
   ...
...
...
   ...


Less elements means less overhead, we do not need to bother with the
 vs  problem and there is less redundancy in the data =
format.
And both formats can be conveniently expressed in XSD and both are well
supported by JAXB and similar technologies. It is also much cleaner in =
the
XSD schema as both single and mutli attributes are represented in the =
same
way differentiated only by maxOccurs XSD attribute.

>> When defining an attribute in a resource schema, how is attribute =
schema
used? Is it a namespace that applies to attribute type? Or to the =
attribute
name? Attribute has schema and sub-attribute does not? Why? Does it =
inherit
it from parent? The specification should make that clear.
> Could you give some more details and may be an example?

If the schema is represented like this:

{
   "id":"urn:scim:schemas:core:1.0:User",
   "name":"User",
   "description":"Core User",
   "schema":"urn:scim:schemas:core:1.0",
   "endpoint":"/Users",
   "attributes":[
     {
       "name":"id",
       "type":"string",
       "multiValued":false,
       "description":"Unique identifier for the SCIM resource as defined =
by
the Service Provider. Each representation of the resource MUST include a
non-empty id value. This identifier MUST be unique across the Service
Provider's entire set of resources. It MUST be a stable, =
non-reassignable
identifier that does not change when the same resource is returned in
subsequent requests. The value of the id attribute is always issued by =
the
Service Provider and MUST never be specified by the Service Consumer.
REQUIRED.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":true,
       "required":true,
       "caseExact":false
     },
     ....


Does it mean that the name "id" should be considered as part of the
"urn:scim:schemas:core:1.0" schema/namespace? Or is it the type "string" =

to be considered as part of "urn:scim:schemas:core:1.0"=20
schema/namespace? Or both of them?

And further below in the schema definition:

     ....
     {
       "name":"name",
       "type":"complex",
       "multiValued":false,
       "description":"The components of the user's real name. Providers =
MAY
return just the full name as a single string in the formatted =
sub-attribute,
or they MAY return just the individual component attributes using the =
other
sub-attributes, or they MAY return both. If both variants are returned, =
they
SHOULD be describing the same name, with the formatted name indicating =
how
the component attributes should be combined.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":false,
       "required":false,
       "caseExact":false,
       "subAttributes":[
         {
           "name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, =
titles,
and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J
Jensen, III.)." ,
           "readOnly":false,
           "required":false,
           "caseExact":false
         },
     ....


The attribute "name" has a "schema" URI. But the sub-attribute =
"formatted"
does not. Is it assumed that the sub-attribute inherits the schema
specification from the attribute? I would guess so. But I haven't seen =
that
mentioned in the specification.

But, wouldn't it be better if attribute and sub-attribute use the same
structure to define them? E.g. if they both have "schema" specification,
maybe as an optional part. In that way they can be represented by the =
same
data structures during implemenations and processed by the same code. It =
may
also allow specification of sub-attributes of sub-attributes which can
easily resolve the (unnecessary) limitation of the current model.

>> Does this mean that scim intend to re-develop the equivalent of
inetOrgPerson?
> I=B4m not sure. Some one with more insight into the directory area =
might=20
> be able to answer this question, e.g. Kelly, Trey or Morteza.

I would guess that the answer is both yes and no. SCIM schema defines
something that is "almost, but not quite, entirely unlike =
inetOrgPerson". It
is a schema that is supposed to be used to represent users/accounts in =
which
it is similar to inetOrgPerson. But (at least from my point of view) it
resolves some of the problems of inetOrgPerson such as multi-valued
attributes ("uid", "cn", ...) that are almost never used as multivalued =
but
their multivalueness complicates all implementations that take the
specification seriously. It may also resolve the issues with LDAP groups =
and
entitlements (e.g. groupOfNames vs groupOfUniqueNames vs dynamic groups =
vs
(proprietary) roles). While inetOrgPerson is closely related to the =
storage
of data in directories, SCIM should focus on external representation of =
that
data. SCIM is also on a good way to provide Internet-compatible
extensibility based on URIs rather than OIDs (which only a small part of
engineers that ever used LDAP knows that it exists and even fewer
applications really use it).

I guess that SCIM schema might be something like inetOrgPerson NG - but =
only
if the serious issues of the SCIM schema are resolved.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

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

------=_NextPart_000_0009_01CD2200.61D5FA50
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
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NDE2NTUzMFowIwYJKoZIhvcNAQkEMRYEFKliT7pmLxvEhtqDVKY3msFukQkhMIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAWSVCMoLPPZeHPI2fQYdS3Y9V6TVdUKwQe2Zl6lhhkorJ
R34UvmK8/Iv1z9z9yRP/zLCq0Gq2l9P2GhXcghfQWKY4fNp/kx7XNNwhiS3W1MTv31DhBlbv4twx
BHUjGXCIgbGhzutOQOzfGezh6+xDKj+PTcXmiizb7OFtn+DlblAAAAAAAAA=

------=_NextPart_000_0009_01CD2200.61D5FA50--

From stpeter@stpeter.im  Tue Apr 24 10:35: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 E5EDB21F8853 for ; Tue, 24 Apr 2012 10:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 P6EEjaMk48hl for ; Tue, 24 Apr 2012 10:35:13 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B4A6221F86F8 for ; Tue, 24 Apr 2012 10:35:13 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1F35340058; Tue, 24 Apr 2012 11:49:46 -0600 (MDT)
Message-ID: <4F96E44F.4020408@stpeter.im>
Date: Tue, 24 Apr 2012 11:35:11 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com>  <4F873572.9060205@cisco.com>  <4F8C597E.2040609@stpeter.im>
In-Reply-To: <4F8C597E.2040609@stpeter.im>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: scim@ietf.org, "Morteza Ansari \(moransar\)" , Eliot Lear 
Subject: Re: [scim] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 17:35:17 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A bit of follow up inline...

On 4/16/12 11:40 AM, Peter Saint-Andre wrote:
> On 4/13/12 7:34 AM, Barry Leiba wrote:
>>> First, putting aside the name for a moment (we'll come back to
>>> that) what do you think of the REST of the charter (pun
>>> intended)?
>> 
>> A fair question.  I had wanted to wait for the next iteration,
>> since I know that Morteza has updates to make, based on comments.
>> But yes, here are my thoughts.
>> 
>> * I do think the charter is well thought out and well scoped, in
>> general.
>> 
>> * I am still concerned about the need to develop a new
>> *protocol*, rather than using or adapting existing protocols with
>> new, standardized schemas and uses.  It's often the case that an 
>> applicability statement on an existing protocol can do the job,
>> and I'd like to see that seriously considered *within the IETF
>> context*.
> 
> We had similar debates during formation of the PAWS WG. See for
> instance its original charter:
> 
> http://trac.tools.ietf.org/wg/paws/charters?item=charter-paws-2011-06-14.txt
>
>  Here is some of the relevant text:
> 
> ###
> 
> The overall goals of this working group are to:
> 
> 1. Standardize a mechanism for discovering a white space database.
> 
> 2. Standardize a method for accessing a white space database.
> 
> 3. Standardize query and response formats to be carried over the 
> database access method.
> 
> 4. Ensure that the discovery mechanism, database access method, and
> query/response formats have appropriate security levels in place.
> 
> By "standardize" is not meant that the working group will
> necessarily develop new technologies.  In completing its work, the
> group will:
> 
> - Evaluate existing discovery mechanisms to determine if one of 
> them provides the necessary application features and security 
> properties (or can be extended to do so) for discovering a white
> space database.  Examples might include DNS.
> 
> - Evaluate existing application-layer transport protocols to 
> determine if one of them provides the necessary application 
> features and security properties (or can be extended to do so) for
> use as a building block for communication between location- aware
> devices and white space databases.  If such a method exists, the
> group will reuse it; if not, the group will develop one.  Examples
> might include HTTP.
> 
> - Develop a method for querying a white space database.  Such a
> method will utilize, so far as possible, the features of the
> application-layer transport protocol and not re-implement them in
> the new protocol. It will include mechanisms to verify that the
> requests and responses come from authorized sources, and that they
> have not been modified in transit.  Examples might include LDAP.
> 
> - Define extensible formats for both location-specific queries and 
> location-specific responses for interaction with radio white space
> databases.  The group will consider whether existing data formats
> can be reused.
> 
> ###
> 
> Something along those lines (but briefer) might be appropriate.

Here is some proposed text...

OLD
   The Simple Cloud Identity Management (SCIM) specification
   will be designed to simplify user identity management in
   services and applications by defining standard protocols
   and schemas for creating, reading/searching, modifying,
   and deleting user identities and identity-related objects
   across administrative domains.

NEW

   The Simple Cloud 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.

   By "standardize" is not meant that the working group will
   necessarily 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.  However, those specifications do
   define novel payload formats ("schemas") for data exchange;
   these formats are designed to encapsulate an interoperable
   subset of identity-related information for communication
   between administrative domains, of the kind that is often
   contained in formats such as LDAP and vCard within an
   administrative domain.

I'm a bit unsure about the last sentence, and Barry and others might
think that we need to say something more about considering, in the
IETF context, whether to use native LDAP or vCard or other formats
instead of the novel formats currently defined in SCIM 1.0 (e.g., we
could add a sentence at the end like "The working group should
consider whether existing data formats such as LDAP and vCard are
appropriate for interchange between administrative domains.").
Naturally, feedback is welcome on that point and others.

>> * That said, something built on REST might, indeed, be the right 
>> thing.  At the risk of repeating: it's hard to know that without
>> a real analysis.  And as I said in Paris, it's hard to do an
>> objective analysis when you already have the answer you want.
>> I'm not sure how to fix that, but I think we need to try.
> 
> I think we also need to try to respect the fact that there are half
> a dozen or more existing implementations, which is different from
> the PAWS case. Running code still counts for something, and
> building upon HTTP seems like a perfectly fine thing to do here
> (it's not as if folks are thinking about designing a completely new
> application protocols, which I'd agree would be crazy). In
> particular, Barry, what would you expect the results of a more
> detailed analysis to look like here?

I'm still curious on this point, but I've tried to address the "design
a new protocol" concern in the text I provided above.

>> * I worry that there's no consideration in the charter for
>> security aspects of this, other than to specifically *exclude*
>> work on authentication and authorization.  It's probably good not
>> to spin up new mechanisms for these, but I'd like the charter to
>> say something about how the system *will* address issues of
>> authentication, authorization, access control, privacy, and
>> integrity.
> 
> Something along the lines of what was included in the original
> OAuth charter seems appropriate:
> 
> * Embody good security practice, or document gaps in its 
> capabilities, and propose a path forward for addressing the gap.
> 
> http://trac.tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt
>
>  Naturally, everything in the IETF undergoes security review, so a
> short statement seems sufficient.

I like the text that Melinda Shore provided, so I propose that we
include it in the next version of the charter. I've included it below
(with a tweak or two) after some boilerplate security text copied from
the original OAUTH WG charter:

   The working group will ensure that the SCIM protocol embodies
   good security practices, or document gaps in its capabilities
   and propose a path forward for addressing those gaps.  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.

Does that seem acceptable?

> As to the name, although I'm no fan of buzzwords in protocol names,
> I personally see no active harm in continuity here.

I stand by that statement.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+W5E8ACgkQNL8k5A2w/vxafACbB9jgr9WSmIpvUBDHOXQWvY5b
vn4An2YmxlUWz9gvDFsgINE6ABDoBoSr
=o/cG
-----END PGP SIGNATURE-----

From phil.hunt@oracle.com  Tue Apr 24 11:04: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 2437111E80C1 for ; Tue, 24 Apr 2012 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.908
X-Spam-Level: 
X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=0.091,  BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 ldL8FqBcUXRC for ; Tue, 24 Apr 2012 11:04:31 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 41BFC11E808F for ; Tue, 24 Apr 2012 11:04:31 -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 q3OI4Sjm013512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 18:04:29 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 q3OI4Rd2008792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 18:04:28 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3OI4QRf016781; Tue, 24 Apr 2012 13:04:26 -0500
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2012 11:04:26 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: 
Date: Tue, 24 Apr 2012 11:04:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <533825DB-3E7E-4BA0-8C3E-8F96377D94D7@oracle.com>
References: 
To: Samuel Erdtman 
X-Mailer: Apple Mail (2.1257)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
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, 24 Apr 2012 18:04:32 -0000

I think there may be a more complex issue.  The URN listed is usually =
the extension namespace and not the extension object.

So if you defined:

urn:scim:schemas:ext:corporate as an extended schema and within that =
defined an "employee" and a "contractor" objects, then the following =
json would be ambiguous

> {
> "schemas":["urn:scim:schemas:core:1.0", =
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 =
extendsion 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
> the possibility of conflicts with existing and future attributes.
> Would it be desirable to put extensions within an extension node
> (since extensions as Kelly mentioned are defined by URN:s conflicts
> are in worst cases rare).
> Today a user with two extensions could look like this
> {
> "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1,
> 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
> {
> "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
> the http://www.simplecloud.info/ page)
> //Samuel
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From radovan.semancik@evolveum.com  Tue Apr 24 12:15:34 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E9C21E80B3 for ; Tue, 24 Apr 2012 12:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level: 
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051,  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 c9bFyB-EFxZX for ; Tue, 24 Apr 2012 12:15:33 -0700 (PDT)
Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7566D21E80A4 for ; Tue, 24 Apr 2012 12:15:32 -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 8DAF2A43EE4 for ; Tue, 24 Apr 2012 21:15:31 +0200 (CEST)
Message-ID: <4F96FBD3.3040103@evolveum.com>
Date: Tue, 24 Apr 2012 21:15:31 +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: <4F8E8CF3.50407@evolveum.com>		<56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>	<00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>	<4F8F9451.4030703@gmail.com>	<00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com> <4F96C2DE.30703@cs.tcd.ie>
In-Reply-To: <4F96C2DE.30703@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 19:15:34 -0000

On 04/24/2012 05:12 PM, Stephen Farrell wrote:
> So the other part of my question was: why do we *need*
> to do that re-definition? What would not work if we just
> used inetOrgPerson (or some other existing equivalent).
> Doing the work for fun doesn't see appealing.

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe 
the motivation was similar to that of FOAF. Yet, as you have pointed 
out, new specifications bring new problems (including FOAF), especially 
if they are not tested in practice before they are standardized. Which 
is still the point that I consider to be the most serious issue with 
respect to SCIM standardization. But let's put that aside for now. Here 
is my personal list why not inetOrgPerson:

uid, cn and others are multivalued. This is complicating the 
implementations. Yes, it can be "profiled" to singlevalued, but that 
will actually not be inetOrgPerson any more. The "formal" compatibility 
will be gone. SCIM implementation will still needs to deal with the 
eventuality that these attributes will be multivalued on the LDAP side. 
So there will be actually quite little benefit. And after all it is not 
difficult to implement attribute name mapping. The difficult thing is 
attribute value mapping, which cannot be avoided here. Also, did you 
know that "cn" an "commonName" is actually the same attribute? I guess 
that it is something from the X.500 legacy and is not really the best 
part of LDAP schema specs. We can profile that as well, ruling out 
"commonName" and similar long attribute names. But real good 
SCIM-to-LDAP implementation must be aware of that anyway. So the mapping 
will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose 
that cn is multivalued and it is difficult to display. We do not want a 
separate attribute just to fix ages old problem. We can again profile 
this. But ... well, see above.


Address is scattered across street, l, postOfficeBox, postalCode, and 
other attributes. Yes, there is a postalAddress attribute, but it 
actually duplicates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and 
homePhone (all of them multi-valued). No way to specify work phone or 
mark which of the phone numbers is "primary" (except for copying that 
value to telephoneNumber). For email there is just one attribute (also 
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping 
mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some 
applications works with the former, some with the later. Which one to 
choose? We don't want both of them. But whatever we choose, the 
SCIM-to-LDAP code will most likely still need to support both. Both 
groupOfNames and groupOfUniqueNames contain a list of members as DNs. We 
don't want to use DNs in SCIM, so this needs to be mapped to other 
identifiers anyway (more mapping code). As listing the members of large 
groups is inefficient and cumbersome to manage, most vendors of good 
directory servers provide their own grouping mechanisms (dynamic groups, 
roles). Which means even more mapping code in the usual case.

OIDs: People that use LDAP daily and have never needed to create their 
own schema usually don't know what OIDs are good for, some of them 
probably don't know that OIDs even exist. Vast majority of LDAP code 
does not work with OIDs but with attribute and object class names. If 
SCIM would chose inetOrgPerson and still wants to maintain good 
extensibility, it MUST NOT use attribute names. It should use OIDs. 
Attribute names may collide. It is not a problem in LDAP, as LDAP is 
usually deployed in closed environment and not exposed to the Internet. 
Collisions are easy to handle in closed environments. The inetOrgPerson 
schema is also not really evolving, so the probability of collision with 
future version of inetOrgPerson is close to zero. But SCIM schema must 
be able to evolve. So OIDs are probably the only 
inetOrgPerson-compatible choice here. And I can't believe that something 
like the following example would ever be widely adopted (although I can 
see a lot of benefits going this way, we don't want SCIM to end up as 
SPML and DSML, do we?):

{
   "urn:oid:0.9.2342.19200300.100.1.1": "jack",
   "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
   ....
}

If this would be what we want then the best choice would probably be to 
stay with ASN.1. It has a solid schema language and it is one the most 
efficient data representation languages that we know. Formats based on 
ASN.1 are also well extensible. And that means that we do not really 
need another provisioning language at all! We can reuse LDAP. But ASN.1 
is quite difficult to work with. The scripting folk would hate it. 
Dealing with all the problems of JSON and XML is probably the lesser 
evil here. But what would that mean is actually re-creating ASN.1/LDAP 
in JSON and XML. I don't think we want that. DSML was something like 
that and it was not a huge success. And actually, it is probably not 
correct to fix protocol to just one URI scheme. Therefore SCIM should 
allow also other URIs for attribute names. In which case the 
SCIM-to-LDAP code will have really hard time to translate generic URIs 
to OIDs.

I guess there are much more issues that I have missed. It looks like 
taking a schema designed for one technology and trying to reuse it "as 
is" for another technology may not be the best idea. I don't try to 
suggest that LDAP is bad. I quite believe the contrary. Some things 
shows its age and the marks of evolution, but overall it is not bad. But 
it is quite incompatible with the principles of the Web. I like LDAP a 
lot and I appreciate the engineering behind it (and ASN.1 and other 
related technologies). But I don't think that the Web is ready for that 
approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in 
SCIM brings at last as many problems as would be created by introducing 
a new SCIM schema.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com


From michael.hammer@yaanatech.com  Tue Apr 24 13:31: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 6121021F853E for ; Tue, 24 Apr 2012 13:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 RhwQA840P0g6 for ; Tue, 24 Apr 2012 13:31:02 -0700 (PDT)
Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id BFDD821F8533 for ; Tue, 24 Apr 2012 13:31:00 -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; Tue, 24 Apr 2012 13:31:00 -0700
From: Michael Hammer 
To: "radovan.semancik@evolveum.com" , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNG9KFHOfKYrjznUWU9AUNoU9olZae7lAAgACkeQCAADX/AP//k6EQgACcQACAANSxgIAAkPwAgAAwHwD//7g6cIAAwKCAgAAdO0CACCXWAIAAIoWAgAAqIwCAAEPmgP//n5pQ
Date: Tue, 24 Apr 2012 20:30:59 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A2DAF@EX2K10MB1.corp.yaanatech.com>
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com> <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com> <4F96C2DE.30703@cs.tcd.ie> <4F96FBD3.3040103@evolveum.com>
In-Reply-To: <4F96FBD3.3040103@evolveum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.17.88.8]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01CD221E.7B8269C0"
MIME-Version: 1.0
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 20:31:03 -0000

------=_NextPart_000_0033_01CD221E.7B8269C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The term "overkill" comes most readily to mind.  :)

Mike


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Radovan Semancik
Sent: Tuesday, April 24, 2012 12:16 PM
To: scim@ietf.org
Subject: Re: [scim] SCIM Issues

On 04/24/2012 05:12 PM, Stephen Farrell wrote:
> So the other part of my question was: why do we *need* to do that 
> re-definition? What would not work if we just used inetOrgPerson (or 
> some other existing equivalent).
> Doing the work for fun doesn't see appealing.

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe the
motivation was similar to that of FOAF. Yet, as you have pointed out, new
specifications bring new problems (including FOAF), especially if they are
not tested in practice before they are standardized. Which is still the
point that I consider to be the most serious issue with respect to SCIM
standardization. But let's put that aside for now. Here is my personal list
why not inetOrgPerson:

uid, cn and others are multivalued. This is complicating the
implementations. Yes, it can be "profiled" to singlevalued, but that will
actually not be inetOrgPerson any more. The "formal" compatibility will be
gone. SCIM implementation will still needs to deal with the eventuality that
these attributes will be multivalued on the LDAP side. 
So there will be actually quite little benefit. And after all it is not
difficult to implement attribute name mapping. The difficult thing is
attribute value mapping, which cannot be avoided here. Also, did you know
that "cn" an "commonName" is actually the same attribute? I guess that it is
something from the X.500 legacy and is not really the best part of LDAP
schema specs. We can profile that as well, ruling out "commonName" and
similar long attribute names. But real good SCIM-to-LDAP implementation must
be aware of that anyway. So the mapping will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose that
cn is multivalued and it is difficult to display. We do not want a separate
attribute just to fix ages old problem. We can again profile this. But ...
well, see above.


Address is scattered across street, l, postOfficeBox, postalCode, and other
attributes. Yes, there is a postalAddress attribute, but it actually
duplicates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and homePhone
(all of them multi-valued). No way to specify work phone or mark which of
the phone numbers is "primary" (except for copying that value to
telephoneNumber). For email there is just one attribute (also
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping mechanisms
in LDAP: groupOfNames and groupOfUniqueNames. Some applications works with
the former, some with the later. Which one to choose? We don't want both of
them. But whatever we choose, the SCIM-to-LDAP code will most likely still
need to support both. Both groupOfNames and groupOfUniqueNames contain a
list of members as DNs. We don't want to use DNs in SCIM, so this needs to
be mapped to other identifiers anyway (more mapping code). As listing the
members of large groups is inefficient and cumbersome to manage, most
vendors of good directory servers provide their own grouping mechanisms
(dynamic groups, roles). Which means even more mapping code in the usual
case.

OIDs: People that use LDAP daily and have never needed to create their own
schema usually don't know what OIDs are good for, some of them probably
don't know that OIDs even exist. Vast majority of LDAP code does not work
with OIDs but with attribute and object class names. If SCIM would chose
inetOrgPerson and still wants to maintain good extensibility, it MUST NOT
use attribute names. It should use OIDs. 
Attribute names may collide. It is not a problem in LDAP, as LDAP is usually
deployed in closed environment and not exposed to the Internet. 
Collisions are easy to handle in closed environments. The inetOrgPerson
schema is also not really evolving, so the probability of collision with
future version of inetOrgPerson is close to zero. But SCIM schema must be
able to evolve. So OIDs are probably the only inetOrgPerson-compatible
choice here. And I can't believe that something like the following example
would ever be widely adopted (although I can see a lot of benefits going
this way, we don't want SCIM to end up as SPML and DSML, do we?):

{
   "urn:oid:0.9.2342.19200300.100.1.1": "jack",
   "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
   ....
}

If this would be what we want then the best choice would probably be to stay
with ASN.1. It has a solid schema language and it is one the most efficient
data representation languages that we know. Formats based on
ASN.1 are also well extensible. And that means that we do not really need
another provisioning language at all! We can reuse LDAP. But ASN.1 is quite
difficult to work with. The scripting folk would hate it. 
Dealing with all the problems of JSON and XML is probably the lesser evil
here. But what would that mean is actually re-creating ASN.1/LDAP in JSON
and XML. I don't think we want that. DSML was something like that and it was
not a huge success. And actually, it is probably not correct to fix protocol
to just one URI scheme. Therefore SCIM should allow also other URIs for
attribute names. In which case the SCIM-to-LDAP code will have really hard
time to translate generic URIs to OIDs.

I guess there are much more issues that I have missed. It looks like taking
a schema designed for one technology and trying to reuse it "as is" for
another technology may not be the best idea. I don't try to suggest that
LDAP is bad. I quite believe the contrary. Some things shows its age and the
marks of evolution, but overall it is not bad. But it is quite incompatible
with the principles of the Web. I like LDAP a lot and I appreciate the
engineering behind it (and ASN.1 and other related technologies). But I
don't think that the Web is ready for that approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in SCIM
brings at last as many problems as would be created by introducing a new
SCIM schema.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

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

------=_NextPart_000_0033_01CD221E.7B8269C0
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
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NDIwMzA1OFowIwYJKoZIhvcNAQkEMRYEFBGHwF2EYf6Jt2j8t7lOffbvBv2FMIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAj3PyELEQV6hPgad4QU/KFsyMyD3j3OeF/+HFBzYDZcQV
FJwC0w3CvfNbV7A7/F4UXCNH0yv/rN/+9WGBEos1mMX750QtlyxeiWNQUOklnASr3hANY7tVl20+
S9wrmxBRLYqKpO6nEqALCWL2Lknf/0xRNbPVFvg+TQYCYxRPX5AAAAAAAAA=

------=_NextPart_000_0033_01CD221E.7B8269C0--

From edreux@cloudiway.com  Tue Apr 24 13:42: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 59C8211E80A4 for ; Tue, 24 Apr 2012 13:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level: 
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 ixFtiaW9H1HR for ; Tue, 24 Apr 2012 13:42:29 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5911E808D for ; Tue, 24 Apr 2012 13:42:28 -0700 (PDT)
Received: from mail120-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 20:42:27 +0000
Received: from mail120-db3 (localhost [127.0.0.1])	by mail120-db3-R.bigfish.com (Postfix) with ESMTP id 6803A3C05F1; Tue, 24 Apr 2012 20:42:27 +0000 (UTC)
X-SpamScore: -76
X-BigFish: PS-76(zz9371Ic89bh542M15caKJzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT002.eurprd06.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail120-db3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT002.eurprd06.prod.outlook.com ; .outlook.com ; 
Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1335300145466783_17516; Tue, 24 Apr 2012 20:42:25 +0000 (UTC)
Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.236])	by mail120-db3.bigfish.com (Postfix) with ESMTP id 640D61A007C; Tue, 24 Apr 2012 20:42:25 +0000 (UTC)
Received: from AMXPRD0610HT002.eurprd06.prod.outlook.com (157.56.248.213) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 20:42:25 +0000
Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.188]) by AMXPRD0610HT002.eurprd06.prod.outlook.com ([10.255.58.37]) with mapi id 14.16.0143.004; Tue, 24 Apr 2012 20:42:23 +0000
From: Emmanuel Dreux 
To: Kelly Grizzle , Samuel Erdtman , "scim@ietf.org" 
Thread-Topic: [scim] Canonical groups types (SCIM 1.0 cleanup)
Thread-Index: AQHNIjsjqfZXgu0HT06Mo3ffj9wQ0JaqaiSQ
Date: Tue, 24 Apr 2012 20:42:22 +0000
Message-ID: 
References:  <56C3C758F9D6534CA3778EAA1E0C34371C689755@BL2PRD0410MB351.namprd04.prod.outlook.com>
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34371C689755@BL2PRD0410MB351.namprd04.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [62.212.99.192]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CRA-Verdict: 157.56.248.213$sailpoint.com%0%1%cloudiway.com%False%False%0$
X-OriginatorOrg: cloudiway.com
X-Mailman-Approved-At: Tue, 24 Apr 2012 14:09:20 -0700
Subject: Re: [scim] Canonical groups types (SCIM 1.0 cleanup)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 20:43:05 -0000

If you need this info, could it simply reference the location instead of th=
e uniqueID?=20
{
  "members": [
    {"value": "http://www.company.com/{tenantID}/users/2819c223-7f76-453a-9=
19d-413861904646"},
    {"value": "http://www.company.com/{tenantID}/groups/902c246b-6245-4190-=
8e05-00816be7344a"}
]
}

If you refer to Active Directory, the member attribute of a Group contains =
distinguishedNames.
It does not tell if the DN is a user or group object and we do not need thi=
s information.

Today, in our implementation, having just the uniqueID as it's currently de=
fined in the spec, is sufficient.
As other meta-directories, we retrieve the entire list of users and groups =
in each sources and targets to be able to make internal reconciliations.
Therefore we have all objects and we perform lookups in both our user and g=
roup table to find the referenced uniqueID.

--
Cordialement,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 1 46 15 07 22
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De=A0: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20
Envoy=E9=A0: mardi 24 avril 2012 15:47
=C0=A0: Samuel Erdtman; scim@ietf.org
Objet=A0: Re: [scim] Canonical groups types (SCIM 1.0 cleanup)

There was recently a discussion about being able to dereference a group mem=
ber.  Since the members list can contain both groups and users we need some=
 way to distinguish the resource type.  For example:

{
  "members": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "type": "User"
    },
    {
      "value": "902c246b-6245-4190-8e05-00816be7344a",
      "type": "Group"
    }
]

It would be nice to be able to get the URL for the full representation for =
each of these members.  Since User and Group are the "name" attribute in th=
e schema, a client could look up the endpoint in the schema and construct a=
 URL (eg - https://www.example.com/scim/v1/Users/2819c223-7f76-453a-919d-41=
3861904646).

There is another proposal to just have each element contain the URL to full=
 representation.  In this case the canonical types could be lowercase, but =
I still kind of like the symmetry with the schema name.

In any case, this needs some more thought and might be worth adding to the =
issue tracker so we don't lose it.

--Kelly

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sam=
uel Erdtman
Sent: Tuesday, April 24, 2012 5:41 AM
To: scim@ietf.org
Subject: [scim] Canonical groups types (SCIM 1.0 cleanup)

The Canonical types for groups attribute begins with capital letter, but al=
l other are lowercase. just a simple change.

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





From stephen.farrell@cs.tcd.ie  Tue Apr 24 14:22:27 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B079311E80AE for ; Tue, 24 Apr 2012 14:22:27 -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 Ch1AdRrhoY+q for ; Tue, 24 Apr 2012 14:21:59 -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 1EC8521F8619 for ; Tue, 24 Apr 2012 14:21:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BA2A21714E1; Tue, 24 Apr 2012 22:21:57 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335302517; bh=JVfQcgL2mrYvKD Pa2zyrLDtB3tbJRLtxqybnX1f56vs=; b=AVDJGdukvArCIiuq80rGT9wkOzwqVE qBi6FrLq7XrRnI/4I7ofX9cYe/K80quBxCpT41swHCs0Yja81H5UbLUaKPeUCUho q9lARCvxfWcixvrG2CnbeXKyTVPIvxCDW+05XC7EJgdmIKTD0hCR5FhCZ1akFoCM gLWZtuA6syQI4w/s/wE6vNzTZxm+DYkfT4/Itml9MMbBPQVlIgzP3r8gvE7y9kG2 fM5TA7k+L8fE1acyG5gsSNb+Er+cRcwmepVD5kPJN21cZShJwF1oF2zqCMc3bKY5 CjfE0ueSRKqIh18aUow6E1psYXF1JJtGKp1+7HixPWlEj9y+xLMYNn3w==
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 40+xb8f1p7fc; Tue, 24 Apr 2012 22:21:57 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.42.27.157]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 060141714DC; Tue, 24 Apr 2012 22:21:56 +0100 (IST)
Message-ID: <4F97196A.4000308@cs.tcd.ie>
Date: Tue, 24 Apr 2012 22:21:46 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Radovan Semancik 
References: <4F8E8CF3.50407@evolveum.com>		<56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com>	<00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com>	<4F8F9451.4030703@gmail.com>	<00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com> <4F96C2DE.30703@cs.tcd.ie> <4F96FBD3.3040103@evolveum.com>
In-Reply-To: <4F96FBD3.3040103@evolveum.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "scim@ietf.org" 
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 21:22:28 -0000

So plenty of reasons to cringe if thinking of using
inetOrgPerson, and I think you're probably right in
your text below about those.

But still no reason why it could not work.

FWIW, on the basis that I would expect as many
cringeworthy things in a new schema, some of which
wouldn't be discovered for a few years, I guess
I'm not personally convinced a new one is a necessity.

Having said that, if no-one else is concerned about
this, then maybe a new schema is fine. (And no-one
else has expressed this particular concern on the
list so far that I recall.)

S


On 04/24/2012 08:15 PM, Radovan Semancik wrote:
> On 04/24/2012 05:12 PM, Stephen Farrell wrote:
>> So the other part of my question was: why do we *need*
>> to do that re-definition? What would not work if we just
>> used inetOrgPerson (or some other existing equivalent).
>> Doing the work for fun doesn't see appealing.
> 
> I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe
> the motivation was similar to that of FOAF. Yet, as you have pointed
> out, new specifications bring new problems (including FOAF), especially
> if they are not tested in practice before they are standardized. Which
> is still the point that I consider to be the most serious issue with
> respect to SCIM standardization. But let's put that aside for now. Here
> is my personal list why not inetOrgPerson:
> 
> uid, cn and others are multivalued. This is complicating the
> implementations. Yes, it can be "profiled" to singlevalued, but that
> will actually not be inetOrgPerson any more. The "formal" compatibility
> will be gone. SCIM implementation will still needs to deal with the
> eventuality that these attributes will be multivalued on the LDAP side.
> So there will be actually quite little benefit. And after all it is not
> difficult to implement attribute name mapping. The difficult thing is
> attribute value mapping, which cannot be avoided here. Also, did you
> know that "cn" an "commonName" is actually the same attribute? I guess
> that it is something from the X.500 legacy and is not really the best
> part of LDAP schema specs. We can profile that as well, ruling out
> "commonName" and similar long attribute names. But real good
> SCIM-to-LDAP implementation must be aware of that anyway. So the mapping
> will not be considerably simpler.
> 
> There is cn and displayName. The displayName is there for the purpose
> that cn is multivalued and it is difficult to display. We do not want a
> separate attribute just to fix ages old problem. We can again profile
> this. But ... well, see above.
> 
> 
> Address is scattered across street, l, postOfficeBox, postalCode, and
> other attributes. Yes, there is a postalAddress attribute, but it
> actually duplicates the information. Even that can be profiled ... but ...
> 
> There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and
> homePhone (all of them multi-valued). No way to specify work phone or
> mark which of the phone numbers is "primary" (except for copying that
> value to telephoneNumber). For email there is just one attribute (also
> multi-valued) and also no way how to mark primary address.
> 
> There are at least two frequently used an incompatible grouping
> mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some
> applications works with the former, some with the later. Which one to
> choose? We don't want both of them. But whatever we choose, the
> SCIM-to-LDAP code will most likely still need to support both. Both
> groupOfNames and groupOfUniqueNames contain a list of members as DNs. We
> don't want to use DNs in SCIM, so this needs to be mapped to other
> identifiers anyway (more mapping code). As listing the members of large
> groups is inefficient and cumbersome to manage, most vendors of good
> directory servers provide their own grouping mechanisms (dynamic groups,
> roles). Which means even more mapping code in the usual case.
> 
> OIDs: People that use LDAP daily and have never needed to create their
> own schema usually don't know what OIDs are good for, some of them
> probably don't know that OIDs even exist. Vast majority of LDAP code
> does not work with OIDs but with attribute and object class names. If
> SCIM would chose inetOrgPerson and still wants to maintain good
> extensibility, it MUST NOT use attribute names. It should use OIDs.
> Attribute names may collide. It is not a problem in LDAP, as LDAP is
> usually deployed in closed environment and not exposed to the Internet.
> Collisions are easy to handle in closed environments. The inetOrgPerson
> schema is also not really evolving, so the probability of collision with
> future version of inetOrgPerson is close to zero. But SCIM schema must
> be able to evolve. So OIDs are probably the only
> inetOrgPerson-compatible choice here. And I can't believe that something
> like the following example would ever be widely adopted (although I can
> see a lot of benefits going this way, we don't want SCIM to end up as
> SPML and DSML, do we?):
> 
> {
>   "urn:oid:0.9.2342.19200300.100.1.1": "jack",
>   "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
>   ....
> }
> 
> If this would be what we want then the best choice would probably be to
> stay with ASN.1. It has a solid schema language and it is one the most
> efficient data representation languages that we know. Formats based on
> ASN.1 are also well extensible. And that means that we do not really
> need another provisioning language at all! We can reuse LDAP. But ASN.1
> is quite difficult to work with. The scripting folk would hate it.
> Dealing with all the problems of JSON and XML is probably the lesser
> evil here. But what would that mean is actually re-creating ASN.1/LDAP
> in JSON and XML. I don't think we want that. DSML was something like
> that and it was not a huge success. And actually, it is probably not
> correct to fix protocol to just one URI scheme. Therefore SCIM should
> allow also other URIs for attribute names. In which case the
> SCIM-to-LDAP code will have really hard time to translate generic URIs
> to OIDs.
> 
> I guess there are much more issues that I have missed. It looks like
> taking a schema designed for one technology and trying to reuse it "as
> is" for another technology may not be the best idea. I don't try to
> suggest that LDAP is bad. I quite believe the contrary. Some things
> shows its age and the marks of evolution, but overall it is not bad. But
> it is quite incompatible with the principles of the Web. I like LDAP a
> lot and I appreciate the engineering behind it (and ASN.1 and other
> related technologies). But I don't think that the Web is ready for that
> approach yet.
> 
> I'm not here to judge, but it looks to me that reusing inetOrgPerson in
> SCIM brings at last as many problems as would be created by introducing
> a new SCIM schema.
> 

From wmills@yahoo-inc.com  Tue Apr 24 14:28: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 9F55E21F8646 for ; Tue, 24 Apr 2012 14:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.284
X-Spam-Level: 
X-Spam-Status: No, score=-17.284 tagged_above=-999 required=5 tests=[AWL=0.314, 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 yNG8avICmYGt for ; Tue, 24 Apr 2012 14:28:14 -0700 (PDT)
Received: from nm6-vm0.bullet.mail.ac4.yahoo.com (nm6-vm0.bullet.mail.ac4.yahoo.com [98.139.52.70]) by ietfa.amsl.com (Postfix) with SMTP id E802021F8645 for ; Tue, 24 Apr 2012 14:28:13 -0700 (PDT)
Received: from [98.139.52.190] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 24 Apr 2012 21:28:10 -0000
Received: from [98.139.52.137] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 24 Apr 2012 21:28:10 -0000
Received: from [127.0.0.1] by omp1020.mail.ac4.yahoo.com with NNFMP; 24 Apr 2012 21:28:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 823795.57135.bm@omp1020.mail.ac4.yahoo.com
Received: (qmail 51521 invoked by uid 60001); 24 Apr 2012 21:28:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1335302890; bh=VLRMMJucpSRjrH6bqertvArpXailUCI2sxUadOoc/IM=; 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=XRTmpusBy3Xm9GpWZhajDfRfoNbeqG5SPmRLceSSlBMf991EHcN0uBzBV6H4CT8dqnJ/nM4QnloeBaDuaoYZzljSKmPMJZgZe8NHhhZhH2oTi6UjeZdn8xzqNJwgmY3qPPaC0Wi+MfQO0FkK7+E6YyP7TSJt29sMU/RG7033/D4=
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=ZZ+NUKc2FGkZqthhnCZwdXgGlBLNuGm4Bb/qMCRbGrm71EEnFwjRHDujHk8KRFetRv0ndGz+XRwXDcoNnIYDdzdV5IhyacURM15JNo/6hhAnneW6mdvchrYbigA/8QlMaDKXQH1BaTH8dl849fDR+B81pfGqeZATmilaK5QmVqU=;
X-YMail-OSG: g1MOhS4VM1mAOfzcfGVQdPfINXZ82tS.BvmtvGeSFZDf6sE qlQN5CmkZlu1YgFag_remTYBmIHgGX.hWHUy7VZSnDYkx.VvxvsClMI6eaVy fRpKaeYYktJ91AWpvEaCd_N0sC2Ben3tRgsej2eZOEYd2WdkzNjsrq5JLMsJ oD1FyvYXTiu8waiFN5Q8o2R33h0QF6i7iq8utQaFhw_bQRJxiLe2YCVO_Zoq Sfr1dfNBc9f86K8V1nWoQ6LtQ.WaDRtIkTKwN6VX1XMKi7NNAoh_pNLgBI8u FkyMOCLSZ5A.sfmulP1QOAQvj99K_DgfojZvWaFDoyHPz1AYVhoFMfaWyv6p aZSlLrOwJ.rZv.crUrc1dE9x.j25E2IJq6_b7OS56oEeiMrdC9zceSnG6fqY cMDHuZxJETAofQMYle1Mt5GERQTfakOqr9hf1TYDdMoPIRaEaf_5iFriQ5Ls GcUjMjCHfhKOE1TxXf_D80VxI1e18UTn5zJ2ogrSxivuC0Md8pbBxXtlEu3w FLZ.qAPA8ViUsB7SLIZFNS8hGSxLUyL4N0EMgswbmqAeJDKwqeSmrty8fowN q
Received: from [209.131.62.120] by web31816.mail.mud.yahoo.com via HTTP; Tue, 24 Apr 2012 14:28:10 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com> <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com> <4F96C2DE.30703@cs.tcd.ie> <4F96FBD3.3040103@evolveum.com> <4F97196A.4000308@cs.tcd.ie>
Message-ID: <1335302890.96236.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Tue, 24 Apr 2012 14:28:10 -0700 (PDT)
From: William Mills 
To: Stephen Farrell , Radovan Semancik 
In-Reply-To: <4F97196A.4000308@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-1056895246-1335302890=:96236"
Cc: "scim@ietf.org" 
Subject: Re: [scim] SCIM Issues
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: Tue, 24 Apr 2012 21:28:15 -0000

---1238014912-1056895246-1335302890=:96236
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

As an observer, developing a new schema is a big thing.=A0 It would really =
be surprising to me if there isn't something out there that already does mo=
st of what's needed.=A0 Extending something like that seems a better soluti=
on than defining a completely new one from the ground up.=0A=0A-bill=0A=0A=
=0A=0A=0A>________________________________=0A> From: Stephen Farrell =0A>To: Radovan Semancik  =0A>Cc: "scim@ietf.org"  =0A>Sent: Tuesday, April 24, 201=
2 2:21 PM=0A>Subject: Re: [scim] SCIM Issues=0A> =0A>=0A>So plenty of reaso=
ns to cringe if thinking of using=0A>inetOrgPerson, and I think you're prob=
ably right in=0A>your text below about those.=0A>=0A>But still no reason wh=
y it could not work.=0A>=0A>FWIW, on the basis that I would expect as many=
=0A>cringeworthy things in a new schema, some of which=0A>wouldn't be disco=
vered for a few years, I guess=0A>I'm not personally convinced a new one is=
 a necessity.=0A>=0A>Having said that, if no-one else is concerned about=0A=
>this, then maybe a new schema is fine. (And no-one=0A>else has expressed t=
his particular concern on the=0A>list so far that I recall.)=0A>=0A>S=0A>=
=0A>=0A>On 04/24/2012 08:15 PM, Radovan Semancik wrote:=0A>> On 04/24/2012 =
05:12 PM, Stephen Farrell wrote:=0A>>> So the other part of my question was=
: why do we *need*=0A>>> to do that re-definition? What would not work if w=
e just=0A>>> used inetOrgPerson (or some other existing equivalent).=0A>>> =
Doing the work for fun doesn't see appealing.=0A>> =0A>> I'm not sure why a=
uthors of SCIM chosen not to use inetOrgPerson. Maybe=0A>> the motivation w=
as similar to that of FOAF. Yet, as you have pointed=0A>> out, new specific=
ations bring new problems (including FOAF), especially=0A>> if they are not=
 tested in practice before they are standardized. Which=0A>> is still the p=
oint that I consider to be the most serious issue with=0A>> respect to SCIM=
 standardization. But let's put that aside for now. Here=0A>> is my persona=
l list why not inetOrgPerson:=0A>> =0A>> uid, cn and others are multivalued=
. This is complicating the=0A>> implementations. Yes, it can be "profiled" =
to singlevalued, but that=0A>> will actually not be inetOrgPerson any more.=
 The "formal" compatibility=0A>> will be gone. SCIM implementation will sti=
ll needs to deal with the=0A>> eventuality that these attributes will be mu=
ltivalued on the LDAP side.=0A>> So there will be actually quite little ben=
efit. And after all it is not=0A>> difficult to implement attribute name ma=
pping. The difficult thing is=0A>> attribute value mapping, which cannot be=
 avoided here. Also, did you=0A>> know that "cn" an "commonName" is actuall=
y the same attribute? I guess=0A>> that it is something from the X.500 lega=
cy and is not really the best=0A>> part of LDAP schema specs. We can profil=
e that as well, ruling out=0A>> "commonName" and similar long attribute nam=
es. But real good=0A>> SCIM-to-LDAP implementation must be aware of that an=
yway. So the mapping=0A>> will not be considerably simpler.=0A>> =0A>> Ther=
e is cn and displayName. The displayName is there for the purpose=0A>> that=
 cn is multivalued and it is difficult to display. We do not want a=0A>> se=
parate attribute just to fix ages old problem. We can again profile=0A>> th=
is. But ... well, see above.=0A>> =0A>> =0A>> Address is scattered across s=
treet, l, postOfficeBox, postalCode, and=0A>> other attributes. Yes, there =
is a postalAddress attribute, but it=0A>> actually duplicates the informati=
on. Even that can be profiled ... but ...=0A>> =0A>> There is telephoneNumb=
er, mobile (a.k.a mobileTelephoneNumber) and=0A>> homePhone (all of them mu=
lti-valued). No way to specify work phone or=0A>> mark which of the phone n=
umbers is "primary" (except for copying that=0A>> value to telephoneNumber)=
. For email there is just one attribute (also=0A>> multi-valued) and also n=
o way how to mark primary address.=0A>> =0A>> There are at least two freque=
ntly used an incompatible grouping=0A>> mechanisms in LDAP: groupOfNames an=
d groupOfUniqueNames. Some=0A>> applications works with the former, some wi=
th the later. Which one to=0A>> choose? We don't want both of them. But wha=
tever we choose, the=0A>> SCIM-to-LDAP code will most likely still need to =
support both. Both=0A>> groupOfNames and groupOfUniqueNames contain a list =
of members as DNs. We=0A>> don't want to use DNs in SCIM, so this needs to =
be mapped to other=0A>> identifiers anyway (more mapping code). As listing =
the members of large=0A>> groups is inefficient and cumbersome to manage, m=
ost vendors of good=0A>> directory servers provide their own grouping mecha=
nisms (dynamic groups,=0A>> roles). Which means even more mapping code in t=
he usual case.=0A>> =0A>> OIDs: People that use LDAP daily and have never n=
eeded to create their=0A>> own schema usually don't know what OIDs are good=
 for, some of them=0A>> probably don't know that OIDs even exist. Vast majo=
rity of LDAP code=0A>> does not work with OIDs but with attribute and objec=
t class names. If=0A>> SCIM would chose inetOrgPerson and still wants to ma=
intain good=0A>> extensibility, it MUST NOT use attribute names. It should =
use OIDs.=0A>> Attribute names may collide. It is not a problem in LDAP, as=
 LDAP is=0A>> usually deployed in closed environment and not exposed to the=
 Internet.=0A>> Collisions are easy to handle in closed environments. The i=
netOrgPerson=0A>> schema is also not really evolving, so the probability of=
 collision with=0A>> future version of inetOrgPerson is close to zero. But =
SCIM schema must=0A>> be able to evolve. So OIDs are probably the only=0A>>=
 inetOrgPerson-compatible choice here. And I can't believe that something=
=0A>> like the following example would ever be widely adopted (although I c=
an=0A>> see a lot of benefits going this way, we don't want SCIM to end up =
as=0A>> SPML and DSML, do we?):=0A>> =0A>> {=0A>>=A0  "urn:oid:0.9.2342.192=
00300.100.1.1": "jack",=0A>>=A0  "urn:oid:2.5.4.3": "cpt. Jack Sparrow",=0A=
>>=A0  ....=0A>> }=0A>> =0A>> If this would be what we want then the best c=
hoice would probably be to=0A>> stay with ASN.1. It has a solid schema lang=
uage and it is one the most=0A>> efficient data representation languages th=
at we know. Formats based on=0A>> ASN.1 are also well extensible. And that =
means that we do not really=0A>> need another provisioning language at all!=
 We can reuse LDAP. But ASN.1=0A>> is quite difficult to work with. The scr=
ipting folk would hate it.=0A>> Dealing with all the problems of JSON and X=
ML is probably the lesser=0A>> evil here. But what would that mean is actua=
lly re-creating ASN.1/LDAP=0A>> in JSON and XML. I don't think we want that=
. DSML was something like=0A>> that and it was not a huge success. And actu=
ally, it is probably not=0A>> correct to fix protocol to just one URI schem=
e. Therefore SCIM should=0A>> allow also other URIs for attribute names. In=
 which case the=0A>> SCIM-to-LDAP code will have really hard time to transl=
ate generic URIs=0A>> to OIDs.=0A>> =0A>> I guess there are much more issue=
s that I have missed. It looks like=0A>> taking a schema designed for one t=
echnology and trying to reuse it "as=0A>> is" for another technology may no=
t be the best idea. I don't try to=0A>> suggest that LDAP is bad. I quite b=
elieve the contrary. Some things=0A>> shows its age and the marks of evolut=
ion, but overall it is not bad. But=0A>> it is quite incompatible with the =
principles of the Web. I like LDAP a=0A>> lot and I appreciate the engineer=
ing behind it (and ASN.1 and other=0A>> related technologies). But I don't =
think that the Web is ready for that=0A>> approach yet.=0A>> =0A>> I'm not =
here to judge, but it looks to me that reusing inetOrgPerson in=0A>> SCIM b=
rings at last as many problems as would be created by introducing=0A>> a ne=
w SCIM schema.=0A>> =0A>_______________________________________________=0A>=
scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman/listinfo=
/scim=0A>=0A>=0A>
---1238014912-1056895246-1335302890=:96236
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


As an observer, developing a new schema is a big thing.  It would re=
ally be surprising to me if there isn't something out there that already do=
es most of what's needed.  Extending something like that seems a bette=
r solution than defining a completely new one from the ground up.

-bill

  
 
  
  <=
span style=3D"font-weight:bold;">From: Stephen Farrell
 <stephen.farrell@cs.tcd.ie>
 Cc: "scim@ietf.org" <s=
cim@ietf.org> 
 Sent: Tuesday, April 24, 2012 2:21 PM
 Subject: Re: [scim] SCIM Issues
  
 

So p=
lenty of reasons to cringe if thinking of using
inetOrgPerson, and I thi=
nk you're probably right in
your text below about those.

But stil=
l no reason why it could not work.

FWIW, on the basis that I would e=
xpect as many
cringeworthy things in a new schema, some of which
woul=
dn't be discovered for a few years, I guess
I'm not personally convinced=
 a new one is a necessity.

Having said that, if no-one else is conce=
rned about
this, then maybe a new schema is fine. (And no-one
else ha=
s
 expressed this particular concern on the
list so far that I recall.)
S


On 04/24/2012 08:15 PM, Radovan Semancik wrote:
> O=
n 04/24/2012 05:12 PM, Stephen Farrell wrote:
>> So the other part=
 of my question was: why do we *need*
>> to do that re-definition?=
 What would not work if we just
>> used inetOrgPerson (or some oth=
er existing equivalent).
>> Doing the work for fun doesn't see app=
ealing.
> 
> I'm not sure why authors of SCIM chosen not to use=
 inetOrgPerson. Maybe
> the motivation was similar to that of FOAF. Y=
et, as you have pointed
> out, new specifications bring new problems =
(including FOAF), especially
> if they are not tested in practice bef=
ore they are standardized. Which
> is still the point that I consider=
 to be the most serious issue with
> respect to SCIM standardization.=
 But let's put that aside for now. Here
> is my personal list
 why not inetOrgPerson:
> 
> uid, cn and others are multivalued=
. This is complicating the
> implementations. Yes, it can be "profile=
d" to singlevalued, but that
> will actually not be inetOrgPerson any=
 more. The "formal" compatibility
> will be gone. SCIM implementation=
 will still needs to deal with the
> eventuality that these attribute=
s will be multivalued on the LDAP side.
> So there will be actually q=
uite little benefit. And after all it is not
> difficult to implement=
 attribute name mapping. The difficult thing is
> attribute value map=
ping, which cannot be avoided here. Also, did you
> know that "cn" an=
 "commonName" is actually the same attribute? I guess
> that it is so=
mething from the X.500 legacy and is not really the best
> part of LD=
AP schema specs. We can profile that as well, ruling out
> "commonNam=
e" and similar long attribute names. But real good
>
 SCIM-to-LDAP implementation must be aware of that anyway. So the mapping> will not be considerably simpler.
> 
> There is cn and d=
isplayName. The displayName is there for the purpose
> that cn is mul=
tivalued and it is difficult to display. We do not want a
> separate =
attribute just to fix ages old problem. We can again profile
> this. =
But ... well, see above.
> 
> 
> Address is scattered acr=
oss street, l, postOfficeBox, postalCode, and
> other attributes. Yes=
, there is a postalAddress attribute, but it
> actually duplicates th=
e information. Even that can be profiled ... but ...
> 
> There=
 is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and
> homeP=
hone (all of them multi-valued). No way to specify work phone or
> ma=
rk which of the phone numbers is "primary" (except for copying that
>=
 value to telephoneNumber). For email there is just one attribute
 (also
> multi-valued) and also no way how to mark primary address.> 
> There are at least two frequently used an incompatible grou=
ping
> mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some<=
br>> applications works with the former, some with the later. Which one =
to
> choose? We don't want both of them. But whatever we choose, the<=
br>> SCIM-to-LDAP code will most likely still need to support both. Both=

> groupOfNames and groupOfUniqueNames contain a list of members as D=
Ns. We
> don't want to use DNs in SCIM, so this needs to be mapped to=
 other
> identifiers anyway (more mapping code). As listing the membe=
rs of large
> groups is inefficient and cumbersome to manage, most ve=
ndors of good
> directory servers provide their own grouping mechanis=
ms (dynamic groups,
> roles). Which means even more mapping code in t=
he usual case.
> 
> OIDs: People that use LDAP daily and
 have never needed to create their
> own schema usually don't know wh=
at OIDs are good for, some of them
> probably don't know that OIDs ev=
en exist. Vast majority of LDAP code
> does not work with OIDs but wi=
th attribute and object class names. If
> SCIM would chose inetOrgPer=
son and still wants to maintain good
> extensibility, it MUST NOT use=
 attribute names. It should use OIDs.
> Attribute names may collide. =
It is not a problem in LDAP, as LDAP is
> usually deployed in closed =
environment and not exposed to the Internet.
> Collisions are easy to=
 handle in closed environments. The inetOrgPerson
> schema is also no=
t really evolving, so the probability of collision with
> future vers=
ion of inetOrgPerson is close to zero. But SCIM schema must
> be able=
 to evolve. So OIDs are probably the only
> inetOrgPerson-compatible =
choice here. And I can't believe that something
> like the
 following example would ever be widely adopted (although I can
> see=
 a lot of benefits going this way, we don't want SCIM to end up as
> =
SPML and DSML, do we?):
> 
> {
>   "urn:oid:0.9.2342=
.19200300.100.1.1": "jack",
>   "urn:oid:2.5.4.3": "cpt. Jack Sp=
arrow",
>   ....
> }
> 
> If this would be wha=
t we want then the best choice would probably be to
> stay with ASN.1=
. It has a solid schema language and it is one the most
> efficient d=
ata representation languages that we know. Formats based on
> ASN.1 a=
re also well extensible. And that means that we do not really
> need =
another provisioning language at all! We can reuse LDAP. But ASN.1
> =
is quite difficult to work with. The scripting folk would hate it.
> =
Dealing with all the problems of JSON and XML is probably the lesser
>=
; evil here. But what would that mean is actually re-creating
 ASN.1/LDAP
> in JSON and XML. I don't think we want that. DSML was s=
omething like
> that and it was not a huge success. And actually, it =
is probably not
> correct to fix protocol to just one URI scheme. The=
refore SCIM should
> allow also other URIs for attribute names. In wh=
ich case the
> SCIM-to-LDAP code will have really hard time to transl=
ate generic URIs
> to OIDs.
> 
> I guess there are much m=
ore issues that I have missed. It looks like
> taking a schema design=
ed for one technology and trying to reuse it "as
> is" for another te=
chnology may not be the best idea. I don't try to
> suggest that LDAP=
 is bad. I quite believe the contrary. Some things
> shows its age an=
d the marks of evolution, but overall it is not bad. But
> it is quit=
e incompatible with the principles of the Web. I like LDAP a
> lot an=
d I appreciate the engineering behind it (and ASN.1 and
 other
> related technologies). But I don't think that the Web is rea=
dy for that
> approach yet.
> 
> I'm not here to judge, b=
ut it looks to me that reusing inetOrgPerson in
> SCIM brings at last=
 as many problems as would be created by introducing
> a new SCIM sch=
ema.
> 
_______________________________________________
scim ma=
iling list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
<=
br>
 
 
 
   

---1238014912-1056895246-1335302890=:96236--

From Chris.Phillips@canarie.ca  Tue Apr 24 14:39: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 3CF1721F8639 for ; Tue, 24 Apr 2012 14:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 C2EqfFREt7dr for ; Tue, 24 Apr 2012 14:39:02 -0700 (PDT)
Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id A5C0E21F8633 for ; Tue, 24 Apr 2012 14:39:02 -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, 24 Apr 2012 17:39:01 -0400
From: Chris Phillips 
To: "scim@ietf.org" 
Date: Tue, 24 Apr 2012 17:37:38 -0400
Thread-Topic: [scim] Draft charter - v7
Thread-Index: Ac0iYqlt5kJJjEH1RFOwFQ7sINXOTw==
Message-ID: 
In-Reply-To: <4F96E44F.4020408@stpeter.im>
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] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 21:39:03 -0000

+1 to the text from Melinda Shore, it has coverage for what's outside the
payload and talks briefly about what is in the attributes in the payload.



Chris.




On 12-04-24 1:35 PM, "Peter Saint-Andre"  wrote:

>I like the text that Melinda Shore provided, so I propose that we
>include it in the next version of the charter. I've included it below
>(with a tweak or two) after some boilerplate security text copied from
>the original OAUTH WG charter:
>
>   The working group will ensure that the SCIM protocol embodies
>   good security practices, or document gaps in its capabilities
>   and propose a path forward for addressing those gaps.  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.
>
>Does that seem acceptable?


From edreux@cloudiway.com  Tue Apr 24 15:48: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 8851711E8076 for ; Tue, 24 Apr 2012 15:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.034
X-Spam-Level: 
X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 RdOyv4J-kViW for ; Tue, 24 Apr 2012 15:48:22 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2621F8656 for ; Tue, 24 Apr 2012 15:48:21 -0700 (PDT)
Received: from mail104-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 22:48:21 +0000
Received: from mail104-db3 (localhost [127.0.0.1])	by mail104-db3-R.bigfish.com (Postfix) with ESMTP id 1C8423A04BD; Tue, 24 Apr 2012 22:48:21 +0000 (UTC)
X-SpamScore: -75
X-BigFish: PS-75(zzbb2dI9371Ic89bh15caKJ98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT002.eurprd06.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail104-db3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT002.eurprd06.prod.outlook.com ; .outlook.com ; 
Received: from mail104-db3 (localhost.localdomain [127.0.0.1]) by mail104-db3 (MessageSwitch) id 1335307698944842_8212; Tue, 24 Apr 2012 22:48:18 +0000 (UTC)
Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.232])	by mail104-db3.bigfish.com (Postfix) with ESMTP id E2718400253; Tue, 24 Apr 2012 22:48:18 +0000 (UTC)
Received: from AMXPRD0610HT002.eurprd06.prod.outlook.com (157.56.248.213) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 22:48:18 +0000
Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.188]) by AMXPRD0610HT002.eurprd06.prod.outlook.com ([10.255.58.37]) with mapi id 14.16.0143.004; Tue, 24 Apr 2012 22:48:17 +0000
From: Emmanuel Dreux 
To: Radovan Semancik , "scim@ietf.org" 
Thread-Topic: [scim] SCIM Issues
Thread-Index: AQHNIl6MTBgTU+ST1EGFR0viOIf+SJaqjkjA
Date: Tue, 24 Apr 2012 22:48:16 +0000
Message-ID: 
References: <4F8E8CF3.50407@evolveum.com>  <56C3C758F9D6534CA3778EAA1E0C34371C68751E@BL2PRD0410MB351.namprd04.prod.outlook.com> <00C069FD01E0324C9FFCADF539701DB38A10E1@EX2K10MB1.corp.yaanatech.com> <4F8F9451.4030703@gmail.com> <00C069FD01E0324C9FFCADF539701DB38A1258@EX2K10MB1.corp.yaanatech.com>  <4F969F85.3030408@evolveum.com> <4F96C2DE.30703@cs.tcd.ie> <4F96FBD3.3040103@evolveum.com>
In-Reply-To: <4F96FBD3.3040103@evolveum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [62.212.99.192]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: cloudiway.com
X-Mailman-Approved-At: Tue, 24 Apr 2012 16:33:35 -0700
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 24 Apr 2012 22:48:24 -0000

I would even prefer not having a schema at all:
1. We already maintain attribute mapping tables between sources and targets=
(name/familyName/SN/LastName, mail/email/proxyadress,LoginID)
2. Most of the time we have to exchange attributes not defined in the exist=
ing SCIM schema (social attributes, job title, job description, assistant, =
manager, SIP, +lots of other attributes). We have also to synchronize organ=
izational units with some providers, and other notions of roles and entitie=
s.

Having SCIM standardize the name of standard attributes (loginID, firstname=
, lastname, email, nickname, etc...) and leave the flexibility to exchange =
whatever we want is just what we're asking for doing our business, with dat=
a formatted on the wire in a convenient way (JSON format exchanged using RE=
ST apis).

--
Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 1 46 15 07 22
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De=A0: Radovan Semancik [mailto:radovan.semancik@evolveum.com]=20
Envoy=E9=A0: mardi 24 avril 2012 21:16
=C0=A0: scim@ietf.org
Objet=A0: Re: [scim] SCIM Issues

On 04/24/2012 05:12 PM, Stephen Farrell wrote:
> So the other part of my question was: why do we *need* to do that=20
> re-definition? What would not work if we just used inetOrgPerson (or=20
> some other existing equivalent).
> Doing the work for fun doesn't see appealing.

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe the=
 motivation was similar to that of FOAF. Yet, as you have pointed out, new =
specifications bring new problems (including FOAF), especially if they are =
not tested in practice before they are standardized. Which is still the poi=
nt that I consider to be the most serious issue with respect to SCIM standa=
rdization. But let's put that aside for now. Here is my personal list why n=
ot inetOrgPerson:

uid, cn and others are multivalued. This is complicating the implementation=
s. Yes, it can be "profiled" to singlevalued, but that will actually not be=
 inetOrgPerson any more. The "formal" compatibility will be gone. SCIM impl=
ementation will still needs to deal with the eventuality that these attribu=
tes will be multivalued on the LDAP side.=20
So there will be actually quite little benefit. And after all it is not dif=
ficult to implement attribute name mapping. The difficult thing is attribut=
e value mapping, which cannot be avoided here. Also, did you know that "cn"=
 an "commonName" is actually the same attribute? I guess that it is somethi=
ng from the X.500 legacy and is not really the best part of LDAP schema spe=
cs. We can profile that as well, ruling out "commonName" and similar long a=
ttribute names. But real good SCIM-to-LDAP implementation must be aware of =
that anyway. So the mapping will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose that =
cn is multivalued and it is difficult to display. We do not want a separate=
 attribute just to fix ages old problem. We can again profile this. But ...=
 well, see above.


Address is scattered across street, l, postOfficeBox, postalCode, and other=
 attributes. Yes, there is a postalAddress attribute, but it actually dupli=
cates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and homePhon=
e (all of them multi-valued). No way to specify work phone or mark which of=
 the phone numbers is "primary" (except for copying that value to telephone=
Number). For email there is just one attribute (also
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping mechanisms =
in LDAP: groupOfNames and groupOfUniqueNames. Some applications works with =
the former, some with the later. Which one to choose? We don't want both of=
 them. But whatever we choose, the SCIM-to-LDAP code will most likely still=
 need to support both. Both groupOfNames and groupOfUniqueNames contain a l=
ist of members as DNs. We don't want to use DNs in SCIM, so this needs to b=
e mapped to other identifiers anyway (more mapping code). As listing the me=
mbers of large groups is inefficient and cumbersome to manage, most vendors=
 of good directory servers provide their own grouping mechanisms (dynamic g=
roups, roles). Which means even more mapping code in the usual case.

OIDs: People that use LDAP daily and have never needed to create their own =
schema usually don't know what OIDs are good for, some of them probably don=
't know that OIDs even exist. Vast majority of LDAP code does not work with=
 OIDs but with attribute and object class names. If SCIM would chose inetOr=
gPerson and still wants to maintain good extensibility, it MUST NOT use att=
ribute names. It should use OIDs.=20
Attribute names may collide. It is not a problem in LDAP, as LDAP is usuall=
y deployed in closed environment and not exposed to the Internet.=20
Collisions are easy to handle in closed environments. The inetOrgPerson sch=
ema is also not really evolving, so the probability of collision with futur=
e version of inetOrgPerson is close to zero. But SCIM schema must be able t=
o evolve. So OIDs are probably the only inetOrgPerson-compatible choice her=
e. And I can't believe that something like the following example would ever=
 be widely adopted (although I can see a lot of benefits going this way, we=
 don't want SCIM to end up as SPML and DSML, do we?):

{
   "urn:oid:0.9.2342.19200300.100.1.1": "jack",
   "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
   ....
}

If this would be what we want then the best choice would probably be to sta=
y with ASN.1. It has a solid schema language and it is one the most efficie=
nt data representation languages that we know. Formats based on
ASN.1 are also well extensible. And that means that we do not really need a=
nother provisioning language at all! We can reuse LDAP. But ASN.1 is quite =
difficult to work with. The scripting folk would hate it.=20
Dealing with all the problems of JSON and XML is probably the lesser evil h=
ere. But what would that mean is actually re-creating ASN.1/LDAP in JSON an=
d XML. I don't think we want that. DSML was something like that and it was =
not a huge success. And actually, it is probably not correct to fix protoco=
l to just one URI scheme. Therefore SCIM should allow also other URIs for a=
ttribute names. In which case the SCIM-to-LDAP code will have really hard t=
ime to translate generic URIs to OIDs.

I guess there are much more issues that I have missed. It looks like taking=
 a schema designed for one technology and trying to reuse it "as is" for an=
other technology may not be the best idea. I don't try to suggest that LDAP=
 is bad. I quite believe the contrary. Some things shows its age and the ma=
rks of evolution, but overall it is not bad. But it is quite incompatible w=
ith the principles of the Web. I like LDAP a lot and I appreciate the engin=
eering behind it (and ASN.1 and other related technologies). But I don't th=
ink that the Web is ready for that approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in SCI=
M brings at last as many problems as would be created by introducing a new =
SCIM schema.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com




From Chris.Phillips@canarie.ca  Tue Apr 24 21:22: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 0830C21E8012 for ; Tue, 24 Apr 2012 21:22:08 -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 vk06qDMIhNWL for ; Tue, 24 Apr 2012 21:22:06 -0700 (PDT)
Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3AB11E8074 for ; Tue, 24 Apr 2012 21:22:06 -0700 (PDT)
Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Wed, 25 Apr 2012 00:22:05 -0400
From: Chris Phillips 
To: "scim@ietf.org" 
Date: Wed, 25 Apr 2012 00:21:59 -0400
Thread-Topic: About SCIM Schema,  was ->Re: [scim] SCIM Issues
Thread-Index: Ac0imvf3V+qTYGAoSaOO/fm16h4nxw==
Message-ID: 
In-Reply-To: <1335302890.96236.YahooMailNeo@web31816.mail.mud.yahoo.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_CBBCE32599C03chrisphillipscanarieca_"
MIME-Version: 1.0
Subject: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 25 Apr 2012 04:22:08 -0000

--_000_CBBCE32599C03chrisphillipscanarieca_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Regarding schema:

I appreciate the scrutiny that schema is getting as it is a complex area.  =
I would like to call out the backward compatibility element in the proposed=
 charter[1] though:

"..These drafts are based on existing specifications, which together are co=
mmonly known as SCIM 1.0. As such, some consideration should be given for b=
ackward compatibility as the group evolves the work. This group will consid=
er, the operational experience gathered from the existing work, as well as =
experiences with work done by other bodies, including the OASIS Provisionin=
g TC"

I would find it very difficult to preserve back compatibility with signific=
ant alterations to the schema, extensions excepted of course.

Emmanuel, to your comment on not using any schema at all, it sounds like mo=
st of your needs would be served in using schema extension and capturing yo=
u items there.

William, there are many schemas out there, just not agreement around them. =
Rather than not have a schema at all, SCIM chose one and enhanced it with s=
chema extensions allowing for flexibility for data elements yet to be thoug=
ht of to keep it evergreen. The real challenge is maintaining the fidelity =
between what SCIM can maintain in the core and what the target in question =
can receive (e.g. SCIM-> LDAP ).  There are always going to be concessions =
made between schemas that are not the same so some fidelity may be lost in =
the process translating from SCIM to a target.

Stephen, count me and the federation communities observing this spec activi=
ty as concerned regarding schema change.

Chris.


[1] http://www.ietf.org/mail-archive/web/scim/current/msg00185.html

From: William Mills >
Reply-To: William Mills >
Date: Tue, 24 Apr 2012 17:28:10 -0400
To: Stephen Farrell >, Radovan Semancik >
Cc: "scim@ietf.org" >
Subject: Re: [scim] SCIM Issues

As an observer, developing a new schema is a big thing.  It would really be=
 surprising to me if there isn't something out there that already does most=
 of what's needed.  Extending something like that seems a better solution t=
han defining a completely new one from the ground up.

-bill

________________________________
From: Stephen Farrell >
To: Radovan Semancik >
Cc: "scim@ietf.org" >
Sent: Tuesday, April 24, 2012 2:21 PM
Subject: Re: [scim] SCIM Issues


So plenty of reasons to cringe if thinking of using
inetOrgPerson, and I think you're probably right in
your text below about those.

But still no reason why it could not work.

FWIW, on the basis that I would expect as many
cringeworthy things in a new schema, some of which
wouldn't be discovered for a few years, I guess
I'm not personally convinced a new one is a necessity.

Having said that, if no-one else is concerned about
this, then maybe a new schema is fine. (And no-one
else has expressed this particular concern on the
list so far that I recall.)

S


On 04/24/2012 08:15 PM, Radovan Semancik wrote:
> On 04/24/2012 05:12 PM, Stephen Farrell wrote:
>> So the other part of my question was: why do we *need*
>> to do that re-definition? What would not work if we just
>> used inetOrgPerson (or some other existing equivalent).
>> Doing the work for fun doesn't see appealing.
>
> I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe
> the motivation was similar to that of FOAF. Yet, as you have pointed
> out, new specifications bring new problems (including FOAF), especially
> if they are not tested in practice before they are standardized. Which
> is still the point that I consider to be the most serious issue with
> respect to SCIM standardization. But let's put that aside for now. Here
> is my personal list why not inetOrgPerson:
>
> uid, cn and others are multivalued. This is complicating the
> implementations. Yes, it can be "profiled" to singlevalued, but that
> will actually not be inetOrgPerson any more. The "formal" compatibility
> will be gone. SCIM implementation will still needs to deal with the
> eventuality that these attributes will be multivalued on the LDAP side.
> So there will be actually quite little benefit. And after all it is not
> difficult to implement attribute name mapping. The difficult thing is
> attribute value mapping, which cannot be avoided here. Also, did you
> know that "cn" an "commonName" is actually the same attribute? I guess
> that it is something from the X.500 legacy and is not really the best
> part of LDAP schema specs. We can profile that as well, ruling out
> "commonName" and similar long attribute names. But real good
> SCIM-to-LDAP implementation must be aware of that anyway. So the mapping
> will not be considerably simpler.
>
> There is cn and displayName. The displayName is there for the purpose
> that cn is multivalued and it is difficult to display. We do not want a
> separate attribute just to fix ages old problem. We can again profile
> this. But ... well, see above.
>
>
> Address is scattered across street, l, postOfficeBox, postalCode, and
> other attributes. Yes, there is a postalAddress attribute, but it
> actually duplicates the information. Even that can be profiled ... but ..=
.
>
> There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and
> homePhone (all of them multi-valued). No way to specify work phone or
> mark which of the phone numbers is "primary" (except for copying that
> value to telephoneNumber). For email there is just one attribute (also
> multi-valued) and also no way how to mark primary address.
>
> There are at least two frequently used an incompatible grouping
> mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some
> applications works with the former, some with the later. Which one to
> choose? We don't want both of them. But whatever we choose, the
> SCIM-to-LDAP code will most likely still need to support both. Both
> groupOfNames and groupOfUniqueNames contain a list of members as DNs. We
> don't want to use DNs in SCIM, so this needs to be mapped to other
> identifiers anyway (more mapping code). As listing the members of large
> groups is inefficient and cumbersome to manage, most vendors of good
> directory servers provide their own grouping mechanisms (dynamic groups,
> roles). Which means even more mapping code in the usual case.
>
> OIDs: People that use LDAP daily and have never needed to create their
> own schema usually don't know what OIDs are good for, some of them
> probably don't know that OIDs even exist. Vast majority of LDAP code
> does not work with OIDs but with attribute and object class names. If
> SCIM would chose inetOrgPerson and still wants to maintain good
> extensibility, it MUST NOT use attribute names. It should use OIDs.
> Attribute names may collide. It is not a problem in LDAP, as LDAP is
> usually deployed in closed environment and not exposed to the Internet.
> Collisions are easy to handle in closed environments. The inetOrgPerson
> schema is also not really evolving, so the probability of collision with
> future version of inetOrgPerson is close to zero. But SCIM schema must
> be able to evolve. So OIDs are probably the only
> inetOrgPerson-compatible choice here. And I can't believe that something
> like the following example would ever be widely adopted (although I can
> see a lot of benefits going this way, we don't want SCIM to end up as
> SPML and DSML, do we?):
>
> {
>  "urn:oid:0.9.2342.19200300.100.1.1": "jack",
>  "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
>  ....
> }
>
> If this would be what we want then the best choice would probably be to
> stay with ASN.1. It has a solid schema language and it is one the most
> efficient data representation languages that we know. Formats based on
> ASN.1 are also well extensible. And that means that we do not really
> need another provisioning language at all! We can reuse LDAP. But ASN.1
> is quite difficult to work with. The scripting folk would hate it.
> Dealing with all the problems of JSON and XML is probably the lesser
> evil here. But what would that mean is actually re-creating ASN.1/LDAP
> in JSON and XML. I don't think we want that. DSML was something like
> that and it was not a huge success. And actually, it is probably not
> correct to fix protocol to just one URI scheme. Therefore SCIM should
> allow also other URIs for attribute names. In which case the
> SCIM-to-LDAP code will have really hard time to translate generic URIs
> to OIDs.
>
> I guess there are much more issues that I have missed. It looks like
> taking a schema designed for one technology and trying to reuse it "as
> is" for another technology may not be the best idea. I don't try to
> suggest that LDAP is bad. I quite believe the contrary. Some things
> shows its age and the marks of evolution, but overall it is not bad. But
> it is quite incompatible with the principles of the Web. I like LDAP a
> lot and I appreciate the engineering behind it (and ASN.1 and other
> related technologies). But I don't think that the Web is ready for that
> approach yet.
>
> I'm not here to judge, but it looks to me that reusing inetOrgPerson in
> SCIM brings at last as many problems as would be created by introducing
> a new SCIM schema.
>
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--_000_CBBCE32599C03chrisphillipscanarieca_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Regarding schema:
<=
div>
I appreciate the scrutiny that schema is getting as it i=
s a complex area.  I would like to call out the backward compatibility=
 element in the proposed charter[1] though:

"..These drafts are based on existing specifications, which toget=
her are commonly known as SCIM 1.0.  As such, some c=
onsideration should be given for backward compatibil=
ity as the group evolves the work.  This group will consider, the operational experience gathered from the existing work, as we=
ll as experiences with work done by other bodies, in=
cluding the OASIS Provisioning TC"
I =
would find it very difficult to preserve back compatibility with significan=
t alterations to the schema, extensions excepted of course.
Emmanue=
l, to your comment on not using any schema at all, it sounds like most of y=
our needs would be served in using schema extension and capturing you items=
 there.
William, there are many schemas out there, just not agreeme=
nt around them. Rather than not have a schema at all, SCIM chose one a=
nd enhanced it with schema extensions allowing for flexibility for data ele=
ments yet to be thought of to keep it evergreen. The real challenge is=
 maintaining the fidelity between what SCIM can maintain in the core and wh=
at the target in question can receive (e.g. SCIM-> LDAP ).  There are al=
ways going to be concessions made between schemas that are not the same so =
some fidelity may be lost in the process translating from SCIM to a target.=
 
Stephen, count me and the federation communities observing this s=
pec activity as concerned regarding schema change.
Chris.
<=
br>

=
From:  William Mills <wmi=
lls@yahoo-inc.com>
Reply-To:  William Mills <wmills@yahoo=
-inc.com>
Date:  Tue, 24 =
Apr 2012 17:28:10 -0400
To:  Ste=
phen Farrell <stephen.farre=
ll@cs.tcd.ie>, Radovan Semancik <radovan.semancik@evolveum.com>
Cc:  "scim@ietf.org=
" <scim@ietf.org>
Subject:  Re: [scim] SCIM Issues
=


As an observer, developing a new schema is a big thing. =
; It would really be surprising to me if there isn't something out there th=
at already does most of what's needed.  Extending something like that =
seems a better solution than defining a completely new one from the ground =
up.

-bill

  
 
 
  
  From: Stephen Farr=
ell
 <stephen.farrell@cs.tcd.ie=
>
 To: Radovan S=
emancik <radovan.semanc=
ik@evolveum.com> 
Cc: "scim@ietf.org" <scim@ietf.org> 
 Sent: Tuesday, April 24, 2012 2:21 PM
 Subject: Re: [scim] SCIM Issues
 <=
/font> 
 

So plenty of reasons to cringe if thinking of usinginetOrgPerson, and I think you're probably right in
your text below ab=
out those.

But still no reason why it could not work.

FWIW, o=
n the basis that I would expect as many
cringeworthy things in a new sch=
ema, some of which
wouldn't be discovered for a few years, I guess
I'=
m not personally convinced a new one is a necessity.

Having said tha=
t, if no-one else is concerned about
this, then maybe a new schema is fi=
ne. (And no-one
else has
 expressed this particular concern on the
list so far that I recall.)
S


On 04/24/2012 08:15 PM, Radovan Semancik wrote:
> O=
n 04/24/2012 05:12 PM, Stephen Farrell wrote:
>> So the other part=
 of my question was: why do we *need*
>> to do that re-definition?=
 What would not work if we just
>> used inetOrgPerson (or some oth=
er existing equivalent).
>> Doing the work for fun doesn't see app=
ealing.
> 
> I'm not sure why authors of SCIM chosen not to use=
 inetOrgPerson. Maybe
> the motivation was similar to that of FOAF. Y=
et, as you have pointed
> out, new specifications bring new problems =
(including FOAF), especially
> if they are not tested in practice bef=
ore they are standardized. Which
> is still the point that I consider=
 to be the most serious issue with
> respect to SCIM standardization.=
 But let's put that aside for now. Here
> is my personal list
 why not inetOrgPerson:
> 
> uid, cn and others are multivalued=
. This is complicating the
> implementations. Yes, it can be "profile=
d" to singlevalued, but that
> will actually not be inetOrgPerson any=
 more. The "formal" compatibility
> will be gone. SCIM implementation=
 will still needs to deal with the
> eventuality that these attribute=
s will be multivalued on the LDAP side.
> So there will be actually q=
uite little benefit. And after all it is not
> difficult to implement=
 attribute name mapping. The difficult thing is
> attribute value map=
ping, which cannot be avoided here. Also, did you
> know that "cn" an=
 "commonName" is actually the same attribute? I guess
> that it is so=
mething from the X.500 legacy and is not really the best
> part of LD=
AP schema specs. We can profile that as well, ruling out
> "commonNam=
e" and similar long attribute names. But real good
>
 SCIM-to-LDAP implementation must be aware of that anyway. So the mapping> will not be considerably simpler.
> 
> There is cn and d=
isplayName. The displayName is there for the purpose
> that cn is mul=
tivalued and it is difficult to display. We do not want a
> separate =
attribute just to fix ages old problem. We can again profile
> this. =
But ... well, see above.
> 
> 
> Address is scattered acr=
oss street, l, postOfficeBox, postalCode, and
> other attributes. Yes=
, there is a postalAddress attribute, but it
> actually duplicates th=
e information. Even that can be profiled ... but ...
> 
> There=
 is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and
> homeP=
hone (all of them multi-valued). No way to specify work phone or
> ma=
rk which of the phone numbers is "primary" (except for copying that
>=
 value to telephoneNumber). For email there is just one attribute
 (also
> multi-valued) and also no way how to mark primary address.> 
> There are at least two frequently used an incompatible grou=
ping
> mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some<=
br>> applications works with the former, some with the later. Which one =
to
> choose? We don't want both of them. But whatever we choose, the<=
br>> SCIM-to-LDAP code will most likely still need to support both. Both=

> groupOfNames and groupOfUniqueNames contain a list of members as D=
Ns. We
> don't want to use DNs in SCIM, so this needs to be mapped to=
 other
> identifiers anyway (more mapping code). As listing the membe=
rs of large
> groups is inefficient and cumbersome to manage, most ve=
ndors of good
> directory servers provide their own grouping mechanis=
ms (dynamic groups,
> roles). Which means even more mapping code in t=
he usual case.
> 
> OIDs: People that use LDAP daily and
 have never needed to create their
> own schema usually don't know wh=
at OIDs are good for, some of them
> probably don't know that OIDs ev=
en exist. Vast majority of LDAP code
> does not work with OIDs but wi=
th attribute and object class names. If
> SCIM would chose inetOrgPer=
son and still wants to maintain good
> extensibility, it MUST NOT use=
 attribute names. It should use OIDs.
> Attribute names may collide. =
It is not a problem in LDAP, as LDAP is
> usually deployed in closed =
environment and not exposed to the Internet.
> Collisions are easy to=
 handle in closed environments. The inetOrgPerson
> schema is also no=
t really evolving, so the probability of collision with
> future vers=
ion of inetOrgPerson is close to zero. But SCIM schema must
> be able=
 to evolve. So OIDs are probably the only
> inetOrgPerson-compatible =
choice here. And I can't believe that something
> like the
 following example would ever be widely adopted (although I can
> see=
 a lot of benefits going this way, we don't want SCIM to end up as
> =
SPML and DSML, do we?):
> 
> {
>   "urn:oid:0.9.2342=
.19200300.100.1.1": "jack",
>   "urn:oid:2.5.4.3": "cpt. Jack Sp=
arrow",
>   ....
> }
> 
> If this would be wha=
t we want then the best choice would probably be to
> stay with ASN.1=
. It has a solid schema language and it is one the most
> efficient d=
ata representation languages that we know. Formats based on
> ASN.1 a=
re also well extensible. And that means that we do not really
> need =
another provisioning language at all! We can reuse LDAP. But ASN.1
> =
is quite difficult to work with. The scripting folk would hate it.
> =
Dealing with all the problems of JSON and XML is probably the lesser
>=
; evil here. But what would that mean is actually re-creating
 ASN.1/LDAP
> in JSON and XML. I don't think we want that. DSML was s=
omething like
> that and it was not a huge success. And actually, it =
is probably not
> correct to fix protocol to just one URI scheme. The=
refore SCIM should
> allow also other URIs for attribute names. In wh=
ich case the
> SCIM-to-LDAP code will have really hard time to transl=
ate generic URIs
> to OIDs.
> 
> I guess there are much m=
ore issues that I have missed. It looks like
> taking a schema design=
ed for one technology and trying to reuse it "as
> is" for another te=
chnology may not be the best idea. I don't try to
> suggest that LDAP=
 is bad. I quite believe the contrary. Some things
> shows its age an=
d the marks of evolution, but overall it is not bad. But
> it is quit=
e incompatible with the principles of the Web. I like LDAP a
> lot an=
d I appreciate the engineering behind it (and ASN.1 and
 other
> related technologies). But I don't think that the Web is rea=
dy for that
> approach yet.
> 
> I'm not here to judge, b=
ut it looks to me that reusing inetOrgPerson in
> SCIM brings at last=
 as many problems as would be created by introducing
> a new SCIM sch=
ema.
> 
_______________________________________________
scim ma=
iling list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
<=
br>
 
 
 
   


--_000_CBBCE32599C03chrisphillipscanarieca_--

From melinda.shore@gmail.com  Tue Apr 24 21: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 5D99321F8661 for ; Tue, 24 Apr 2012 21:52: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 zNWN718dI8Dn for ; Tue, 24 Apr 2012 21:52:24 -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 69F5921F8665 for ; Tue, 24 Apr 2012 21:52:23 -0700 (PDT)
Received: by pbbrp16 with SMTP id rp16so979868pbb.31 for ; Tue, 24 Apr 2012 21:52:23 -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=BIqf918uo87mw3y+qS/RriEF06uMXY4BGhVo9L+qSmQ=; b=NaqRXrPUsR6/d/xvcnrdPyQieTzEPul1aHqlrZ+5439uMmyDF7sgm5LtHQSGF2/zoC oYvctrPIrDf1EJ515oMX0Y2M84/Hhu+E6MtHcK1h0svHQdCugA4WKjbz5qB0GKRsPnVn NUV9KinWPNWYvXPcTxKWY1r2hyzfrs3ZSiI8DQO2AL/YkgvWgmY/DrBKe1X6ATFzl15R +S1CV4/ZVXFF5tGGW2IPDOU53+8fMlko4/KxfLrakkXdMuyrHhitRatYfXjflelhMSQI 2tAoR/sbgqYwxGZXsSDX+uBXzNvUlxn8WUkP9HUJlAuFqLxP2falFYbHyJ+d+gZ/XQbs O8ZA==
Received: by 10.68.195.38 with SMTP id ib6mr4492466pbc.28.1335329543127; Tue, 24 Apr 2012 21:52:23 -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 pu7sm1554609pbb.9.2012.04.24.21.52.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 21:52:22 -0700 (PDT)
Message-ID: <4F978304.4050005@gmail.com>
Date: Tue, 24 Apr 2012 20:52:20 -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] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 25 Apr 2012 04:52:31 -0000

On 4/24/12 8:21 PM, Chris Phillips wrote:
> I would find it very difficult to preserve back compatibility with
> significant alterations to the schema, extensions excepted of
> course.

To be honest I find the notion of maintaining backward
compatibility with a schema that didn't maintain backward
compatibility (with inetOrgPerson, which is pretty much
everywhere) far less compelling than arguments about the
technical difficulties.  I think we could probably punt
on the embedded OIDs (although I'm not certain that we
could) but the multi-valued stuff seems like a problem.

Also, and with all due respect to, like, everybody, I always
find discussions about messages and message contents a lot
more productive than discussions about data representation,
and I've never fully understood why it's inevitably the
first place working groups want to go when undertaking a
new standardization effort.  Seems to me that it ought to be
the least interesting aspect, or at least close to the
least interesting.  I don't think that anything that's been
tossed out, up to and including ASN.1, is insufficiently
rich to be able to represent what's under discussion.

Melinda

From radovan.semancik@evolveum.com  Wed Apr 25 01:48: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 2F97621F84B5 for ; Wed, 25 Apr 2012 01:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level: 
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 T7eYZYowHB2b for ; Wed, 25 Apr 2012 01:48:03 -0700 (PDT)
Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id B69A421F8713 for ; Wed, 25 Apr 2012 01:48:02 -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 CEB93A43ED3 for ; Wed, 25 Apr 2012 10:47:59 +0200 (CEST)
Message-ID: <4F97BA3F.7040706@evolveum.com>
Date: Wed, 25 Apr 2012 10:47:59 +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:  <4F978304.4050005@gmail.com>
In-Reply-To: <4F978304.4050005@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 25 Apr 2012 08:48:04 -0000

I don't think this discussion is about data representation. Even though 
some representation mechanisms were mentioned, the core of the argument 
is data model (or meta-model if you like), extensibility mechanisms and 
compatibility.

This is very important to me and I would guess that also to the overall 
usability of SCIM.

If SCIM does not have a schema then it is almost useless. It is as 
simple as that. Anyone that ever build any provisioning 
connector/adapter will know that implementing the "protocol" is the 
simplest part. I mean implementing REST, web service, XML, JSON or 
similar layers. There are libraries for that and this part of code can 
actually work in few hours. The problem lies within the data: What 
attributes account has? What are the identifiers? Which attributes are 
mandatory to create an account? What is the type of individual 
attributes? How are times and dates represented? (and in what timezone) 
Are the values single or multivalued? How are national characters 
represented? May identifiers contain national characters? May 
identifiers change? How do we do renames? How is the account enabled and 
disabled? How are accounts assigned to groups? How are other 
entitlements assigned? Implementing and especially testing this takes 
most of the time. If SCIM cannot help to resolve this then it has very 
little real value. It would be approximately the same effort to write a 
custom adapter/connector as to customize and configure real-world SCIM 
connection. Maybe the custom way may be even more attractive as it will 
not be limited by SCIM specifications.

If SCIM is not backwards compatible, it probably won't be worth 
implementing at all. At least in the early stages. I think that 
everybody is aware that it is unlikely that a perfect schema will be 
created in early versions of SCIM. Then what is the point of 
implementing such early versions if we know that the schema is bad and 
we also know that we will need to throw out significant part of the code 
and configuration when a new SCIM version comes? And even worse: we 
would need to maintain several SCIM versions working at the same time to 
allow clients to migrate. Most people will actually wait for next 
versions of SCIM and do not implement the early versions (I assume 
reasonable thinking here, not a hype). If that is true, then there is a 
serious adoption problem.

I strongly believe that small, solid, extensible and backwards 
compatible schema is a critical part of SCIM specification. I would say 
it is much more important than the "protocol" part. I can't see how 
could SCIM be successful without that.

But in fact Melinda is right: talking about this should not be a 
(significant) part of standardization effort. However, this is protocol 
(and schema) development, not standardization. And that's the problem.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com



On 04/25/2012 06:52 AM, Melinda Shore wrote:
> On 4/24/12 8:21 PM, Chris Phillips wrote:
>> I would find it very difficult to preserve back compatibility with
>> significant alterations to the schema, extensions excepted of
>> course.
>
> To be honest I find the notion of maintaining backward
> compatibility with a schema that didn't maintain backward
> compatibility (with inetOrgPerson, which is pretty much
> everywhere) far less compelling than arguments about the
> technical difficulties.  I think we could probably punt
> on the embedded OIDs (although I'm not certain that we
> could) but the multi-valued stuff seems like a problem.
>
> Also, and with all due respect to, like, everybody, I always
> find discussions about messages and message contents a lot
> more productive than discussions about data representation,
> and I've never fully understood why it's inevitably the
> first place working groups want to go when undertaking a
> new standardization effort.  Seems to me that it ought to be
> the least interesting aspect, or at least close to the
> least interesting.  I don't think that anything that's been
> tossed out, up to and including ASN.1, is insufficiently
> rich to be able to represent what's under discussion.
>
> Melinda
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim



From wmills@yahoo-inc.com  Wed Apr 25 07:49: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 8A12D21F8716 for ; Wed, 25 Apr 2012 07:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.197
X-Spam-Level: 
X-Spam-Status: No, score=-17.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, 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 d0esgElHM48g for ; Wed, 25 Apr 2012 07:49:23 -0700 (PDT)
Received: from nm2.bullet.mail.ac4.yahoo.com (nm2.bullet.mail.ac4.yahoo.com [98.139.52.199]) by ietfa.amsl.com (Postfix) with SMTP id 81AC121F8713 for ; Wed, 25 Apr 2012 07:49:23 -0700 (PDT)
Received: from [98.139.52.189] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 25 Apr 2012 14:49:19 -0000
Received: from [98.139.52.154] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 25 Apr 2012 14:49:19 -0000
Received: from [127.0.0.1] by omp1037.mail.ac4.yahoo.com with NNFMP; 25 Apr 2012 14:49:19 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 883959.97872.bm@omp1037.mail.ac4.yahoo.com
Received: (qmail 15729 invoked by uid 60001); 25 Apr 2012 14:49:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1335365359; bh=fuRTtlO3gxSvsWtq2re3D8mrZNZTXw7Lw9xHP0pIzkM=; 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:Content-Transfer-Encoding; b=E/ISGWo+mnGAvG/oKKVRsgbOgqxlwjA30VhmKRtJiO8GBdRynvo+jxQsqsIiYIpShLwTNZ2yqF29mB+KsGNxpjbvjUovfLA16In+EuzZkBOTfJwaUCoQNiHs+FIPqNz7TwJdFs+3Q0fsxCP9NexMu0LMLB9of682GiLa4hp3qRU=
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:Content-Transfer-Encoding; b=Xt9bxmCWrm/CgzbMkH+QDB1ZM3iXHzug5fCTZYLh2uNgy/STJ5RG4wJ1rBAEHwJYFg546SeOdv2/335L5aWcmmJbmHqPW+OQEV2xpHQPbEdXzl4WYiqEklBuAK9LyTsuY69D9dQsEHjI470CgdOWThZ9Gx8oIICgHr42zLOtl1k=;
X-YMail-OSG: wmCTXpUVM1ndO5521qMsOZ_MXeoMab83L3cOTHCsaMeOTly w9sjMS_HOrZUNHWiS.Uqqlh1JWsOyOuB.bkBI_7l6iepjr_MFI60kbSGecE5 X7G7PWGEHjsQG2uxT6lu5YGU5N1fiuW1edmk8f6xzGSSLvo2dix2WcGWHlXC kkSmOq.A_CaociuINt7Hpd3XEeO_ESjuHxn8NQD.D9okllpHccdtuQhshXZU retLeIDPfe6449CB2V3qKjBMpWCw1_N9kGwVcMlCIzJBXCGsn08TMI6pLZqL LGnI2g9HSg5ZwJ04T.1Oyb3j7zd.C4ZMqYFHOP0iEveafN89_hOeN1ZzOajE XSHkeQ07Jz6GXAagAtv.hbmBv.IlelifClbHEOum8ptlLK7ihqfKfaNpLArp jo.Eyc_Vv.2_n6cudWV027H3XQFpkkO4g7GsqbDf2ZQQOJDPzMQ0ggje89xN 91iMSw8QmRwKjFvQLUf9zjQsOEnjDagpCk5H6ho.Xt8XZW.dWkp.hDPuWwL3 J3T0Ml_2NCmYW2fTNOALKk6N3.reRhvgn893k
Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Wed, 25 Apr 2012 07:49:18 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1335302890.96236.YahooMailNeo@web31816.mail.mud.yahoo.com> 
Message-ID: <1335365358.6497.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Wed, 25 Apr 2012 07:49:18 -0700 (PDT)
From: William Mills 
To: Chris Phillips , "scim@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
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: Wed, 25 Apr 2012 14:49:25 -0000

=0A=0A=0A=0A=0A>________________________________=0A> From: Chris Phillips <=
Chris.Phillips@canarie.ca>=0A>To: "scim@ietf.org"  =0A>Sent:=
 Tuesday, April 24, 2012 9:21 PM=0A>Subject: [scim] About SCIM Schema,=A0=
=A0was ->Re:=A0=A0SCIM Issues=0A> =0A>=0A>Regarding schema:=0A>=0A>=0A>I ap=
preciate the scrutiny that schema is getting as it is a complex area. =A0I =
would like to call out the backward compatibility element in the proposed c=
harter[1] though:=0A>=0A>=0A>"..These drafts are based on existing specific=
ations, which together are commonly known as SCIM 1.0.=A0=A0As such, some c=
onsideration should be given for backward compatibility as the group evolve=
s the work.=A0=A0This group will consider, the operational experience gathe=
red from the existing work, as well as experiences with work done by other =
bodies, including the OASIS Provisioning TC"=0A>I would find it very diffic=
ult to preserve back compatibility with significant alterations to the sche=
ma, extensions excepted of course.=0A>Emmanuel, to your comment on not usin=
g any schema at all, it sounds like most of your needs would be served in u=
sing schema extension and capturing you items there.=0A>William, there are =
many schemas out there, just not agreement around them.=A0Rather than not h=
ave a schema at all, SCIM chose one and enhanced it with schema extensions =
allowing for flexibility for data elements yet to be thought of to keep it =
evergreen.=A0The real challenge is maintaining the fidelity between what SC=
IM can maintain in the core and what the target in question can receive (e.=
g. SCIM-> LDAP ).=A0=A0There are always going to be concessions made betwee=
n schemas that are not the same so some fidelity may be lost in the process=
 translating from SCIM to a target. =0A=0A=0AThat's sure not what the discu=
ssion sounds like, there's been a lot of discussion around defining names e=
tc. That really appears to be around defining an entirely new schema for pe=
ople.=A0 Rather than that I'd suggest figuring out the rest of the structur=
e like groups, atom identity, ownership and such and then include an object=
 that has it's own schema like an LDAP person or something form Dublin Core=
.=0A=0A=0A>Stephen, count me and the federation communities observing this =
spec activity as concerned regarding schema change.=0A>Chris.=0A>=0A>=0A>[1=
]=A0http://www.ietf.org/mail-archive/web/scim/current/msg00185.html=0A>=0A>=
From:=A0=A0William Mills =0A>Reply-To:=A0=A0William M=
ills =0A>Date:=A0=A0Tue, 24 Apr 2012 17:28:10 -0400=
=0A>To:=A0=A0Stephen Farrell , Radovan Semancik =
=0A>Cc:=A0=A0"scim@ietf.org" =
=0A>Subject:=A0=A0Re: [scim] SCIM Issues=0A>=0A>=0A>=0A>As an observer, dev=
eloping a new schema is a big thing.=A0 It would really be surprising to me=
 if there isn't something out there that already does most of what's needed=
.=A0 Extending something like that seems a better solution than defining a =
completely new one from the ground up.=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>=0A>=
>________________________________=0A>> From: Stephen Farrell =0A>>To: Radovan Semancik  =0A>=
>Cc: "scim@ietf.org"  =0A>>Sent: Tuesday, April 24, 2012 2:2=
1 PM=0A>>Subject: Re: [scim] SCIM Issues=0A>> =0A>>=0A>>So plenty of reason=
s to cringe if thinking of using=0A>>inetOrgPerson, and I think you're prob=
ably right in=0A>>your text below about those.=0A>>=0A>>But still no reason=
 why it could not work.=0A>>=0A>>FWIW, on the basis that I would expect as =
many=0A>>cringeworthy things in a new schema, some of which=0A>>wouldn't be=
 discovered for a few years, I guess=0A>>I'm not personally convinced a new=
 one is a necessity.=0A>>=0A>>Having said that, if no-one else is concerned=
 about=0A>>this, then maybe a new schema is fine. (And no-one=0A>>else has=
=0Aexpressed this particular concern on the=0A>>list so far that I recall.)=
=0A>>=0A>>S=0A>>=0A>>=0A>>On 04/24/2012 08:15 PM, Radovan Semancik wrote:=
=0A>>> On 04/24/2012 05:12 PM, Stephen Farrell wrote:=0A>>>> So the other p=
art of my question was: why do we *need*=0A>>>> to do that re-definition? W=
hat would not work if we just=0A>>>> used inetOrgPerson (or some other exis=
ting equivalent).=0A>>>> Doing the work for fun doesn't see appealing.=0A>>=
> =0A>>> I'm not sure why authors of SCIM chosen not to use inetOrgPerson. =
Maybe=0A>>> the motivation was similar to that of FOAF. Yet, as you have po=
inted=0A>>> out, new specifications bring new problems (including FOAF), es=
pecially=0A>>> if they are not tested in practice before they are standardi=
zed. Which=0A>>> is still the point that I consider to be the most serious =
issue with=0A>>> respect to SCIM standardization. But let's put that aside =
for now. Here=0A>>> is my personal list=0Awhy not inetOrgPerson:=0A>>> =0A>=
>> uid, cn and others are multivalued. This is complicating the=0A>>> imple=
mentations. Yes, it can be "profiled" to singlevalued, but that=0A>>> will =
actually not be inetOrgPerson any more. The "formal" compatibility=0A>>> wi=
ll be gone. SCIM implementation will still needs to deal with the=0A>>> eve=
ntuality that these attributes will be multivalued on the LDAP side.=0A>>> =
So there will be actually quite little benefit. And after all it is not=0A>=
>> difficult to implement attribute name mapping. The difficult thing is=0A=
>>> attribute value mapping, which cannot be avoided here. Also, did you=0A=
>>> know that "cn" an "commonName" is actually the same attribute? I guess=
=0A>>> that it is something from the X.500 legacy and is not really the bes=
t=0A>>> part of LDAP schema specs. We can profile that as well, ruling out=
=0A>>> "commonName" and similar long attribute names. But real good=0A>>>=
=0ASCIM-to-LDAP implementation must be aware of that anyway. So the mapping=
=0A>>> will not be considerably simpler.=0A>>> =0A>>> There is cn and displ=
ayName. The displayName is there for the purpose=0A>>> that cn is multivalu=
ed and it is difficult to display. We do not want a=0A>>> separate attribut=
e just to fix ages old problem. We can again profile=0A>>> this. But ... we=
ll, see above.=0A>>> =0A>>> =0A>>> Address is scattered across street, l, p=
ostOfficeBox, postalCode, and=0A>>> other attributes. Yes, there is a posta=
lAddress attribute, but it=0A>>> actually duplicates the information. Even =
that can be profiled ... but ...=0A>>> =0A>>> There is telephoneNumber, mob=
ile (a.k.a mobileTelephoneNumber) and=0A>>> homePhone (all of them multi-va=
lued). No way to specify work phone or=0A>>> mark which of the phone number=
s is "primary" (except for copying that=0A>>> value to telephoneNumber). Fo=
r email there is just one attribute=0A(also=0A>>> multi-valued) and also no=
 way how to mark primary address.=0A>>> =0A>>> There are at least two frequ=
ently used an incompatible grouping=0A>>> mechanisms in LDAP: groupOfNames =
and groupOfUniqueNames. Some=0A>>> applications works with the former, some=
 with the later. Which one to=0A>>> choose? We don't want both of them. But=
 whatever we choose, the=0A>>> SCIM-to-LDAP code will most likely still nee=
d to support both. Both=0A>>> groupOfNames and groupOfUniqueNames contain a=
 list of members as DNs. We=0A>>> don't want to use DNs in SCIM, so this ne=
eds to be mapped to other=0A>>> identifiers anyway (more mapping code). As =
listing the members of large=0A>>> groups is inefficient and cumbersome to =
manage, most vendors of good=0A>>> directory servers provide their own grou=
ping mechanisms (dynamic groups,=0A>>> roles). Which means even more mappin=
g code in the usual case.=0A>>> =0A>>> OIDs: People that use LDAP daily and=
=0Ahave never needed to create their=0A>>> own schema usually don't know wh=
at OIDs are good for, some of them=0A>>> probably don't know that OIDs even=
 exist. Vast majority of LDAP code=0A>>> does not work with OIDs but with a=
ttribute and object class names. If=0A>>> SCIM would chose inetOrgPerson an=
d still wants to maintain good=0A>>> extensibility, it MUST NOT use attribu=
te names. It should use OIDs.=0A>>> Attribute names may collide. It is not =
a problem in LDAP, as LDAP is=0A>>> usually deployed in closed environment =
and not exposed to the Internet.=0A>>> Collisions are easy to handle in clo=
sed environments. The inetOrgPerson=0A>>> schema is also not really evolvin=
g, so the probability of collision with=0A>>> future version of inetOrgPers=
on is close to zero. But SCIM schema must=0A>>> be able to evolve. So OIDs =
are probably the only=0A>>> inetOrgPerson-compatible choice here. And I can=
't believe that something=0A>>> like the=0Afollowing example would ever be =
widely adopted (although I can=0A>>> see a lot of benefits going this way, =
we don't want SCIM to end up as=0A>>> SPML and DSML, do we?):=0A>>> =0A>>> =
{=0A>>>=A0=A0=A0"urn:oid:0.9.2342.19200300.100.1.1": "jack",=0A>>>=A0=A0=A0=
"urn:oid:2.5.4.3": "cpt. Jack Sparrow",=0A>>>=A0=A0=A0....=0A>>> }=0A>>> =
=0A>>> If this would be what we want then the best choice would probably be=
 to=0A>>> stay with ASN.1. It has a solid schema language and it is one the=
 most=0A>>> efficient data representation languages that we know. Formats b=
ased on=0A>>> ASN.1 are also well extensible. And that means that we do not=
 really=0A>>> need another provisioning language at all! We can reuse LDAP.=
 But ASN.1=0A>>> is quite difficult to work with. The scripting folk would =
hate it.=0A>>> Dealing with all the problems of JSON and XML is probably th=
e lesser=0A>>> evil here. But what would that mean is actually re-creating=
=0AASN.1/LDAP=0A>>> in JSON and XML. I don't think we want that. DSML was s=
omething like=0A>>> that and it was not a huge success. And actually, it is=
 probably not=0A>>> correct to fix protocol to just one URI scheme. Therefo=
re SCIM should=0A>>> allow also other URIs for attribute names. In which ca=
se the=0A>>> SCIM-to-LDAP code will have really hard time to translate gene=
ric URIs=0A>>> to OIDs.=0A>>> =0A>>> I guess there are much more issues tha=
t I have missed. It looks like=0A>>> taking a schema designed for one techn=
ology and trying to reuse it "as=0A>>> is" for another technology may not b=
e the best idea. I don't try to=0A>>> suggest that LDAP is bad. I quite bel=
ieve the contrary. Some things=0A>>> shows its age and the marks of evoluti=
on, but overall it is not bad. But=0A>>> it is quite incompatible with the =
principles of the Web. I like LDAP a=0A>>> lot and I appreciate the enginee=
ring behind it (and ASN.1 and=0Aother=0A>>> related technologies). But I do=
n't think that the Web is ready for that=0A>>> approach yet.=0A>>> =0A>>> I=
'm not here to judge, but it looks to me that reusing inetOrgPerson in=0A>>=
> SCIM brings at last as many problems as would be created by introducing=
=0A>>> a new SCIM schema.=0A>>> =0A>>______________________________________=
_________=0A>>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.org/=
mailman/listinfo/scim=0A>>=0A>>=0A>>=0A>___________________________________=
____________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/=
mailman/listinfo/scim=0A>=0A>=0A>

From kelly.grizzle@sailpoint.com  Wed Apr 25 14:33: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 B863011E808E for ; Wed, 25 Apr 2012 14:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.007
X-Spam-Level: 
X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 k8BoFQlTAZWU for ; Wed, 25 Apr 2012 14:33:55 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id F353711E8088 for ; Wed, 25 Apr 2012 14:33:25 -0700 (PDT)
Received: from mail112-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Apr 2012 21:33:24 +0000
Received: from mail112-ch1 (localhost [127.0.0.1])	by mail112-ch1-R.bigfish.com (Postfix) with ESMTP id 9E9251A0427; Wed, 25 Apr 2012 21:33:24 +0000 (UTC)
X-SpamScore: -37
X-BigFish: PS-37(zzbb2dI9371I542M1432N1418I98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail112-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=BL2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; 
Received: from mail112-ch1 (localhost.localdomain [127.0.0.1]) by mail112-ch1 (MessageSwitch) id 1335389602438975_7679; Wed, 25 Apr 2012 21:33:22 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228])	by mail112-ch1.bigfish.com (Postfix) with ESMTP id 68D923800A1;	Wed, 25 Apr 2012 21:33:22 +0000 (UTC)
Received: from BL2PRD0410HT005.namprd04.prod.outlook.com (157.56.240.85) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Apr 2012 21:33:21 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.33]) by BL2PRD0410HT005.namprd04.prod.outlook.com ([10.255.99.40]) with mapi id 14.16.0143.004; Wed, 25 Apr 2012 21:33:21 +0000
From: Kelly Grizzle 
To: Radovan Semancik , "scim@ietf.org" 
Thread-Topic: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
Thread-Index: AQHNIpr/TFvtWahJSUu03t0tZKcKApaq+S4AgABB14CAAMZnMA==
Date: Wed, 25 Apr 2012 21:33:20 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com>
References:  <4F978304.4050005@gmail.com> <4F97BA3F.7040706@evolveum.com>
In-Reply-To: <4F97BA3F.7040706@evolveum.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] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 25 Apr 2012 21:33:56 -0000

I agree with the importance of a small core schema that is extensible - SCI=
M would be DOA without one.  In fact, the current schema was designed tryin=
g to address many of the questions that you raised, and if it falls short i=
n some of these areas it needs to be addressed.

For a bit of history, the SCIM schema has its origins in Portable Contacts =
(http://portablecontacts.net/).  Other starting points were considered (inc=
luding inetOrgPerson), but ultimately PoCo was chosen because of its abilit=
y to model multi-valued complex attributes and similarity of data model.  S=
CIM steered away from inetOrgPerson because of its flat data model (eg - in=
 inetOrgPerson it is very hard to model a work email address and home email=
 address, and denote one as the primary email address), among some of the o=
ther issues that you pointed out.

> what is the point of implementing such early versions if we know that
> the schema is bad and we also know that we will need to throw out
> significant part of the code and configuration when a new SCIM version
> comes? ... If that is true, then there is a serious adoption problem.

I disagree here.  Adoption has always been a primary goal, and there are ma=
ny vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...) =
that have already committed to adopting SCIM - many of whom already have wo=
rking code.  You are absolutely right that some non-backwards compatible ch=
anges will need to be made.  The charter calls out that these should be kep=
t to a minimum, and most early adopters seem happy enough with this.

The alternative is that SaaS providers continue to write their own propriet=
ary APIs that will have the same versioning problems as SCIM.  In this worl=
d, every consumer would have to write a custom connector to every SaaS app,=
 each with a custom protocol and language around the data that they model.

The question you raise is whether a near-perfect solution should be develop=
ed in isolation before it is unleashed to the world.  The initial philosoph=
y of the SCIM community was that it is better to start the ball rolling wit=
h a wider community engaged (SaaS vendors, SaaS consumers, standards expert=
s) and work out issues by writing code and finding problems along the way. =
 Working outside of a standards body makes it nearly impossible to engage s=
uch a large community.

--Kelly

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Rad=
ovan Semancik
Sent: Wednesday, April 25, 2012 3:48 AM
To: scim@ietf.org
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

I don't think this discussion is about data representation. Even though som=
e representation mechanisms were mentioned, the core of the argument is dat=
a model (or meta-model if you like), extensibility mechanisms and compatibi=
lity.

This is very important to me and I would guess that also to the overall usa=
bility of SCIM.

If SCIM does not have a schema then it is almost useless. It is as simple a=
s that. Anyone that ever build any provisioning connector/adapter will know=
 that implementing the "protocol" is the simplest part. I mean implementing=
 REST, web service, XML, JSON or similar layers. There are libraries for th=
at and this part of code can actually work in few hours. The problem lies w=
ithin the data: What attributes account has? What are the identifiers? Whic=
h attributes are mandatory to create an account? What is the type of indivi=
dual attributes? How are times and dates represented? (and in what timezone=
) Are the values single or multivalued? How are national characters represe=
nted? May identifiers contain national characters? May identifiers change? =
How do we do renames? How is the account enabled and disabled? How are acco=
unts assigned to groups? How are other entitlements assigned? Implementing =
and especially testing this takes most of the time. If SCIM cannot help to =
resolve this then it has very little real value. It would be approximately =
the same effort to write a custom adapter/connector as to customize and con=
figure real-world SCIM connection. Maybe the custom way may be even more at=
tractive as it will not be limited by SCIM specifications.

If SCIM is not backwards compatible, it probably won't be worth implementin=
g at all. At least in the early stages. I think that everybody is aware tha=
t it is unlikely that a perfect schema will be created in early versions of=
 SCIM. Then what is the point of implementing such early versions if we kno=
w that the schema is bad and we also know that we will need to throw out si=
gnificant part of the code and configuration when a new SCIM version comes?=
 And even worse: we would need to maintain several SCIM versions working at=
 the same time to allow clients to migrate. Most people will actually wait =
for next versions of SCIM and do not implement the early versions (I assume=
 reasonable thinking here, not a hype). If that is true, then there is a se=
rious adoption problem.

I strongly believe that small, solid, extensible and backwards compatible s=
chema is a critical part of SCIM specification. I would say it is much more=
 important than the "protocol" part. I can't see how could SCIM be successf=
ul without that.

But in fact Melinda is right: talking about this should not be a
(significant) part of standardization effort. However, this is protocol (an=
d schema) development, not standardization. And that's the problem.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com



On 04/25/2012 06:52 AM, Melinda Shore wrote:
> On 4/24/12 8:21 PM, Chris Phillips wrote:
>> I would find it very difficult to preserve back compatibility with=20
>> significant alterations to the schema, extensions excepted of course.
>
> To be honest I find the notion of maintaining backward compatibility=20
> with a schema that didn't maintain backward compatibility (with=20
> inetOrgPerson, which is pretty much
> everywhere) far less compelling than arguments about the technical=20
> difficulties.  I think we could probably punt on the embedded OIDs=20
> (although I'm not certain that we
> could) but the multi-valued stuff seems like a problem.
>
> Also, and with all due respect to, like, everybody, I always find=20
> discussions about messages and message contents a lot more productive=20
> than discussions about data representation, and I've never fully=20
> understood why it's inevitably the first place working groups want to=20
> go when undertaking a new standardization effort.  Seems to me that it=20
> ought to be the least interesting aspect, or at least close to the=20
> least interesting.  I don't think that anything that's been tossed=20
> out, up to and including ASN.1, is insufficiently rich to be able to=20
> represent what's under discussion.
>
> 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 radovan.semancik@evolveum.com  Thu Apr 26 00:44: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 8E0DC21F87B6 for ; Thu, 26 Apr 2012 00:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.638
X-Spam-Level: 
X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 IybZcOvrENhR for ; Thu, 26 Apr 2012 00:44:41 -0700 (PDT)
Received: from charon.evolveum.com (charon.evolveum.com [81.89.58.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78021F87AA for ; Thu, 26 Apr 2012 00:44:40 -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 0A26DA43EA3 for ; Thu, 26 Apr 2012 09:44:38 +0200 (CEST)
Message-ID: <4F98FCE5.2000603@evolveum.com>
Date: Thu, 26 Apr 2012 09:44:37 +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: 	<4F978304.4050005@gmail.com> <4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com>
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 07:44:42 -0000

On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>> what is the point of implementing such early versions if we know that
>> the schema is bad and we also know that we will need to throw out
>> significant part of the code and configuration when a new SCIM version
>> comes? ... If that is true, then there is a serious adoption problem.
> I disagree here.  Adoption has always been a primary goal, and there are many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...) that have already committed to adopting SCIM - many of whom already have working code.  You are absolutely right that some non-backwards compatible changes will need to be made.  The charter calls out that these should be kept to a minimum, and most early adopters seem happy enough with this.

With all respect to the early adopters, I see mostly provisioning 
vendors in the interoperability tests. If SCIM should be a "cloud" 
protocols I would expect mostly cloud providers in that group as it a 
provider side of the protocol that should specify most of the 
requirements. Is there any real production-quality deployment of SCIM 
among the early adopters? What is the feedback from the early SCIM 
tests? That it works as designed? Pardon me, but that's pretty useless 
feedback in this situation.

> The alternative is that SaaS providers continue to write their own proprietary APIs that will have the same versioning problems as SCIM.  In this world, every consumer would have to write a custom connector to every SaaS app, each with a custom protocol and language around the data that they model.

My argument is that if SCIM brings the same problems as proprietary APIs 
(little compatibility, weak schema, need to "profile" every deployment) 
then SCIM does not bring enough value to justify its existence. I.e. it 
would be approximately the same effort to configure SCIM connector as to 
write a new connector for proprietary API from scratch. And 
approximately the same effort to maintain them. Maybe it is even higher 
effort to maintain SCIM connector as a change in SCIM may affect many 
systems and there may be unexpected side effects.

If SCIM brings the same problems as existing APIs and improves the 
situation just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be developed in isolation before it is unleashed to the world.  The initial philosophy of the SCIM community was that it is better to start the ball rolling with a wider community engaged (SaaS vendors, SaaS consumers, standards experts) and work out issues by writing code and finding problems along the way.  Working outside of a standards body makes it nearly impossible to engage such a large community.

I don't argue for developing a solution in isolation. Quite the 
contrary. Open development (e.g. in a form of an open source project) is 
necessary for something like SCIM. But it has to be open development not 
yet the standardization. Standardization means fixing the interface. 
Fixing the interface inevitably limits further development. And fixing 
the interface that is inappropriate for real use does not make much 
sense to me. And engineering experience shows now and again that if 
something has not been tested in real situations it is inappropriate for 
real use (with an overwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development 
version that is barely usable and then work on SCIM 2.0 which may in 
fact bring some value I'm OK with that. But it should be clearly 
indicated that SCIM 1.0 is just a development version and it is not 
suitable for real deployments.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com


From michael.brenner@alcatel-lucent.com  Thu Apr 26 05:40: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 76EBE21F8751 for ; Thu, 26 Apr 2012 05:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.299
X-Spam-Level: 
X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 hjkKdva2swlz for ; Thu, 26 Apr 2012 05:40:21 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5038521F8744 for ; Thu, 26 Apr 2012 05:40:21 -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 q3QCeHuJ022093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Apr 2012 07:40:17 -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 q3QCeHCJ027695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Apr 2012 07:40:17 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 26 Apr 2012 07:40:17 -0500
From: "Brenner, Michael Ralf (Michael)" 
To: Radovan Semancik , "scim@ietf.org" 
Date: Thu, 26 Apr 2012 07:40:15 -0500
Thread-Topic: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
Thread-Index: Ac0jgHLzs/JctrGZQgWIVyH3OUqT1QAJdMZA
Message-ID: <219947F0B2242843A0A1E62FDB510DC02510BF2F92@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  <4F978304.4050005@gmail.com>	<4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com>
In-Reply-To: <4F98FCE5.2000603@evolveum.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] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 12:40:22 -0000

Is it really useful to get hung up on labels? ("early development", "not su=
itable", etc) and on the value of standards?If a handful of companies found=
 and agreed that SCIM 1.0 to be good to implement it, in my book it beats t=
he API that each company may have implemented a separate API in isolation. =
It's a good start and SCIM 2.0 should improve on it. I don't care much whet=
her some may call it a standard or not (although I have to assume that we w=
ill call it a standard if developed in IETF, and we would ca it something e=
lse if developed as Open Source or similar), but I do care if more companie=
s find that they can adopt it than the number of companies that adopted SCI=
M 1.0.
If there are good reasons to break backward compatibility to SCIM 1.0, so b=
e it, and I expect the adopters of SCIM 1.0 can be convinced by technical a=
rguments. The value of a standard is eventual less work globally (hence at =
least small savings for most) and broader adoption (at some version-point i=
n the future, if not immediate) because of issues being found/resolved over=
 time while re-using the core functionality. It's always more acceptable to=
 a developer to re-develop ONCE every time the backward compatibility is br=
oken (not that this is a good thing), than to develop n times using a diffe=
rent proprietary mechanism ... and who can ever guarantee that proprietary =
APIs do not break backward compatibility?

Having said that, I agree with Radovan that making sure the providers' requ=
irements are understood and addressed is VERY important, much more importan=
t than either starting from SCIM 1.0, or breaking backward compatibility to=
 it. Without clear requirements, anybody can argue either side for a long t=
ime. Assuming SCIM 1.0 was implemented against a set of clear requirements,=
 and those are still the ones to pursue, then SCIM 1.0 is a good start, and=
 we should not impose any hard conditions on backward compatibility (no SHA=
LL for sure, but a rather a SHOULD if possible, or leave it open for now). =
If the assumption is incorrect, then we should be back at the drawing board=
 - draft/agree new requirements if applicable, and design from scratch agai=
nst those.

Michael

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Rad=
ovan Semancik
Sent: Thursday, April 26, 2012 3:45 AM
To: scim@ietf.org
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>> what is the point of implementing such early versions if we know that
>> the schema is bad and we also know that we will need to throw out
>> significant part of the code and configuration when a new SCIM version
>> comes? ... If that is true, then there is a serious adoption problem.
> I disagree here.  Adoption has always been a primary goal, and there are =
many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...=
) that have already committed to adopting SCIM - many of whom already have =
working code.  You are absolutely right that some non-backwards compatible =
changes will need to be made.  The charter calls out that these should be k=
ept to a minimum, and most early adopters seem happy enough with this.

With all respect to the early adopters, I see mostly provisioning=20
vendors in the interoperability tests. If SCIM should be a "cloud"=20
protocols I would expect mostly cloud providers in that group as it a=20
provider side of the protocol that should specify most of the=20
requirements. Is there any real production-quality deployment of SCIM=20
among the early adopters? What is the feedback from the early SCIM=20
tests? That it works as designed? Pardon me, but that's pretty useless=20
feedback in this situation.

> The alternative is that SaaS providers continue to write their own propri=
etary APIs that will have the same versioning problems as SCIM.  In this wo=
rld, every consumer would have to write a custom connector to every SaaS ap=
p, each with a custom protocol and language around the data that they model=
.

My argument is that if SCIM brings the same problems as proprietary APIs=20
(little compatibility, weak schema, need to "profile" every deployment)=20
then SCIM does not bring enough value to justify its existence. I.e. it=20
would be approximately the same effort to configure SCIM connector as to=20
write a new connector for proprietary API from scratch. And=20
approximately the same effort to maintain them. Maybe it is even higher=20
effort to maintain SCIM connector as a change in SCIM may affect many=20
systems and there may be unexpected side effects.

If SCIM brings the same problems as existing APIs and improves the=20
situation just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be devel=
oped in isolation before it is unleashed to the world.  The initial philoso=
phy of the SCIM community was that it is better to start the ball rolling w=
ith a wider community engaged (SaaS vendors, SaaS consumers, standards expe=
rts) and work out issues by writing code and finding problems along the way=
.  Working outside of a standards body makes it nearly impossible to engage=
 such a large community.

I don't argue for developing a solution in isolation. Quite the=20
contrary. Open development (e.g. in a form of an open source project) is=20
necessary for something like SCIM. But it has to be open development not=20
yet the standardization. Standardization means fixing the interface.=20
Fixing the interface inevitably limits further development. And fixing=20
the interface that is inappropriate for real use does not make much=20
sense to me. And engineering experience shows now and again that if=20
something has not been tested in real situations it is inappropriate for=20
real use (with an overwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development=20
version that is barely usable and then work on SCIM 2.0 which may in=20
fact bring some value I'm OK with that. But it should be clearly=20
indicated that SCIM 1.0 is just a development version and it is not=20
suitable for real deployments.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

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

From kelly.grizzle@sailpoint.com  Thu Apr 26 07:53: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 192EA21F86C6 for ; Thu, 26 Apr 2012 07:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level: 
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 FPbx9CzF-dxC for ; Thu, 26 Apr 2012 07:53:16 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8A21F86E1 for ; Thu, 26 Apr 2012 07:53:15 -0700 (PDT)
Received: from mail37-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 14:53:12 +0000
Received: from mail37-am1 (localhost [127.0.0.1])	by mail37-am1-R.bigfish.com (Postfix) with ESMTP id CB1B41E0125; Thu, 26 Apr 2012 14:53:12 +0000 (UTC)
X-SpamScore: -29
X-BigFish: PS-29(zzbb2dI9371I542M98dKzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail37-am1: 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=BL2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; 
Received: from mail37-am1 (localhost.localdomain [127.0.0.1]) by mail37-am1 (MessageSwitch) id 1335451990645518_7552; Thu, 26 Apr 2012 14:53:10 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.233])	by mail37-am1.bigfish.com (Postfix) with ESMTP id 8D26A1C008D; Thu, 26 Apr 2012 14:53:10 +0000 (UTC)
Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 14:53:09 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.33]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Thu, 26 Apr 2012 14:53:07 +0000
From: Kelly Grizzle 
To: Radovan Semancik , "scim@ietf.org" 
Thread-Topic: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
Thread-Index: AQHNIpr/TFvtWahJSUu03t0tZKcKApaq+S4AgABB14CAAMZnMIAAujmAgABgtBA=
Date: Thu, 26 Apr 2012 14:53:06 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.namprd04.prod.outlook.com>
References:  <4F978304.4050005@gmail.com>	<4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com>
In-Reply-To: <4F98FCE5.2000603@evolveum.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] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 14:53:17 -0000

I hear what you're saying and agree with you.  If SCIM does not solve real =
problems or provide real interoperability then it is a complete waste of ti=
me.  Where we differ is whether SCIM 1.0 is stable enough to use.  While it=
 is not currently in production anywhere, multiple SaaS providers and vendo=
rs have committed to supporting it by the end of the year, so the "developm=
ent version" label is not accurate.  Will it change in 2.0 in non-backwards=
-compatible ways?  Almost certainly ... but that is alright.

The primary goal of the interop events are to make sure that real use cases=
 actually work and see where the spec doesn't hold up.  So far testing has =
found both weaknesses in the spec and bugs in the implementations.  Some of=
 the spec problems are being addressed in 1.0 and some in 2.0.  See simplec=
loud.info for interop results and discussion.

> [Michael] I agree with Radovan that making sure the providers' requiremen=
ts are
> understood and addressed is VERY important, much more important than eith=
er
> starting from SCIM 1.0, or breaking backward compatibility to it.

I totally agree.  There are some documented use cases on simplecloud.info, =
but they are very high level and somewhat out of date.  Lower level use cas=
es have been used for the interop events, but these are not exhaustive and =
are light on detail.  The charter calls for a use cases document, which sho=
uld definitely be done early in the process.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Rad=
ovan Semancik
Sent: Thursday, April 26, 2012 2:45 AM
To: scim@ietf.org
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>> what is the point of implementing such early versions if we know that=20
>> the schema is bad and we also know that we will need to throw out=20
>> significant part of the code and configuration when a new SCIM=20
>> version comes? ... If that is true, then there is a serious adoption pro=
blem.
> I disagree here.  Adoption has always been a primary goal, and there are =
many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...=
) that have already committed to adopting SCIM - many of whom already have =
working code.  You are absolutely right that some non-backwards compatible =
changes will need to be made.  The charter calls out that these should be k=
ept to a minimum, and most early adopters seem happy enough with this.

With all respect to the early adopters, I see mostly provisioning vendors i=
n the interoperability tests. If SCIM should be a "cloud"=20
protocols I would expect mostly cloud providers in that group as it a provi=
der side of the protocol that should specify most of the requirements. Is t=
here any real production-quality deployment of SCIM among the early adopter=
s? What is the feedback from the early SCIM tests? That it works as designe=
d? Pardon me, but that's pretty useless feedback in this situation.

> The alternative is that SaaS providers continue to write their own propri=
etary APIs that will have the same versioning problems as SCIM.  In this wo=
rld, every consumer would have to write a custom connector to every SaaS ap=
p, each with a custom protocol and language around the data that they model=
.

My argument is that if SCIM brings the same problems as proprietary APIs (l=
ittle compatibility, weak schema, need to "profile" every deployment) then =
SCIM does not bring enough value to justify its existence. I.e. it would be=
 approximately the same effort to configure SCIM connector as to write a ne=
w connector for proprietary API from scratch. And approximately the same ef=
fort to maintain them. Maybe it is even higher effort to maintain SCIM conn=
ector as a change in SCIM may affect many systems and there may be unexpect=
ed side effects.

If SCIM brings the same problems as existing APIs and improves the situatio=
n just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be devel=
oped in isolation before it is unleashed to the world.  The initial philoso=
phy of the SCIM community was that it is better to start the ball rolling w=
ith a wider community engaged (SaaS vendors, SaaS consumers, standards expe=
rts) and work out issues by writing code and finding problems along the way=
.  Working outside of a standards body makes it nearly impossible to engage=
 such a large community.

I don't argue for developing a solution in isolation. Quite the contrary. O=
pen development (e.g. in a form of an open source project) is necessary for=
 something like SCIM. But it has to be open development not yet the standar=
dization. Standardization means fixing the interface.=20
Fixing the interface inevitably limits further development. And fixing the =
interface that is inappropriate for real use does not make much sense to me=
. And engineering experience shows now and again that if something has not =
been tested in real situations it is inappropriate for real use (with an ov=
erwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development version t=
hat is barely usable and then work on SCIM 2.0 which may in fact bring some=
 value I'm OK with that. But it should be clearly indicated that SCIM 1.0 i=
s just a development version and it is not suitable for real deployments.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

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



From michael.brenner@alcatel-lucent.com  Thu Apr 26 08:29:07 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A431F21E80B7 for ; Thu, 26 Apr 2012 08:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.832
X-Spam-Level: 
X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 sKD66ofOXVzP for ; Thu, 26 Apr 2012 08:29:06 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 96B6021E80B4 for ; Thu, 26 Apr 2012 08:29:06 -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 q3QFT2DS028433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Apr 2012 10:29:02 -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 q3QFT0E3023652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Apr 2012 10:29:02 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 26 Apr 2012 10:29:01 -0500
From: "Brenner, Michael Ralf (Michael)" 
To: Kelly Grizzle , Radovan Semancik , "scim@ietf.org" 
Date: Thu, 26 Apr 2012 10:29:00 -0500
Thread-Topic: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
Thread-Index: AQHNIpr/TFvtWahJSUu03t0tZKcKApaq+S4AgABB14CAAMZnMIAAujmAgABgtBCAAB9TYA==
Message-ID: <219947F0B2242843A0A1E62FDB510DC02510BF30E4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  <4F978304.4050005@gmail.com>	<4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.namprd04.prod.outlook.com>
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.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.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 15:29:07 -0000

That is what I was hoping to hear from one of the early adopters. I don't t=
hink we differ on whether SCIM 1.0 is stable enough or not. What I said ear=
lier was that if SCIM 1.0 is considered stable enough by several companies =
that are implementing it (which you now confirm), then this is good enough =
for me. And better than a particular API implementation for the same purpos=
e by a single company (no matter which one that was).

Michael

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel=
ly Grizzle
Sent: Thursday, April 26, 2012 10:53 AM
To: Radovan Semancik; scim@ietf.org
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

I hear what you're saying and agree with you.  If SCIM does not solve real =
problems or provide real interoperability then it is a complete waste of ti=
me.  Where we differ is whether SCIM 1.0 is stable enough to use.  While it=
 is not currently in production anywhere, multiple SaaS providers and vendo=
rs have committed to supporting it by the end of the year, so the "developm=
ent version" label is not accurate.  Will it change in 2.0 in non-backwards=
-compatible ways?  Almost certainly ... but that is alright.

The primary goal of the interop events are to make sure that real use cases=
 actually work and see where the spec doesn't hold up.  So far testing has =
found both weaknesses in the spec and bugs in the implementations.  Some of=
 the spec problems are being addressed in 1.0 and some in 2.0.  See simplec=
loud.info for interop results and discussion.

> [Michael] I agree with Radovan that making sure the providers' requiremen=
ts are
> understood and addressed is VERY important, much more important than eith=
er
> starting from SCIM 1.0, or breaking backward compatibility to it.

I totally agree.  There are some documented use cases on simplecloud.info, =
but they are very high level and somewhat out of date.  Lower level use cas=
es have been used for the interop events, but these are not exhaustive and =
are light on detail.  The charter calls for a use cases document, which sho=
uld definitely be done early in the process.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Rad=
ovan Semancik
Sent: Thursday, April 26, 2012 2:45 AM
To: scim@ietf.org
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>> what is the point of implementing such early versions if we know that=20
>> the schema is bad and we also know that we will need to throw out=20
>> significant part of the code and configuration when a new SCIM=20
>> version comes? ... If that is true, then there is a serious adoption pro=
blem.
> I disagree here.  Adoption has always been a primary goal, and there are =
many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...=
) that have already committed to adopting SCIM - many of whom already have =
working code.  You are absolutely right that some non-backwards compatible =
changes will need to be made.  The charter calls out that these should be k=
ept to a minimum, and most early adopters seem happy enough with this.

With all respect to the early adopters, I see mostly provisioning vendors i=
n the interoperability tests. If SCIM should be a "cloud"=20
protocols I would expect mostly cloud providers in that group as it a provi=
der side of the protocol that should specify most of the requirements. Is t=
here any real production-quality deployment of SCIM among the early adopter=
s? What is the feedback from the early SCIM tests? That it works as designe=
d? Pardon me, but that's pretty useless feedback in this situation.

> The alternative is that SaaS providers continue to write their own propri=
etary APIs that will have the same versioning problems as SCIM.  In this wo=
rld, every consumer would have to write a custom connector to every SaaS ap=
p, each with a custom protocol and language around the data that they model=
.

My argument is that if SCIM brings the same problems as proprietary APIs (l=
ittle compatibility, weak schema, need to "profile" every deployment) then =
SCIM does not bring enough value to justify its existence. I.e. it would be=
 approximately the same effort to configure SCIM connector as to write a ne=
w connector for proprietary API from scratch. And approximately the same ef=
fort to maintain them. Maybe it is even higher effort to maintain SCIM conn=
ector as a change in SCIM may affect many systems and there may be unexpect=
ed side effects.

If SCIM brings the same problems as existing APIs and improves the situatio=
n just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be devel=
oped in isolation before it is unleashed to the world.  The initial philoso=
phy of the SCIM community was that it is better to start the ball rolling w=
ith a wider community engaged (SaaS vendors, SaaS consumers, standards expe=
rts) and work out issues by writing code and finding problems along the way=
.  Working outside of a standards body makes it nearly impossible to engage=
 such a large community.

I don't argue for developing a solution in isolation. Quite the contrary. O=
pen development (e.g. in a form of an open source project) is necessary for=
 something like SCIM. But it has to be open development not yet the standar=
dization. Standardization means fixing the interface.=20
Fixing the interface inevitably limits further development. And fixing the =
interface that is inappropriate for real use does not make much sense to me=
. And engineering experience shows now and again that if something has not =
been tested in real situations it is inappropriate for real use (with an ov=
erwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development version t=
hat is barely usable and then work on SCIM 2.0 which may in fact bring some=
 value I'm OK with that. But it should be clearly indicated that SCIM 1.0 i=
s just a development version and it is not suitable for real deployments.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

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


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

From melinda.shore@gmail.com  Thu Apr 26 09:06: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 DBD7921E8111 for ; Thu, 26 Apr 2012 09:06: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 AAuNhOotKoGT for ; Thu, 26 Apr 2012 09:06:38 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 56E3721E810D for ; Thu, 26 Apr 2012 09:06:38 -0700 (PDT)
Received: by dady13 with SMTP id y13so2724528dad.27 for ; Thu, 26 Apr 2012 09:06: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=gym3RY7dKVwcjoMN9iob3iBAaShK9JDcXtyRyc7sGSE=; b=0zM1i7TBo19do+osszDT2TP2a4vTFLbWtKGYmufjrinkPJIRYyeGOmV69hrAxz0HpE r4oYUVp3TUvE78DHUMajFTWgub8EBY28qrVuU30vVZyXSKbezjgo/fs0lOQStFD8aa7D pD+IjEURMEAmbYA1j+Zh1oB4NdZgTdNH0eLfTmzUzU8oPFu+NOfBe4gx3V4wgjqpVXXj aCTNbk0NrY11ZNZy6v3/bcE/mwiGnmZ6eJZwCLgi/B9OBQXy/V2jleN5OpmOlY/U2qe3 m5ic7pmKKXCJIQqlv8NAkMQ5A53ekcMUX4x/TmNVByZ/MokiU/ZW6WB8O/fd04m+gcGE PGeQ==
Received: by 10.68.132.133 with SMTP id ou5mr6639714pbb.21.1335456398177; Thu, 26 Apr 2012 09:06: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 nv9sm3658112pbb.35.2012.04.26.09.06.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 09:06:37 -0700 (PDT)
Message-ID: <4F99728A.9090507@gmail.com>
Date: Thu, 26 Apr 2012 08:06: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: 	<4F978304.4050005@gmail.com> <4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com>
In-Reply-To: <4F98FCE5.2000603@evolveum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 16:06:39 -0000

On 4/25/12 11:44 PM, Radovan Semancik wrote:
> My argument is that if SCIM brings the same problems as proprietary APIs
> (little compatibility, weak schema, need to "profile" every deployment)
> then SCIM does not bring enough value to justify its existence. I.e. it
> would be approximately the same effort to configure SCIM connector as to
> write a new connector for proprietary API from scratch. And
> approximately the same effort to maintain them. Maybe it is even higher
> effort to maintain SCIM connector as a change in SCIM may affect many
> systems and there may be unexpected side effects.

There's often an adoption challenge around interoperability -
interoperability by definition undermines vendor lock-in.
There's an interest in *not* making it easy to provision to
other vendors' gear.  The three general responses to that are
1) to be able to make an argument that this technology is
better; 2) demand from customers, and; 3) if the vendor
software is open-source, go ahead and implement (er, "prototype")
on it.  If vendors believe they've got a proprietary advantage
with what they've got, or that the cost of implementing the new
stuff isn't going to generate (or save) enough revenue to cover
that cost, they're going to be reluctant to move.

Melinda

From phil.hunt@oracle.com  Thu Apr 26 11:29: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 5C07121E8128 for ; Thu, 26 Apr 2012 11:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.214
X-Spam-Level: 
X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 yytaqk-tyyUK for ; Thu, 26 Apr 2012 11:29:20 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4E821E80D9 for ; Thu, 26 Apr 2012 11:29:19 -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 q3QITIMj026321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 Apr 2012 18:29:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3QITH8w029873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 18:29:18 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3QITHfa030019 for ; Thu, 26 Apr 2012 13:29:17 -0500
Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Apr 2012 11:29:17 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
From: Phil Hunt 
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.namprd04.prod.outlook.com>
Date: Thu, 26 Apr 2012 11:29:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F64911E-21EA-44EB-8C2E-9E858A44DD80@oracle.com>
References:  <4F978304.4050005@gmail.com>	<4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.namprd04.prod.outlook.com>
To: scim@ietf.org
X-Mailer: Apple Mail (2.1257)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [scim] Backwards Compatibility -> Was Re:  About SCIM Schema
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 18:29:22 -0000

If there are no production deployments of SCIM in operation and issues =
with the consortium specs have been found, why is backwards =
compatibility in the charter?=20

Phil

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





On 2012-04-26, at 7:53 AM, Kelly Grizzle wrote:

> I hear what you're saying and agree with you.  If SCIM does not solve =
real problems or provide real interoperability then it is a complete =
waste of time.  Where we differ is whether SCIM 1.0 is stable enough to =
use.  While it is not currently in production anywhere, multiple SaaS =
providers and vendors have committed to supporting it by the end of the =
year, so the "development version" label is not accurate.  Will it =
change in 2.0 in non-backwards-compatible ways?  Almost certainly ... =
but that is alright.
>=20
> The primary goal of the interop events are to make sure that real use =
cases actually work and see where the spec doesn't hold up.  So far =
testing has found both weaknesses in the spec and bugs in the =
implementations.  Some of the spec problems are being addressed in 1.0 =
and some in 2.0.  See simplecloud.info for interop results and =
discussion.
>=20
>> [Michael] I agree with Radovan that making sure the providers' =
requirements are
>> understood and addressed is VERY important, much more important than =
either
>> starting from SCIM 1.0, or breaking backward compatibility to it.
>=20
> I totally agree.  There are some documented use cases on =
simplecloud.info, but they are very high level and somewhat out of date. =
 Lower level use cases have been used for the interop events, but these =
are not exhaustive and are light on detail.  The charter calls for a use =
cases document, which should definitely be done early in the process.
>=20
> --Kelly
>=20
>=20
> -----Original Message-----
> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf =
Of Radovan Semancik
> Sent: Thursday, April 26, 2012 2:45 AM
> To: scim@ietf.org
> Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues
>=20
> On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>>> what is the point of implementing such early versions if we know =
that=20
>>> the schema is bad and we also know that we will need to throw out=20
>>> significant part of the code and configuration when a new SCIM=20
>>> version comes? ... If that is true, then there is a serious adoption =
problem.
>> I disagree here.  Adoption has always been a primary goal, and there =
are many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, =
etc...) that have already committed to adopting SCIM - many of whom =
already have working code.  You are absolutely right that some =
non-backwards compatible changes will need to be made.  The charter =
calls out that these should be kept to a minimum, and most early =
adopters seem happy enough with this.
>=20
> With all respect to the early adopters, I see mostly provisioning =
vendors in the interoperability tests. If SCIM should be a "cloud"=20
> protocols I would expect mostly cloud providers in that group as it a =
provider side of the protocol that should specify most of the =
requirements. Is there any real production-quality deployment of SCIM =
among the early adopters? What is the feedback from the early SCIM =
tests? That it works as designed? Pardon me, but that's pretty useless =
feedback in this situation.
>=20
>> The alternative is that SaaS providers continue to write their own =
proprietary APIs that will have the same versioning problems as SCIM.  =
In this world, every consumer would have to write a custom connector to =
every SaaS app, each with a custom protocol and language around the data =
that they model.
>=20
> My argument is that if SCIM brings the same problems as proprietary =
APIs (little compatibility, weak schema, need to "profile" every =
deployment) then SCIM does not bring enough value to justify its =
existence. I.e. it would be approximately the same effort to configure =
SCIM connector as to write a new connector for proprietary API from =
scratch. And approximately the same effort to maintain them. Maybe it is =
even higher effort to maintain SCIM connector as a change in SCIM may =
affect many systems and there may be unexpected side effects.
>=20
> If SCIM brings the same problems as existing APIs and improves the =
situation just a tiny bit, is it worth all the hassle?
>=20
>> The question you raise is whether a near-perfect solution should be =
developed in isolation before it is unleashed to the world.  The initial =
philosophy of the SCIM community was that it is better to start the ball =
rolling with a wider community engaged (SaaS vendors, SaaS consumers, =
standards experts) and work out issues by writing code and finding =
problems along the way.  Working outside of a standards body makes it =
nearly impossible to engage such a large community.
>=20
> I don't argue for developing a solution in isolation. Quite the =
contrary. Open development (e.g. in a form of an open source project) is =
necessary for something like SCIM. But it has to be open development not =
yet the standardization. Standardization means fixing the interface.=20
> Fixing the interface inevitably limits further development. And fixing =
the interface that is inappropriate for real use does not make much =
sense to me. And engineering experience shows now and again that if =
something has not been tested in real situations it is inappropriate for =
real use (with an overwhelming probability).
>=20
> Therefore if you consider SCIM 1.0 to be a very early development =
version that is barely usable and then work on SCIM 2.0 which may in =
fact bring some value I'm OK with that. But it should be clearly =
indicated that SCIM 1.0 is just a development version and it is not =
suitable for real deployments.
>=20
> --=20
>=20
>                                          Radovan Semancik
>                                         Software Architect
>                                            evolveum.com
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From moransar@cisco.com  Thu Apr 26 12:30: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 99F2221E8175 for ; Thu, 26 Apr 2012 12:30: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=[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 t3blGfBjyn8h for ; Thu, 26 Apr 2012 12:30:40 -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 073BF21E8173 for ; Thu, 26 Apr 2012 12:30:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=896; q=dns/txt; s=iport; t=1335468640; x=1336678240; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qG773bD3nJAFtG5bL50Y88oQt20J5kJJCX/bkhO4Fpc=; b=TLHLK3BCVUS16KDyMfDS7I3OtzCy2lIK1HZBybp7FB7TRlOeYLUpI40l y0RFiZI33pFMvtZdR1Mle//JBPRu8Hw6ZgkhxkCfuwWhkjn7XjkkZQqy1 ngVDj8Gnin1dFSQXwMxNwc6uRKAFT8onuBJ2wckQ+XoRb45uhHe8LVnNn M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKKhmU+tJV2b/2dsb2JhbABFsXCBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQTCBqHawuaV6AdBIp9hQVjBIhjm3GBaYMGgTYI
X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78217624"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2012 19:30:39 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QJUdie027804;  Thu, 26 Apr 2012 19:30:39 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, 26 Apr 2012 14:30:39 -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, 26 Apr 2012 14:30:38 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE012F316B@XMB-RCD-313.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [scim] Draft charter - v7
Thread-Index: Ac0fL/Em3swOGckvRei2so/MyfuSrQEslufg
References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com><4F86686D.8010609@gmail.com><93C6FB63F046384C86EC8F7F3FFEC7BE0114E4D3@XMB-RCD-313.cisco.com> 
From: "Morteza Ansari (moransar)" 
To: "Barry Leiba" 
X-OriginalArrivalTime: 26 Apr 2012 19:30:39.0290 (UTC) FILETIME=[0FC799A0:01CD23E3]
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 19:30:40 -0000

My apologies for going quite for the past week or so. I was out of town
with very limited email access. I am going through the comments and will
roll them up into an updated charter text today.


Cheers,
Morteza

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Barry Leiba
Sent: Friday, April 20, 2012 12:58 PM
To: Morteza Ansari (moransar)
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v7

It's been several days without any further discussion of the charter.
There's active conversation about the specs, and that's a nice thing.
Since the charter comments seem to have settled, why don't you post
another version of the charter with the recent comments (since v7)
incorporated?

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

From kelly.grizzle@sailpoint.com  Thu Apr 26 13:31: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 C654D21E8120 for ; Thu, 26 Apr 2012 13:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.905
X-Spam-Level: 
X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 Y-WnS9HyG6-U for ; Thu, 26 Apr 2012 13:31:35 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8965D21E80BC for ; Thu, 26 Apr 2012 13:31:35 -0700 (PDT)
Received: from mail82-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 20:31:33 +0000
Received: from mail82-ch1 (localhost [127.0.0.1])	by mail82-ch1-R.bigfish.com (Postfix) with ESMTP id 1830A2A0278; Thu, 26 Apr 2012 20:31:33 +0000 (UTC)
X-SpamScore: -38
X-BigFish: PS-38(zzbb2dI9371I936eK542M1432N98dKzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25h)
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 (mail82-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 mail82-ch1 (localhost.localdomain [127.0.0.1]) by mail82-ch1 (MessageSwitch) id 1335472290759913_6510; Thu, 26 Apr 2012 20:31:30 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236])	by mail82-ch1.bigfish.com (Postfix) with ESMTP id B56444025F; Thu, 26 Apr 2012 20:31:30 +0000 (UTC)
Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 20:31:30 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.33]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0143.004; Thu, 26 Apr 2012 20:31:30 +0000
From: Kelly Grizzle 
To: Phil Hunt , "scim@ietf.org" 
Thread-Topic: [scim] Backwards Compatibility -> Was Re:  About SCIM Schema
Thread-Index: AQHNI9qEf911oqWXDkmgdH6sk1ianZatfDLA
Date: Thu, 26 Apr 2012 20:31:29 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C343722092DDC@BL2PRD0410MB351.namprd04.prod.outlook.com>
References:  <4F978304.4050005@gmail.com>	<4F97BA3F.7040706@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C34372208F983@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F98FCE5.2000603@evolveum.com> <56C3C758F9D6534CA3778EAA1E0C343722092AC0@BL2PRD0410MB351.namprd04.prod.outlook.com> <4F64911E-21EA-44EB-8C2E-9E858A44DD80@oracle.com>
In-Reply-To: <4F64911E-21EA-44EB-8C2E-9E858A44DD80@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
Subject: Re: [scim] Backwards Compatibility -> Was Re:  About SCIM Schema
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 26 Apr 2012 20:31:36 -0000

Primarily because there will soon be production deployments of 1.0 (plus so=
me small fixes).  The charter says:

  some consideration should be given for backward
  compatibility as the group evolves the work.


To me this just says backwards compatibility should be one of the factors i=
n deciding what goes into 2.0.  I don't think that 2.0 will end up having d=
rop-in backwards compatibility with 1.0, but keeping these to a minimum wil=
l ease upgrade 2-3 years down the line when SCIM 2.0 is finalized.  That sa=
id, if the working group decides that major changes would be very beneficia=
l to (for example) the schema, the desire for backwards compatibility may l=
ose out.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi=
l Hunt
Sent: Thursday, April 26, 2012 1:29 PM
To: scim@ietf.org
Subject: [scim] Backwards Compatibility -> Was Re: About SCIM Schema

If there are no production deployments of SCIM in operation and issues with=
 the consortium specs have been found, why is backwards compatibility in th=
e charter?=20

Phil

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





On 2012-04-26, at 7:53 AM, Kelly Grizzle wrote:

> I hear what you're saying and agree with you.  If SCIM does not solve rea=
l problems or provide real interoperability then it is a complete waste of =
time.  Where we differ is whether SCIM 1.0 is stable enough to use.  While =
it is not currently in production anywhere, multiple SaaS providers and ven=
dors have committed to supporting it by the end of the year, so the "develo=
pment version" label is not accurate.  Will it change in 2.0 in non-backwar=
ds-compatible ways?  Almost certainly ... but that is alright.
>=20
> The primary goal of the interop events are to make sure that real use cas=
es actually work and see where the spec doesn't hold up.  So far testing ha=
s found both weaknesses in the spec and bugs in the implementations.  Some =
of the spec problems are being addressed in 1.0 and some in 2.0.  See simpl=
ecloud.info for interop results and discussion.
>=20
>> [Michael] I agree with Radovan that making sure the providers'=20
>> requirements are understood and addressed is VERY important, much=20
>> more important than either starting from SCIM 1.0, or breaking backward =
compatibility to it.
>=20
> I totally agree.  There are some documented use cases on simplecloud.info=
, but they are very high level and somewhat out of date.  Lower level use c=
ases have been used for the interop events, but these are not exhaustive an=
d are light on detail.  The charter calls for a use cases document, which s=
hould definitely be done early in the process.
>=20
> --Kelly
>=20
>=20
> -----Original Message-----
> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20
> Of Radovan Semancik
> Sent: Thursday, April 26, 2012 2:45 AM
> To: scim@ietf.org
> Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues
>=20
> On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>>> what is the point of implementing such early versions if we know=20
>>> that the schema is bad and we also know that we will need to throw=20
>>> out significant part of the code and configuration when a new SCIM=20
>>> version comes? ... If that is true, then there is a serious adoption pr=
oblem.
>> I disagree here.  Adoption has always been a primary goal, and there are=
 many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc..=
.) that have already committed to adopting SCIM - many of whom already have=
 working code.  You are absolutely right that some non-backwards compatible=
 changes will need to be made.  The charter calls out that these should be =
kept to a minimum, and most early adopters seem happy enough with this.
>=20
> With all respect to the early adopters, I see mostly provisioning vendors=
 in the interoperability tests. If SCIM should be a "cloud"=20
> protocols I would expect mostly cloud providers in that group as it a pro=
vider side of the protocol that should specify most of the requirements. Is=
 there any real production-quality deployment of SCIM among the early adopt=
ers? What is the feedback from the early SCIM tests? That it works as desig=
ned? Pardon me, but that's pretty useless feedback in this situation.
>=20
>> The alternative is that SaaS providers continue to write their own propr=
ietary APIs that will have the same versioning problems as SCIM.  In this w=
orld, every consumer would have to write a custom connector to every SaaS a=
pp, each with a custom protocol and language around the data that they mode=
l.
>=20
> My argument is that if SCIM brings the same problems as proprietary APIs =
(little compatibility, weak schema, need to "profile" every deployment) the=
n SCIM does not bring enough value to justify its existence. I.e. it would =
be approximately the same effort to configure SCIM connector as to write a =
new connector for proprietary API from scratch. And approximately the same =
effort to maintain them. Maybe it is even higher effort to maintain SCIM co=
nnector as a change in SCIM may affect many systems and there may be unexpe=
cted side effects.
>=20
> If SCIM brings the same problems as existing APIs and improves the situat=
ion just a tiny bit, is it worth all the hassle?
>=20
>> The question you raise is whether a near-perfect solution should be deve=
loped in isolation before it is unleashed to the world.  The initial philos=
ophy of the SCIM community was that it is better to start the ball rolling =
with a wider community engaged (SaaS vendors, SaaS consumers, standards exp=
erts) and work out issues by writing code and finding problems along the wa=
y.  Working outside of a standards body makes it nearly impossible to engag=
e such a large community.
>=20
> I don't argue for developing a solution in isolation. Quite the contrary.=
 Open development (e.g. in a form of an open source project) is necessary f=
or something like SCIM. But it has to be open development not yet the stand=
ardization. Standardization means fixing the interface.=20
> Fixing the interface inevitably limits further development. And fixing th=
e interface that is inappropriate for real use does not make much sense to =
me. And engineering experience shows now and again that if something has no=
t been tested in real situations it is inappropriate for real use (with an =
overwhelming probability).
>=20
> Therefore if you consider SCIM 1.0 to be a very early development version=
 that is barely usable and then work on SCIM 2.0 which may in fact bring so=
me value I'm OK with that. But it should be clearly indicated that SCIM 1.0=
 is just a development version and it is not suitable for real deployments.
>=20
> --
>=20
>                                          Radovan Semancik
>                                         Software Architect
>                                            evolveum.com
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

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



From moransar@cisco.com  Thu Apr 26 23:57: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 076E821F86EA for ; Thu, 26 Apr 2012 23:57:24 -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 IITuzQoACZ9j for ; Thu, 26 Apr 2012 23:57:23 -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 3F4EF21F86B5 for ; Thu, 26 Apr 2012 23:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=1693; q=dns/txt; s=iport; t=1335509843; x=1336719443; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=OSOglxn5w1dyPufL6foc/tupidshdt9+bPyEehiUMN0=; b=bzE8iaMtV8vVABXzesF+P/5BNQF8zTboNbTFYh8+PGZwkaNDZr0KfOjo ok4ZN4aRiXZ9SwRA2oMjMxhBvT4CxxW96yoaNf6629SAhCbjwyQ/FVGs0 s11wUA9RH0Arzmp+lQTDVX9H3Lg1/N888KKG4u+S1wRyLgFo7DCoK2ND3 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOxCmk+tJV2c/2dsb2JhbABFsXeBB4IJAQEBAwEBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCAEMDYdmBQucDKAZiweFWWMEiGObcYFpgwaBPg
X-IronPort-AV: E=Sophos;i="4.75,489,1330905600"; d="scan'208";a="78347535"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 27 Apr 2012 06:57:22 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3R6vMCe017777;  Fri, 27 Apr 2012 06:57:22 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, 27 Apr 2012 01:57:22 -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, 27 Apr 2012 01:57:21 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE012F337F@XMB-RCD-313.cisco.com>
In-Reply-To: <4F8DB7D0.5040706@cs.tcd.ie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [scim] SCIM Issues
Thread-Index: Ac0cyNZn8YY/n8VMT2iCRgU+HFIyaAHYNeXQ
References: <4F8C19E8.2010309@evolveum.com> <4F8DB7D0.5040706@cs.tcd.ie>
From: "Morteza Ansari (moransar)" 
To: "Stephen Farrell" , "Samuel Erdtman" 
X-OriginalArrivalTime: 27 Apr 2012 06:57:22.0805 (UTC) FILETIME=[FEFD0A50:01CD2442]
Cc: Radovan Semancik , scim@ietf.org
Subject: Re: [scim] SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 06:57:24 -0000

Stephen,

Kelly answered this question much better than I could:
http://www.ietf.org/mail-archive/web/scim/current/msg00302.html

The key reason for not using inetOrgPerson is the flat vs. complex data
model. Having said that, I think the WG should evaluate and consider
using other options like vCard4 which is a lot closer to the SCIM schema
than any native LDAP schema.


Cheers,
Morteza

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Stephen Farrell
Sent: Tuesday, April 17, 2012 11:35 AM
To: Samuel Erdtman
Cc: Radovan Semancik; scim@ietf.org
Subject: Re: [scim] SCIM Issues


Just a question on one snippet:

On 04/17/2012 06:09 AM, Samuel Erdtman wrote:
>> >
>> > The familyName and givenName attributes have culture-neutral names.

>> > This is a nice take from FOAF. But the middleName is not that good.

>> > It enforces "american" point of view to the schema. Maybe=20
>> > "additionalName" would be more appropriate.
> I do not thing that middleName/additionalName is a big deal but good=20
> point. to be fully compliant with the global view might we also the=20
> need to make it multiValued for situations where more then one is=20
> common?

Does this mean that scim intend to re-develop the equivalent of
inetOrgPerson?

That seems like an odd idea. Why is it necessary?

Note - I'm not saying "use ldif" here, but wondering why this putative
WG would need to go re-do all that data modelling work, as would be
implied by the quoted text above.

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

From moransar@cisco.com  Fri Apr 27 00:43: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 0C63421F86DD for ; Fri, 27 Apr 2012 00:43: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=[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 Dv7IpzOLY5or for ; Fri, 27 Apr 2012 00:43:39 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 051E821F86C7 for ; Fri, 27 Apr 2012 00:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=3560; q=dns/txt; s=iport; t=1335512619; x=1336722219; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=T7hcvfI4TskF6Z/urUcUywNDKq2oZf1hjkwYa+AaDjU=; b=Gu0jQ/IZs+elc4Ew75mwaeqovH5ki9/YojOVSiPjwKyu0849mrSHuNSk h2yf1h4gkvfgzbiSyRpdrLkzm2ybHdbB68sx7XNeyRq5wcAampuwc21IB mb6O2d+zBg+OfSbpP/b9oHiAbBIZVnurOHoXfTKIHGK5xIi4jH8bMjjPU 0=;
X-IronPort-AV: E=Sophos;i="4.75,489,1330905600"; d="scan'208";a="78369024"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 27 Apr 2012 07:43:31 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q3R7hVCk009539;  Fri, 27 Apr 2012 07:43:31 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);  Fri, 27 Apr 2012 02:43:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Fri, 27 Apr 2012 02:43:30 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338B@XMB-RCD-313.cisco.com>
In-Reply-To: <4F96E44F.4020408@stpeter.im>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [scim] Draft charter - v7
Thread-Index: Ac0iQJuOtOjuxmAAR7SY0444oUs0FQCAxACA
References: <93C6FB63F046384C86EC8F7F3FFEC7BE0114E4C4@XMB-RCD-313.cisco.com>  <4F873572.9060205@cisco.com>  <4F8C597E.2040609@stpeter.im> <4F96E44F.4020408@stpeter.im>
From: "Morteza Ansari (moransar)" 
To: "Peter Saint-Andre" , "Barry Leiba" 
X-OriginalArrivalTime: 27 Apr 2012 07:43:31.0236 (UTC) FILETIME=[711A1640:01CD2449]
Cc: scim@ietf.org, Eliot Lear 
Subject: Re: [scim] Draft charter - v7
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 07:43:40 -0000

PHNuaXA+DQpIZXJlIGlzIHNvbWUgcHJvcG9zZWQgdGV4dC4uLg0KDQpPTEQNCiAgIFRoZSBTaW1w
bGUgQ2xvdWQgSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgc3BlY2lmaWNhdGlvbg0KICAgd2ls
bCBiZSBkZXNpZ25lZCB0byBzaW1wbGlmeSB1c2VyIGlkZW50aXR5IG1hbmFnZW1lbnQgaW4NCiAg
IHNlcnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMgYnkgZGVmaW5pbmcgc3RhbmRhcmQgcHJvdG9jb2xz
DQogICBhbmQgc2NoZW1hcyBmb3IgY3JlYXRpbmcsIHJlYWRpbmcvc2VhcmNoaW5nLCBtb2RpZnlp
bmcsDQogICBhbmQgZGVsZXRpbmcgdXNlciBpZGVudGl0aWVzIGFuZCBpZGVudGl0eS1yZWxhdGVk
IG9iamVjdHMNCiAgIGFjcm9zcyBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLg0KDQpORVcNCg0KICAg
VGhlIFNpbXBsZSBDbG91ZCBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSB3b3JraW5nIGdyb3Vw
DQogICB3aWxsIHN0YW5kYXJkaXplIG1ldGhvZHMgZm9yIGNyZWF0aW5nLCByZWFkaW5nL3NlYXJj
aGluZywNCiAgIG1vZGlmeWluZywgYW5kIGRlbGV0aW5nIHVzZXIgaWRlbnRpdGllcyBhbmQgaWRl
bnRpdHktcmVsYXRlZA0KICAgb2JqZWN0cyBhY3Jvc3MgYWRtaW5pc3RyYXRpdmUgZG9tYWlucywg
d2l0aCB0aGUgZ29hbCBvZg0KICAgc2ltcGxpZnlpbmcgY29tbW9uIHRhc2tzIHJlbGF0ZWQgdG8g
dXNlciBpZGVudGl0eSBtYW5hZ2VtZW50DQogICBpbiBzZXJ2aWNlcyBhbmQgYXBwbGljYXRpb25z
Lg0KDQogICBCeSAic3RhbmRhcmRpemUiIGlzIG5vdCBtZWFudCB0aGF0IHRoZSB3b3JraW5nIGdy
b3VwIHdpbGwNCiAgIG5lY2Vzc2FyaWx5IGRldmVsb3AgbmV3IHRlY2hub2xvZ2llcy4gIEZvciBl
eGFtcGxlLCB0aGUNCiAgIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGZvciAiU0NJTSAxLjAiIHBy
b3ZpZGUgUkVTVGZ1bA0KICAgaW50ZXJmYWNlcyBvbiB0b3Agb2YgSFRUUCByYXRoZXIgdGhhbiBk
ZWZpbmluZyBhIG5ldw0KICAgYXBwbGljYXRpb24gcHJvdG9jb2wuICBIb3dldmVyLCB0aG9zZSBz
cGVjaWZpY2F0aW9ucyBkbw0KICAgZGVmaW5lIG5vdmVsIHBheWxvYWQgZm9ybWF0cyAoInNjaGVt
YXMiKSBmb3IgZGF0YSBleGNoYW5nZTsNCiAgIHRoZXNlIGZvcm1hdHMgYXJlIGRlc2lnbmVkIHRv
IGVuY2Fwc3VsYXRlIGFuIGludGVyb3BlcmFibGUNCiAgIHN1YnNldCBvZiBpZGVudGl0eS1yZWxh
dGVkIGluZm9ybWF0aW9uIGZvciBjb21tdW5pY2F0aW9uDQogICBiZXR3ZWVuIGFkbWluaXN0cmF0
aXZlIGRvbWFpbnMsIG9mIHRoZSBraW5kIHRoYXQgaXMgb2Z0ZW4NCiAgIGNvbnRhaW5lZCBpbiBm
b3JtYXRzIHN1Y2ggYXMgTERBUCBhbmQgdkNhcmQgd2l0aGluIGFuDQogICBhZG1pbmlzdHJhdGl2
ZSBkb21haW4uDQoNCkknbSBhIGJpdCB1bnN1cmUgYWJvdXQgdGhlIGxhc3Qgc2VudGVuY2UsIGFu
ZCBCYXJyeSBhbmQgb3RoZXJzIG1pZ2h0IHRoaW5rIHRoYXQgd2UgbmVlZCB0byBzYXkgc29tZXRo
aW5nIG1vcmUgYWJvdXQgY29uc2lkZXJpbmcsIGluIHRoZSBJRVRGIGNvbnRleHQsIHdoZXRoZXIg
dG8gdXNlIG5hdGl2ZSBMREFQIG9yIHZDYXJkIG9yIG90aGVyIGZvcm1hdHMgaW5zdGVhZCBvZiB0
aGUgbm92ZWwgZm9ybWF0cyBjdXJyZW50bHkgZGVmaW5lZCBpbiBTQ0lNIDEuMCAoZS5nLiwgd2Ug
Y291bGQgYWRkIGEgc2VudGVuY2UgYXQgdGhlIGVuZCBsaWtlICJUaGUgd29ya2luZyBncm91cCBz
aG91bGQgY29uc2lkZXIgd2hldGhlciBleGlzdGluZyBkYXRhIGZvcm1hdHMgc3VjaCBhcyBMREFQ
IGFuZCB2Q2FyZCBhcmUgYXBwcm9wcmlhdGUgZm9yIGludGVyY2hhbmdlIGJldHdlZW4gYWRtaW5p
c3RyYXRpdmUgZG9tYWlucy4iKS4NCk5hdHVyYWxseSwgZmVlZGJhY2sgaXMgd2VsY29tZSBvbiB0
aGF0IHBvaW50IGFuZCBvdGhlcnMuDQoNCk1BPiBJIGxpa2UgeW91ciBwcm9wb3NlZCB0ZXh0IGFz
IGl0IGNsZWFybHkgc3RhdGVzIHdoYXQgd2UgYXJlIHRyeWluZyB0byBkbyBhbmQgd2hhdCB0aGUg
Y3VycmVudCBwcm9wb3NhbCBpcy4gSG93ZXZlciwgSSBhbSBhbHNvIHVuc3VyZSBhYm91dCB0aGUg
bGFzdCBzZW50ZW5jZS4gSSB0aGluayBpdCBpcyB0b28gdmVyYm9zZSBhbmQgZG9lcyBub3QgbmVj
ZXNzYXJpbHkgYWRkIGEgd2hvbGUgbG90IGZvciB0aGUgcHVycG9zZXMgb2YgY2hhcnRlci4gVGhl
IGNoYXJ0ZXIgc2ltcGx5IHNheXMgZGVmaW5pbmcgc2NoZW1hIGlzIGEgY29yZSBwYXJ0IG9mIHRo
ZSBjaGFydGVyIGFuZCB0aGF0IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgY29uc2lkZXJhdGlvbiBz
aG91bGQgYmUgZ2l2ZW4gdG8gdGhlIFNDSU0gMS4wIHNwZWMuIFRoaXMgbWVhbnMgdGhlIFdHIHNo
b3VsZCBldmFsdWF0ZSB2YXJpb3VzIG9wdGlvbnMgZm9yIHNjaGVtYSBhbmQgZGVjaWRlIG9uIHRo
ZSBiZXN0IG9wdGlvbi4gRm9yIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBjaGFydGVyIEkgd2ls
bCBza2lwIHRoYXQgc2VudGVuY2UgdW50aWwgb3RoZXJzIGhhdmUgaGFkIGEgY2hhbmNlIHRvIGNo
aW1lIGluIGFuZCBwcm92aWRlIG1vcmUgZmVlZGJhY2svc3VnZ2VzdGlvbnMuICBUaGFua3MgZm9y
IHlvdXIgdGV4dC4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQo=

From moransar@cisco.com  Fri Apr 27 00:55: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 81A8221F86DA for ; Fri, 27 Apr 2012 00:55:06 -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 dBJRKaXCqphu for ; Fri, 27 Apr 2012 00:55:05 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6221F86C1 for ; Fri, 27 Apr 2012 00:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=28145; q=dns/txt; s=iport; t=1335513304; x=1336722904; h=mime-version:subject:date:message-id:from:to; bh=sc4pULH/Iak2BpvCyaFNxI4LW5wPxUKYej8Q0YjniW0=; b=P3r3TBzZNDNb0fPowbbe45CAfdYupjL/3u3BHCdrWC6/Vu9Gcow6saBW XBFIQvCrgy+GZw++SuYPgIePvylg/mmR0coF3M02vzHs4dNjm5eK6F9o6 eRt1Eg2synB0lyU/gglw8+1Z1wmLzVG4oLUXwxThJKUbJ50VAdJvmCM3n Q=;
X-Files: charter8.txt : 4012
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIxPmk+tJXHB/2dsb2JhbAA7AQmCRq80gQeCCwEEAQEBDwEJEQM+HQEqAgQYBwElMQEEEQIIARmHawuaaYEooCCKeAYBCIVZYwSIY4YTgSOUO4FpgwYggRYI
X-IronPort-AV: E=Sophos;i="4.75,490,1330905600";  d="txt'?scan'208,217";a="78370892"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 27 Apr 2012 07:55:04 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3R7t3cu014012 for ; Fri, 27 Apr 2012 07:55:03 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);  Fri, 27 Apr 2012 02:55:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD244B.0DF38540"
Date: Fri, 27 Apr 2012 02:55:02 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft charter - v8
Thread-Index: Ac0kQx045/4YU3aZQ+ibxZmfCQEItQ==
From: "Morteza Ansari (moransar)" 
To: 
X-OriginalArrivalTime: 27 Apr 2012 07:55:03.0700 (UTC) FILETIME=[0DD7B540:01CD244B]
Subject: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 07:55:06 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD244B.0DF38540
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CD244B.0DF38540"


------_=_NextPart_002_01CD244B.0DF38540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks everyone for reviews and suggestions and sorry for delay on my
side in updating the text of charter.  Updated version is attached. The
changes in this version are:

=20

-Added most of the text Peter suggested (see my response to his email)

-Added the security consideration text from Peter & Melinda

-Reordered the milestone to emphasize initial focus on the core
documents

-Fixed minor correction Kelly reported

=20

Please review the text and send your comments. Hopefully this is good
enough to hand it over to the ADs.

=20

=20

Cheers,

Morteza

=20

*** charter7.txt               2012-04-09 18:52:42.000000000 -0700

--- charter8.txt  2012-04-27 00:52:41.000000000 -0700

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

*** 9,21 ****

       Archive:
http://www.ietf.org/mail-archive/web/scim/current/maillist.html

  =20

  Description of Working Group:

! The Simple Cloud Identity Management (SCIM) specification will be
designed to=20

! simplify user identity management in services and applications by
defining

! standard protocols and schemas for creating, reading/searching,
modifying,

! and deleting user identities and identity-related objects across=20

! administrative domains.

 =20

! Today, distributed identity management across such 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,

--- 9,26 ----

       Archive:
http://www.ietf.org/mail-archive/web/scim/current/maillist.html

  =20

  Description of Working Group:

! The Simple Cloud 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,

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

*** 25,31 ****

  including, a lack of common schema, toolsets, and libraries.

 =20

  The SCIM working group will develop the core schema and RESTful
interfaces

! to address these problems. Initially, the WG will focus on a schema
definition

  and set of operations for creation, modification, and deletion of
users, as

  well as schema discovery, search, and bulk operations followed by
extensions

  including client targeting of specific SCIM endpoints.  The approach
will be

--- 30,36 ----

  including, a lack of common schema, toolsets, and libraries.

 =20

  The SCIM working group will develop the core schema and RESTful
interfaces

! to address these problems.  Initially, the WG will focus on a schema
definition

  and set of operations for creation, modification, and deletion of
users, as

  well as schema discovery, search, and bulk operations followed by
extensions

  including client targeting of specific SCIM endpoints.  The approach
will be

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

*** 40,56 ****

 =20

  These drafts are based on existing specifications, which together are
commonly

  known as SCIM 1.0.  As such, some consideration should be given for
backward

! compatibility as the group evolves the work.  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=20

! TC.

 =20

  The group will produce Proposed Standards for a schema, a protocol, a
SAML

  binding, and an LDAP mapping.  In doing so, the group will make
consistent

! the terminology, review and improve security of the overall system,

! identify any functional gaps that would be useful for future work,
address

! internationalization, and provide guidelines for extensibility (either

! through IANA registries or other means). =20

 =20

  The group considers the following out of scope for this group:

       Defining new authentication schemes

--- 45,66 ----

 =20

  These drafts are based on existing specifications, which together are
commonly

  known as SCIM 1.0.  As such, some consideration should be given for
backward

! compatibility as the group evolves the work.  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 group will produce Proposed Standards for a schema, a protocol, a
SAML

  binding, and an LDAP mapping.  In doing so, the group will make
consistent

! the terminology, identify any functional gaps that would be useful for
future

! work, address internationalization, and provide guidelines for
extensibility

! (either through IANA registries or other means). =20

!=20

! In addition, the working group will ensure that the SCIM protocol
embodies

! good security practices, or document gaps in its capabilities and
propose a

! path forward for addressing those gaps.  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

  The group considers the following out of scope for this group:

       Defining new authentication schemes

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

*** 61,70 ****

  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    Initial adoption of SCIM SAML bindings draft

- mm/yyyy    Initial adoption of SCIM LDAP mapping draft

  mm/yyyy    WGLC SCIM core schema

  mm/yyyy    WGLC SCIM restful interface

  mm/yyyy    WGLC SCIM SAML bindings

  mm/yyyy    WGLC SCIM LDAP mapping

  mm/yyyy    Re-charter discussion

--- 71,80 ----

  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


------_=_NextPart_002_01CD244B.0DF38540
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Thanks =
everyone for reviews and suggestions and sorry for delay on my side in =
updating the text of charter.  Updated version is attached. The =
changes in this version are:
 
-Added most =
of the text Peter suggested (see my response to his =
email)
-Added the security =
consideration text from Peter & Melinda
-Reordered the milestone to emphasize initial focus on =
the core documents
-Fixed minor =
correction Kelly reported
 
Please =
review the text and send your comments. Hopefully this is good enough to =
hand it over to the ADs.
 
 
Cheers,
Morteza
 
*** =
charter7.txt          &=
nbsp;    2012-04-09 18:52:42.000000000 =
-0700
--- charter8.txt  =
2012-04-27 00:52:41.000000000 -0700
***************
*** =
9,21 ****
       Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
   
  Description of Working =
Group:
! The Simple Cloud Identity =
Management (SCIM) specification will be designed to 
! simplify user identity management in services and =
applications by defining
! standard =
protocols and schemas for creating, reading/searching, =
modifying,
! and deleting user =
identities and identity-related objects across 
! administrative domains.
  
! Today, =
distributed identity management across such 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,
--- 9,26 ----
       Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
   
  Description of Working =
Group:
! The Simple Cloud 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,
***************
*** =
25,31 ****
  including, a lack =
of common schema, toolsets, and libraries.
  
  The SCIM working group will develop the =
core schema and RESTful interfaces
! =
to address these problems. Initially, the WG will focus on a schema =
definition
  and set of =
operations for creation, modification, and deletion of users, =
as
  well as schema discovery, =
search, and bulk operations followed by extensions
  including client targeting of specific SCIM =
endpoints.  The approach will be
--- 30,36 ----
  including, a lack of common schema, toolsets, =
and libraries.
  =

  The SCIM working group =
will develop the core schema and RESTful interfaces
! to address these problems.  Initially, the WG =
will focus on a schema definition
  and set of operations for creation, =
modification, and deletion of users, as
  well as schema discovery, search, and bulk =
operations followed by extensions
  including client targeting of specific SCIM =
endpoints.  The approach will be
***************
*** =
40,56 ****
  
  These drafts are based on existing =
specifications, which together are commonly
  known as SCIM 1.0.  As such, some =
consideration should be given for backward
! compatibility as the group evolves the work.  =
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 group will produce =
Proposed Standards for a schema, a protocol, a SAML
  binding, and an LDAP mapping.  In doing =
so, the group will make consistent
! =
the terminology, review and improve security of the overall =
system,
! identify any functional =
gaps that would be useful for future work, address
! internationalization, and provide guidelines for =
extensibility (either
! through IANA =
registries or other means).  
  
  The group considers the following out of =
scope for this group:
       Defining new =
authentication schemes
--- 45,66 =
----
  
  These drafts are based on existing =
specifications, which together are commonly
  known as SCIM 1.0.  As such, some =
consideration should be given for backward
! compatibility as the group evolves the work.  =
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 group will produce Proposed Standards =
for a schema, a protocol, a SAML
  binding, and an LDAP mapping.  In doing =
so, the group will make consistent
! =
the terminology, identify any functional gaps that would be useful for =
future
! work, address =
internationalization, and provide guidelines for =
extensibility
! (either through IANA =
registries or other means).  
! =

! In addition, the working group =
will ensure that the SCIM protocol embodies
! good security practices, or document gaps in its =
capabilities and propose a
! path =
forward for addressing those gaps.  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.
  
  The group considers the following out of =
scope for this group:
       Defining new =
authentication schemes
***************
*** =
61,70 ****
  =
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    =
Initial adoption of SCIM SAML bindings draft
- mm/yyyy    Initial adoption of SCIM =
LDAP mapping draft
  =
mm/yyyy    WGLC SCIM core schema
  mm/yyyy    WGLC SCIM restful =
interface
  =
mm/yyyy    WGLC SCIM SAML bindings
  mm/yyyy    WGLC SCIM LDAP =
mapping
  =
mm/yyyy    Re-charter discussion
--- 71,80 ----
  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

------_=_NextPart_002_01CD244B.0DF38540--

------_=_NextPart_001_01CD244B.0DF38540
Content-Type: text/plain;
	name="charter8.txt"
Content-Transfer-Encoding: base64
Content-Description: charter8.txt
Content-Disposition: attachment;
	filename="charter8.txt"

U2ltcGxlIENsb3VkIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pCkNoYWlyKHMpOiBUQkQgCkFw
cGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yKHMpOgogICAgIFBldGUgUmVzbmljayA8cHJlc25pY2tA
cXVhbGNvbW0uY29tPiAKICAgICBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+
IApNYWlsaW5nIExpc3RzOgogICAgIEdlbmVyYWwgRGlzY3Vzc2lvbjogc2NpbUBpZXRmLm9yZwog
ICAgIFRvIFN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
Y2ltCiAgICAgQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Nj
aW0vY3VycmVudC9tYWlsbGlzdC5odG1sCiAKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoK
VGhlIFNpbXBsZSBDbG91ZCBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSB3b3JraW5nIGdyb3Vw
IHdpbGwgc3RhbmRhcmRpemUKbWV0aG9kcyBmb3IgY3JlYXRpbmcsIHJlYWRpbmcvc2VhcmNoaW5n
LCBtb2RpZnlpbmcsIGFuZCBkZWxldGluZyB1c2VyCmlkZW50aXRpZXMgYW5kIGlkZW50aXR5LXJl
bGF0ZWQgb2JqZWN0cyBhY3Jvc3MgYWRtaW5pc3RyYXRpdmUgZG9tYWlucywgd2l0aAp0aGUgZ29h
bCBvZiBzaW1wbGlmeWluZyBjb21tb24gdGFza3MgcmVsYXRlZCB0byB1c2VyIGlkZW50aXR5IG1h
bmFnZW1lbnQgaW4Kc2VydmljZXMgYW5kIGFwcGxpY2F0aW9ucy4KCiJTdGFuZGFyZGl6ZSIgZG9l
cyBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGV2ZWxv
cApuZXcgdGVjaG5vbG9naWVzLiAgRm9yIGV4YW1wbGUsIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0
aW9ucyBmb3IgIlNDSU0gMS4wIgpwcm92aWRlIFJFU1RmdWwgaW50ZXJmYWNlcyBvbiB0b3Agb2Yg
SFRUUCByYXRoZXIgdGhhbiBkZWZpbmluZyBhIG5ldwphcHBsaWNhdGlvbiBwcm90b2NvbC4KClRv
ZGF5LCBkaXN0cmlidXRlZCBpZGVudGl0eSBtYW5hZ2VtZW50IGFjcm9zcyBhZG1pbmlzdHJhdGl2
ZSBkb21haW5zIGlzIGNvbXBsaWNhdGVkCmJ5IGEgbGFjayBvZiBwcm90b2NvbCBhbmQgc2NoZW1h
IHN0YW5kYXJkaXphdGlvbiBiZXR3ZWVuIGNvbnN1bWVycyBhbmQKcHJvZHVjZXJzIG9mIGlkZW50
aXRpZXMuICBUaGlzIGhhcyBsZWQgdG8gYSBudW1iZXIgb2YgYXBwcm9hY2hlcywKaW5jbHVkaW5n
IGVycm9yIHByb25lIG1hbnVhbCBhZG1pbmlzdHJhdGlvbiBhbmQgYnVsayBmaWxlIHVwbG9hZHMs
CmFzIHdlbGwgYXMgcHJvcHJpZXRhcnkgcHJvdG9jb2xzIGFuZCBtZWRpYXRpb24gZGV2aWNlcyB0
aGF0IG11c3QgYmUKYWRhcHRlZCB0byBlYWNoIHNlcnZpY2UgZm9yIGVhY2ggb3JnYW5pemF0aW9u
LiAgV2hpbGUgdGhlcmUgaXMgZXhpc3Rpbmcgd29yawppbiB0aGUgZmllbGQsIGl0IGhhcyBub3Qg
YmVlbiB3aWRlbHkgYWRvcHRlZCBmb3IgYSB2YXJpZXR5IG9mIHJlYXNvbnMKaW5jbHVkaW5nLCBh
IGxhY2sgb2YgY29tbW9uIHNjaGVtYSwgdG9vbHNldHMsIGFuZCBsaWJyYXJpZXMuCgpUaGUgU0NJ
TSB3b3JraW5nIGdyb3VwIHdpbGwgZGV2ZWxvcCB0aGUgY29yZSBzY2hlbWEgYW5kIFJFU1RmdWwg
aW50ZXJmYWNlcwp0byBhZGRyZXNzIHRoZXNlIHByb2JsZW1zLiAgSW5pdGlhbGx5LCB0aGUgV0cg
d2lsbCBmb2N1cyBvbiBhIHNjaGVtYSBkZWZpbml0aW9uCmFuZCBzZXQgb2Ygb3BlcmF0aW9ucyBm
b3IgY3JlYXRpb24sIG1vZGlmaWNhdGlvbiwgYW5kIGRlbGV0aW9uIG9mIHVzZXJzLCBhcwp3ZWxs
IGFzIHNjaGVtYSBkaXNjb3ZlcnksIHNlYXJjaCwgYW5kIGJ1bGsgb3BlcmF0aW9ucyBmb2xsb3dl
ZCBieSBleHRlbnNpb25zCmluY2x1ZGluZyBjbGllbnQgdGFyZ2V0aW5nIG9mIHNwZWNpZmljIFND
SU0gZW5kcG9pbnRzLiAgVGhlIGFwcHJvYWNoIHdpbGwgYmUKZXh0ZW5zaWJsZS4KClRoZSBncm91
cCB3aWxsIHVzZSwgYXMgc3RhcnRpbmcgcG9pbnRzLCB0aGUgZm9sbG93aW5nIGRyYWZ0cyBpbiB0
aGUgZm9sbG93aW5nCndheXM6CgogICAgIGRyYWZ0LXNjaW0tdXNlLWNhc2VzLTAwIGFzIHRoZSBp
bml0aWFsIHVzZSBjYXNlcyBmb3IgU0NJTSwKICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAw
IGFzIHRoZSBzY2hlbWEgc3BlY2lmaWNhdGlvbiwKICAgICBkcmFmdC1zY2ltLWFwaS0wMCBhcyB0
aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwKClRoZXNlIGRyYWZ0cyBhcmUgYmFzZWQgb24gZXhp
c3Rpbmcgc3BlY2lmaWNhdGlvbnMsIHdoaWNoIHRvZ2V0aGVyIGFyZSBjb21tb25seQprbm93biBh
cyBTQ0lNIDEuMC4gIEFzIHN1Y2gsIHNvbWUgY29uc2lkZXJhdGlvbiBzaG91bGQgYmUgZ2l2ZW4g
Zm9yIGJhY2t3YXJkCmNvbXBhdGliaWxpdHkgYXMgdGhlIGdyb3VwIGV2b2x2ZXMgdGhlIHdvcmsu
ICBUaGlzIGdyb3VwIHdpbGwgY29uc2lkZXIgdGhlCm9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgZ2F0
aGVyZWQgZnJvbSB0aGUgZXhpc3Rpbmcgd29yaywgYXMgd2VsbCBhcyBleHBlcmllbmNlcwp3aXRo
IHdvcmsgZG9uZSBieSBvdGhlciBib2RpZXMsIGluY2x1ZGluZyB0aGUgT0FTSVMgUHJvdmlzaW9u
aW5nIFRDLgoKVGhlIGdyb3VwIHdpbGwgcHJvZHVjZSBQcm9wb3NlZCBTdGFuZGFyZHMgZm9yIGEg
c2NoZW1hLCBhIHByb3RvY29sLCBhIFNBTUwKYmluZGluZywgYW5kIGFuIExEQVAgbWFwcGluZy4g
IEluIGRvaW5nIHNvLCB0aGUgZ3JvdXAgd2lsbCBtYWtlIGNvbnNpc3RlbnQKdGhlIHRlcm1pbm9s
b2d5LCBpZGVudGlmeSBhbnkgZnVuY3Rpb25hbCBnYXBzIHRoYXQgd291bGQgYmUgdXNlZnVsIGZv
ciBmdXR1cmUKd29yaywgYWRkcmVzcyBpbnRlcm5hdGlvbmFsaXphdGlvbiwgYW5kIHByb3ZpZGUg
Z3VpZGVsaW5lcyBmb3IgZXh0ZW5zaWJpbGl0eQooZWl0aGVyIHRocm91Z2ggSUFOQSByZWdpc3Ry
aWVzIG9yIG90aGVyIG1lYW5zKS4gIAoKSW4gYWRkaXRpb24sIHRoZSB3b3JraW5nIGdyb3VwIHdp
bGwgZW5zdXJlIHRoYXQgdGhlIFNDSU0gcHJvdG9jb2wgZW1ib2RpZXMKZ29vZCBzZWN1cml0eSBw
cmFjdGljZXMsIG9yIGRvY3VtZW50IGdhcHMgaW4gaXRzIGNhcGFiaWxpdGllcyBhbmQgcHJvcG9z
ZSBhCnBhdGggZm9yd2FyZCBmb3IgYWRkcmVzc2luZyB0aG9zZSBnYXBzLiAgR2l2ZW4gYm90aCB0
aGUgc2Vuc2l0aXZpdHkgb2YgdGhlCmluZm9ybWF0aW9uIGJlaW5nIGNvbnZleWVkIGluIFNDSU0g
bWVzc2FnZXMgYW5kIHRoZSByZWd1bGF0b3J5IHJlcXVpcmVtZW50cwpyZWdhcmRpbmcgdGhlIHBy
aXZhY3kgb2YgcGVyc29uYWxseSBpZGVudGlmaWFibGUgaW5mb3JtYXRpb24sIHRoZSB3b3JraW5n
Cmdyb3VwIHdpbGwgcGF5IHBhcnRpY3VsYXIgYXR0ZW50aW9uIHRvIGlzc3VlcyBhcm91bmQgYXV0
aGVudGljaXR5IGFuZCBwcml2YWN5LgoKVGhlIGdyb3VwIGNvbnNpZGVycyB0aGUgZm9sbG93aW5n
IG91dCBvZiBzY29wZSBmb3IgdGhpcyBncm91cDoKICAgICBEZWZpbmluZyBuZXcgYXV0aGVudGlj
YXRpb24gc2NoZW1lcwogICAgIERlZmluaW5nIG5ldyBwb2xpY3kvYXV0aG9yaXphdGlvbiBzY2hl
bWVzCgpNaWxlc3RvbmVzCgptbS95eXl5ICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSB1c2Ug
Y2FzZXMsIGFzIGEgbGl2aW5nIGRvY3VtZW50Cm1tL3l5eXkgICAgSW5pdGlhbCBhZG9wdGlvbiBv
ZiBTQ0lNIGNvcmUgc2NoZW1hCm1tL3l5eXkgICAgSW5pdGlhbCBhZG9wdGlvbiBvZiBTQ0lNIHJl
c3RmdWwgaW50ZXJmYWNlIGRyYWZ0Cm1tL3l5eXkgICAgV0dMQyBTQ0lNIGNvcmUgc2NoZW1hCm1t
L3l5eXkgICAgV0dMQyBTQ0lNIHJlc3RmdWwgaW50ZXJmYWNlCm1tL3l5eXkgICAgSW5pdGlhbCBh
ZG9wdGlvbiBvZiBTQ0lNIFNBTUwgYmluZGluZ3MgZHJhZnQKbW0veXl5eSAgICBJbml0aWFsIGFk
b3B0aW9uIG9mIFNDSU0gTERBUCBtYXBwaW5nIGRyYWZ0Cm1tL3l5eXkgICAgV0dMQyBTQ0lNIFNB
TUwgYmluZGluZ3MKbW0veXl5eSAgICBXR0xDIFNDSU0gTERBUCBtYXBwaW5nCm1tL3l5eXkgICAg
UmUtY2hhcnRlciBkaXNjdXNzaW9uCg==

------_=_NextPart_001_01CD244B.0DF38540--

From barryleiba.mailing.lists@gmail.com  Fri Apr 27 10:52: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 BC8A721F86CA for ; Fri, 27 Apr 2012 10:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, 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 OSW44rHV0BL0 for ; Fri, 27 Apr 2012 10:52:40 -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 57BAD21F86C7 for ; Fri, 27 Apr 2012 10:52:40 -0700 (PDT)
Received: by lagj5 with SMTP id j5so767004lag.31 for ; Fri, 27 Apr 2012 10:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zxHJseYceJUDDCfkUot/EO+NDD8xjoeulAVzNSbyZuk=; b=H7/6AcmiMw6eCRODNfLRPLyjkdtto3tFk5skgxi6s9b2uoplYGlZrjJAJ1E2uxowoE 5LhiGBhIBVx/gYFLuDCwXcrYnBsq7jQmGONyEqzXBoJEuNbPjyHE8xyXPc4W5sOR85lI 6ok0oy/W3ru9BFuAI8P3htrIJe5dxigPRIRi6KPo/sWEmaU5c/hjIFJYES+Q8U0KHUHP wOojUZdS+gi81HbpRvx6GqGzc1uXxoS2AdRNYgT3AxtmnkTFvQJ5LH2jhzYJTwF1Qdlw yjh6dpThYCyHJMO1LNr/XQwdmlUX5GhggcWQe/tsCPf8sVDy4IRcyUiSEiI5ln68hd8t eMOw==
MIME-Version: 1.0
Received: by 10.112.100.8 with SMTP id eu8mr5928501lbb.16.1335549159240; Fri, 27 Apr 2012 10:52:39 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.7.7 with HTTP; Fri, 27 Apr 2012 10:52:39 -0700 (PDT)
In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>
References:  <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>
Date: Fri, 27 Apr 2012 13:52:39 -0400
X-Google-Sender-Auth: hra5qffj0ns1qD_hwhrz-ilfGCs
Message-ID: 
From: Barry Leiba 
To: "Morteza Ansari (moransar)" 
Content-Type: multipart/mixed; boundary=14dae9d7172237768a04beacc52b
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 17:52:41 -0000

--14dae9d7172237768a04beacc52b
Content-Type: text/plain; charset=ISO-8859-1

> Please review the text and send your comments. Hopefully this is good enough
> to hand it over to the ADs.

Excellent; I'm basically happy with this version, and I think it's in
good shape.  Attached is an updated version with some edits, which are
all editorial (wording and formatting).  Please check the editorial
changes to be sure I didn't distort what you meant, and let me know if
anything is amiss.

If this group is happy with this 8.1 version, I'm happy to send it to
the IESG to start the review.

Barry

--14dae9d7172237768a04beacc52b
Content-Type: text/plain; charset=US-ASCII; name="scim charter v8.1.txt"
Content-Disposition: attachment; filename="scim charter v8.1.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h1jjgh6f1

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
Ci0gc2NoZW1hIGRpc2NvdmVyeQotIHNlYXJjaAotIGJ1bGsgb3BlcmF0aW9ucwpJdCB3aWxsIGZv
bGxvdyB0aGF0IGJ5IGNvbnNpZGVyaW5nIGV4dGVuc2lvbnMgZm9yIGNsaWVudCB0YXJnZXRpbmcg
b2YKc3BlY2lmaWMgU0NJTSBlbmRwb2ludHMuICBUaGUgYXBwcm9hY2ggd2lsbCBiZSBleHRlbnNp
YmxlLgoKVGhlIGdyb3VwIHdpbGwgdXNlLCBhcyBzdGFydGluZyBwb2ludHMsIHRoZSBmb2xsb3dp
bmcgZHJhZnRzIGluIHRoZQpmb2xsb3dpbmcgd2F5czoKICAgICBkcmFmdC1zY2ltLXVzZS1jYXNl
cy0wMCBhcyB0aGUgaW5pdGlhbCB1c2UgY2FzZXMgZm9yIFNDSU0KICAgICBkcmFmdC1zY2ltLWNv
cmUtc2NoZW1hLTAwIGFzIHRoZSBzY2hlbWEgc3BlY2lmaWNhdGlvbgogICAgIGRyYWZ0LXNjaW0t
YXBpLTAwIGFzIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uCgpUaGVzZSBkcmFmdHMgYXJlIGJh
c2VkIG9uIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zLCB3aGljaCB0b2dldGhlciBhcmUKY29tbW9u
bHkga25vd24gYXMgU0NJTSAxLjAuICBBcyBzdWNoLCBzb21lIGNvbnNpZGVyYXRpb24gc2hvdWxk
IGJlCmdpdmVuIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFzIHRoZSBncm91cCBkZXZlbG9w
cyB0aGUgd29yay4gIFRoaXMKZ3JvdXAgd2lsbCBjb25zaWRlciB0aGUgb3BlcmF0aW9uYWwgZXhw
ZXJpZW5jZSBnYXRoZXJlZCBmcm9tIHRoZQpleGlzdGluZyB3b3JrLCBhcyB3ZWxsIGFzIGV4cGVy
aWVuY2VzIHdpdGggd29yayBkb25lIGJ5IG90aGVyIGJvZGllcywKaW5jbHVkaW5nIHRoZSBPQVNJ
UyBQcm92aXNpb25pbmcgVEMuCgpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlIFByb3Bvc2VkIFN0YW5k
YXJkcyBmb3IgYSBzY2hlbWEsIGEgUkVTVC1iYXNlZApwcm90b2NvbCwgYSBTQU1MIGJpbmRpbmcs
IGFuZCBhbiBMREFQIG1hcHBpbmcuICBJbiBkb2luZyBzbywgdGhlIGdyb3VwCndpbGwgbWFrZSB0
aGUgdGVybWlub2xvZ3kgY29uc2lzdGVudCwgaWRlbnRpZnkgYW55IGZ1bmN0aW9uYWwgZ2Fwcwp0
aGF0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgZnV0dXJlIHdvcmssIGFkZHJlc3MgaW50ZXJuYXRpb25h
bGl6YXRpb24sCmFuZCBwcm92aWRlIGd1aWRlbGluZXMgYW5kIG1lY2hhbmlzbXMgZm9yIGV4dGVu
c2liaWxpdHkuCgpJbiBhZGRpdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBlbnN1cmUgdGhh
dCB0aGUgU0NJTSBwcm90b2NvbAplbWJvZGllcyBnb29kIHNlY3VyaXR5IHByYWN0aWNlcywgYW5k
IHdpbGwgZG9jdW1lbnQgZ2FwcyBpbiBpdHMKY2FwYWJpbGl0aWVzIGFuZCBwcm9wb3NlIGEgcGF0
aCBmb3J3YXJkIGZvciBhZGRyZXNzaW5nIHRob3NlIGdhcHMuIApHaXZlbiBib3RoIHRoZSBzZW5z
aXRpdml0eSBvZiB0aGUgaW5mb3JtYXRpb24gYmVpbmcgY29udmV5ZWQgaW4gU0NJTQptZXNzYWdl
cyBhbmQgdGhlIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyB0aGUgcHJpdmFjeSBv
ZgpwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbiwgdGhlIHdvcmtpbmcgZ3JvdXAg
d2lsbCBwYXkKcGFydGljdWxhciBhdHRlbnRpb24gdG8gaXNzdWVzIGFyb3VuZCBhdXRoZW50aWNp
dHkgYW5kIHByaXZhY3kuCgpUaGUgZ3JvdXAgY29uc2lkZXJzIHRoZSBmb2xsb3dpbmcgb3V0IG9m
IHNjb3BlIGZvciB0aGlzIGdyb3VwOgogICAgIERlZmluaW5nIG5ldyBhdXRoZW50aWNhdGlvbiBz
Y2hlbWVzCiAgICAgRGVmaW5pbmcgbmV3IHBvbGljeS9hdXRob3JpemF0aW9uIHNjaGVtZXMKCk1p
bGVzdG9uZXMKCm1tL3l5eXkgICAgSW5pdGlhbCBhZG9wdGlvbiBvZiBTQ0lNIHVzZSBjYXNlcywg
YXMgYSBsaXZpbmcgZG9jdW1lbnQKbW0veXl5eSAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0g
Y29yZSBzY2hlbWEKbW0veXl5eSAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gcmVzdGZ1bCBp
bnRlcmZhY2UgZHJhZnQKbW0veXl5eSAgICBXR0xDIFNDSU0gY29yZSBzY2hlbWEKbW0veXl5eSAg
ICBXR0xDIFNDSU0gcmVzdGZ1bCBpbnRlcmZhY2UKbW0veXl5eSAgICBJbml0aWFsIGFkb3B0aW9u
IG9mIFNDSU0gU0FNTCBiaW5kaW5ncyBkcmFmdAptbS95eXl5ICAgIEluaXRpYWwgYWRvcHRpb24g
b2YgU0NJTSBMREFQIG1hcHBpbmcgZHJhZnQKbW0veXl5eSAgICBXR0xDIFNDSU0gU0FNTCBiaW5k
aW5ncwptbS95eXl5ICAgIFdHTEMgU0NJTSBMREFQIG1hcHBpbmcKbW0veXl5eSAgICBSZS1jaGFy
dGVyIGRpc2N1c3Npb24K
--14dae9d7172237768a04beacc52b--

From melinda.shore@gmail.com  Fri Apr 27 11:09: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 6073321F8649 for ; Fri, 27 Apr 2012 11:09: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 k8nYMmdWr0sT for ; Fri, 27 Apr 2012 11:09:17 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D4DD021F8633 for ; Fri, 27 Apr 2012 11:09:17 -0700 (PDT)
Received: by dady13 with SMTP id y13so1764507dad.27 for ; Fri, 27 Apr 2012 11:09:17 -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=OHZFFxvEd2B8WONg1VR7A4KUIuB/u8do3GisOZwNZiU=; b=HCNurdx4BZU3dYZB0KcTaRsuc+UYgwPzql05jM6qE/DeEfWm4ScoDKlRhc+bw0Rici k9zEuSaBumibSkrBv4i/mKKt4S4Mwu/O4DuuBs0cHY0zz2B10EuJcgpToK/oq55RNqaR 16/EAOk4sDXugelwPNHav5mGIDa6bHAgTJo09A3NjgDCpeSMdiV3T9PnkwlnZxuENHuS trHuCIZxdgtfmLC1epOt5oINQxDxNk5FJRMZWAmcWs+KTsxIXQjDltl6lokqLnicEiZ9 /eoTmcvT8xn8Ck5PIAKWUvKUm2aL/R8av9ioTDo2ipoA3Ea9A9BVdOYYywwuf5fZ7RHf OauA==
Received: by 10.68.223.227 with SMTP id qx3mr652610pbc.1.1335550157629; Fri, 27 Apr 2012 11:09:17 -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 nm5sm7129324pbc.6.2012.04.27.11.09.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 11:09:17 -0700 (PDT)
Message-ID: <4F9AE0CB.7050009@gmail.com>
Date: Fri, 27 Apr 2012 10:09:15 -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:  <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 18:09:18 -0000

It looks good to me.

Melinda

From kelly.grizzle@sailpoint.com  Fri Apr 27 11:29: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 9079821F8693 for ; Fri, 27 Apr 2012 11:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.871
X-Spam-Level: 
X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 fM9yiKouR-0M for ; Fri, 27 Apr 2012 11:29:16 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7121F8688 for ; Fri, 27 Apr 2012 11:29:16 -0700 (PDT)
Received: from mail85-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Apr 2012 18:29:13 +0000
Received: from mail85-va3 (localhost [127.0.0.1])	by mail85-va3-R.bigfish.com (Postfix) with ESMTP id 1119F10024B; Fri, 27 Apr 2012 18:29:13 +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:BL2PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail85-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=BL2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; 
Received: from mail85-va3 (localhost.localdomain [127.0.0.1]) by mail85-va3 (MessageSwitch) id 1335551351354964_25925; Fri, 27 Apr 2012 18:29:11 +0000 (UTC)
Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.247])	by mail85-va3.bigfish.com (Postfix) with ESMTP id 46ADE2C00D5; Fri, 27 Apr 2012 18:29:11 +0000 (UTC)
Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Apr 2012 18:29:09 +0000
Received: from BL2PRD0410MB351.namprd04.prod.outlook.com ([169.254.3.197]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0143.004; Fri, 27 Apr 2012 18:29:10 +0000
From: Kelly Grizzle 
To: Melinda Shore , "scim@ietf.org" 
Thread-Topic: [scim] Draft charter - v8
Thread-Index: Ac0kQx045/4YU3aZQ+ibxZmfCQEItQAW2wOAAACUaoAAALBtIA==
Date: Fri, 27 Apr 2012 18:29:10 +0000
Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437220BCF45@BL2PRD0410MB351.namprd04.prod.outlook.com>
References:  <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>  <4F9AE0CB.7050009@gmail.com>
In-Reply-To: <4F9AE0CB.7050009@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] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 18:29:17 -0000

+1

Looks great.

--Kelly

-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Mel=
inda Shore
Sent: Friday, April 27, 2012 1:09 PM
To: scim@ietf.org
Subject: Re: [scim] Draft charter - v8

It looks good to me.

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



From Tina.Tsou.Zouting@huawei.com  Fri Apr 27 11:41:07 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1921F85CE for ; Fri, 27 Apr 2012 11:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  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 6u1V3PuT-bkf for ; Fri, 27 Apr 2012 11:41:06 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 963DF21F85CD for ; Fri, 27 Apr 2012 11:41:06 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFQ54799; Fri, 27 Apr 2012 14:41:06 -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; Fri, 27 Apr 2012 11:39:43 -0700
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 11:39:41 -0700
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.40]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 02:39:39 +0800
From: Tina TSOU 
To: Kelly Grizzle 
Thread-Topic: [scim] Draft charter - v8
Thread-Index: Ac0kQx045/4YU3aZQ+ibxZmfCQEItQAGF3qAAACUaoAAALISAAARISUY
Date: Fri, 27 Apr 2012 18:39:38 +0000
Message-ID: 
References:  <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>  <4F9AE0CB.7050009@gmail.com>, <56C3C758F9D6534CA3778EAA1E0C3437220BCF45@BL2PRD0410MB351.namprd04.prod.outlook.com>
In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437220BCF45@BL2PRD0410MB351.namprd04.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "scim@ietf.org" , Melinda Shore 
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 18:41:07 -0000

It looks good to me.

Sent from my iPad

On Apr 27, 2012, at 11:29 AM, "Kelly Grizzle" =
 wrote:

> +1
>=20
> Looks great.
>=20
> --Kelly
>=20
> -----Original Message-----
> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of M=
elinda Shore
> Sent: Friday, April 27, 2012 1:09 PM
> To: scim@ietf.org
> Subject: Re: [scim] Draft charter - v8
>=20
> It looks good to me.
>=20
> Melinda
> _______________________________________________
> 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 phil.hunt@oracle.com  Fri Apr 27 11:57: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 AC1CF21F864A for ; Fri, 27 Apr 2012 11:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.239
X-Spam-Level: 
X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.359, 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 v5o386mEpt9x for ; Fri, 27 Apr 2012 11:57:14 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB921F86A7 for ; Fri, 27 Apr 2012 11:57:13 -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 q3RIvC4u004936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Apr 2012 18:57:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3RIvBiQ010300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 18:57:12 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 q3RIvBFZ028390; Fri, 27 Apr 2012 13:57:11 -0500
Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Apr 2012 11:57:11 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_79CA3E06-872E-4FFF-8228-E25E8AFD2F4A"
From: Phil Hunt 
In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>
Date: Fri, 27 Apr 2012 11:57:09 -0700
Message-Id: <72110BD4-8BFC-4868-B7A3-A5F560E2E576@oracle.com>
References: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@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
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 18:57:15 -0000

--Apple-Mail=_79CA3E06-872E-4FFF-8228-E25E8AFD2F4A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Targeting appears to be missing (was in v7).

Trey had proposed inclusion into the core spec as permissible in the =
path to avoid an explicit extension endpoint.  Not sure what would =
happen with the schema extension.=20

I think you should reference the target draft and we can decide later =
the best approach (separate extension or part of core) -- I can support =
either approach. =20

Phil

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





On 2012-04-27, at 12:55 AM, Morteza Ansari (moransar) wrote:

> Thanks everyone for reviews and suggestions and sorry for delay on my =
side in updating the text of charter.  Updated version is attached. The =
changes in this version are:
> =20
> -Added most of the text Peter suggested (see my response to his email)
> -Added the security consideration text from Peter & Melinda
> -Reordered the milestone to emphasize initial focus on the core =
documents
> -Fixed minor correction Kelly reported
> =20
> Please review the text and send your comments. Hopefully this is good =
enough to hand it over to the ADs.
> =20
> =20
> Cheers,
> Morteza
> =20
> *** charter7.txt               2012-04-09 18:52:42.000000000 -0700
> --- charter8.txt  2012-04-27 00:52:41.000000000 -0700
> ***************
> *** 9,21 ****
>        Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
>  =20
>   Description of Working Group:
> ! The Simple Cloud Identity Management (SCIM) specification will be =
designed to
> ! simplify user identity management in services and applications by =
defining
> ! standard protocols and schemas for creating, reading/searching, =
modifying,
> ! and deleting user identities and identity-related objects across
> ! administrative domains.
> =20
> ! Today, distributed identity management across such 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,
> --- 9,26 ----
>        Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
>  =20
>   Description of Working Group:
> ! The Simple Cloud 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.
> =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,
> ***************
> *** 25,31 ****
>   including, a lack of common schema, toolsets, and libraries.
> =20
>   The SCIM working group will develop the core schema and RESTful =
interfaces
> ! to address these problems. Initially, the WG will focus on a schema =
definition
>   and set of operations for creation, modification, and deletion of =
users, as
>   well as schema discovery, search, and bulk operations followed by =
extensions
>   including client targeting of specific SCIM endpoints.  The approach =
will be
> --- 30,36 ----
>   including, a lack of common schema, toolsets, and libraries.
> =20
>   The SCIM working group will develop the core schema and RESTful =
interfaces
> ! to address these problems.  Initially, the WG will focus on a schema =
definition
>   and set of operations for creation, modification, and deletion of =
users, as
>   well as schema discovery, search, and bulk operations followed by =
extensions
>   including client targeting of specific SCIM endpoints.  The approach =
will be
> ***************
> *** 40,56 ****
> =20
>   These drafts are based on existing specifications, which together =
are commonly
>   known as SCIM 1.0.  As such, some consideration should be given for =
backward
> ! compatibility as the group evolves the work.  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 group will produce Proposed Standards for a schema, a protocol, =
a SAML
>   binding, and an LDAP mapping.  In doing so, the group will make =
consistent
> ! the terminology, review and improve security of the overall system,
> ! identify any functional gaps that would be useful for future work, =
address
> ! internationalization, and provide guidelines for extensibility =
(either
> ! through IANA registries or other means).=20
>  =20
>   The group considers the following out of scope for this group:
>        Defining new authentication schemes
> --- 45,66 ----
> =20
>   These drafts are based on existing specifications, which together =
are commonly
>   known as SCIM 1.0.  As such, some consideration should be given for =
backward
> ! compatibility as the group evolves the work.  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 group will produce Proposed Standards for a schema, a protocol, =
a SAML
>   binding, and an LDAP mapping.  In doing so, the group will make =
consistent
> ! the terminology, identify any functional gaps that would be useful =
for future
> ! work, address internationalization, and provide guidelines for =
extensibility
> ! (either through IANA registries or other means).=20
> !
> ! In addition, the working group will ensure that the SCIM protocol =
embodies
> ! good security practices, or document gaps in its capabilities and =
propose a
> ! path forward for addressing those gaps.  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
>   The group considers the following out of scope for this group:
>        Defining new authentication schemes
> ***************
> *** 61,70 ****
>   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    Initial adoption of SCIM SAML bindings draft
> - mm/yyyy    Initial adoption of SCIM LDAP mapping draft
>   mm/yyyy    WGLC SCIM core schema
>   mm/yyyy    WGLC SCIM restful interface
>   mm/yyyy    WGLC SCIM SAML bindings
>   mm/yyyy    WGLC SCIM LDAP mapping
>   mm/yyyy    Re-charter discussion
> --- 71,80 ----
>   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
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_79CA3E06-872E-4FFF-8228-E25E8AFD2F4A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Phil

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








On 2012-04-27, at 12:55 AM, Morteza Ansari (moransar) =
wrote:

Thanks everyone for reviews =
and suggestions and sorry for delay on my side in updating the text of =
charter.  Updated version is attached. The changes in this version =
are:
 
-Added most of the =
text Peter suggested (see my response to his email)
-Added the security consideration text from Peter & =
Melinda
-Reordered the milestone to =
emphasize initial focus on the core documents
-Fixed minor correction Kelly =
reported
 
Please review the text and send your comments. Hopefully =
this is good enough to hand it over to the ADs.
 
 
Cheers,
Morteza
*** =
charter7.txt          &n=
bsp;    2012-04-09 18:52:42.000000000 =
-0700
--- charter8.txt  2012-04-27 =
00:52:41.000000000 -0700
*** 9,21 =
****
       =
Archive:   
<charter8.txt>________=
_______________________________________
scim mailing list
scim@ietf.org

In-Reply-To: <72110BD4-8BFC-4868-B7A3-A5F560E2E576@oracle.com>
Date: Fri, 27 Apr 2012 11:58:45 -0700
Message-Id: <98767A52-E62B-4608-8FDC-9AC36DF2F537@oracle.com>
References: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com> <72110BD4-8BFC-4868-B7A3-A5F560E2E576@oracle.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
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 18:58:53 -0000

--Apple-Mail=_3E1512B3-65ED-42D1-BABE-9339B48EA7F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

apologies. I see the text is in there...
> The SCIM working group will develop the core schema and RESTful =
interfaces
> to address these problems.  Initially, the WG will focus on a schema =
definition
> and set of operations for creation, modification, and deletion of =
users, as
> well as schema discovery, search, and bulk operations followed by =
extensions
> including client targeting of specific SCIM endpoints.  The approach =
will be
> extensible.

+1 for the document.

Phil

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





On 2012-04-27, at 11:57 AM, Phil Hunt wrote:

> Targeting appears to be missing (was in v7).
>=20
> Trey had proposed inclusion into the core spec as permissible in the =
path to avoid an explicit extension endpoint.  Not sure what would =
happen with the schema extension.=20
>=20
> I think you should reference the target draft and we can decide later =
the best approach (separate extension or part of core) -- I can support =
either approach. =20
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2012-04-27, at 12:55 AM, Morteza Ansari (moransar) wrote:
>=20
>> Thanks everyone for reviews and suggestions and sorry for delay on my =
side in updating the text of charter.  Updated version is attached. The =
changes in this version are:
>> =20
>> -Added most of the text Peter suggested (see my response to his =
email)
>> -Added the security consideration text from Peter & Melinda
>> -Reordered the milestone to emphasize initial focus on the core =
documents
>> -Fixed minor correction Kelly reported
>> =20
>> Please review the text and send your comments. Hopefully this is good =
enough to hand it over to the ADs.
>> =20
>> =20
>> Cheers,
>> Morteza
>> =20
>> *** charter7.txt               2012-04-09 18:52:42.000000000 -0700
>> --- charter8.txt  2012-04-27 00:52:41.000000000 -0700
>> ***************
>> *** 9,21 ****
>>        Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
>>  =20
>>   Description of Working Group:
>> ! The Simple Cloud Identity Management (SCIM) specification will be =
designed to
>> ! simplify user identity management in services and applications by =
defining
>> ! standard protocols and schemas for creating, reading/searching, =
modifying,
>> ! and deleting user identities and identity-related objects across
>> ! administrative domains.
>> =20
>> ! Today, distributed identity management across such 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,
>> --- 9,26 ----
>>        Archive: =
http://www.ietf.org/mail-archive/web/scim/current/maillist.html
>>  =20
>>   Description of Working Group:
>> ! The Simple Cloud 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.
>> =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,
>> ***************
>> *** 25,31 ****
>>   including, a lack of common schema, toolsets, and libraries.
>> =20
>>   The SCIM working group will develop the core schema and RESTful =
interfaces
>> ! to address these problems. Initially, the WG will focus on a schema =
definition
>>   and set of operations for creation, modification, and deletion of =
users, as
>>   well as schema discovery, search, and bulk operations followed by =
extensions
>>   including client targeting of specific SCIM endpoints.  The =
approach will be
>> --- 30,36 ----
>>   including, a lack of common schema, toolsets, and libraries.
>> =20
>>   The SCIM working group will develop the core schema and RESTful =
interfaces
>> ! to address these problems.  Initially, the WG will focus on a =
schema definition
>>   and set of operations for creation, modification, and deletion of =
users, as
>>   well as schema discovery, search, and bulk operations followed by =
extensions
>>   including client targeting of specific SCIM endpoints.  The =
approach will be
>> ***************
>> *** 40,56 ****
>> =20
>>   These drafts are based on existing specifications, which together =
are commonly
>>   known as SCIM 1.0.  As such, some consideration should be given for =
backward
>> ! compatibility as the group evolves the work.  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 group will produce Proposed Standards for a schema, a protocol, =
a SAML
>>   binding, and an LDAP mapping.  In doing so, the group will make =
consistent
>> ! the terminology, review and improve security of the overall system,
>> ! identify any functional gaps that would be useful for future work, =
address
>> ! internationalization, and provide guidelines for extensibility =
(either
>> ! through IANA registries or other means).=20
>>  =20
>>   The group considers the following out of scope for this group:
>>        Defining new authentication schemes
>> --- 45,66 ----
>> =20
>>   These drafts are based on existing specifications, which together =
are commonly
>>   known as SCIM 1.0.  As such, some consideration should be given for =
backward
>> ! compatibility as the group evolves the work.  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 group will produce Proposed Standards for a schema, a protocol, =
a SAML
>>   binding, and an LDAP mapping.  In doing so, the group will make =
consistent
>> ! the terminology, identify any functional gaps that would be useful =
for future
>> ! work, address internationalization, and provide guidelines for =
extensibility
>> ! (either through IANA registries or other means).=20
>> !
>> ! In addition, the working group will ensure that the SCIM protocol =
embodies
>> ! good security practices, or document gaps in its capabilities and =
propose a
>> ! path forward for addressing those gaps.  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
>>   The group considers the following out of scope for this group:
>>        Defining new authentication schemes
>> ***************
>> *** 61,70 ****
>>   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    Initial adoption of SCIM SAML bindings draft
>> - mm/yyyy    Initial adoption of SCIM LDAP mapping draft
>>   mm/yyyy    WGLC SCIM core schema
>>   mm/yyyy    WGLC SCIM restful interface
>>   mm/yyyy    WGLC SCIM SAML bindings
>>   mm/yyyy    WGLC SCIM LDAP mapping
>>   mm/yyyy    Re-charter discussion
>> --- 71,80 ----
>>   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
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_3E1512B3-65ED-42D1-BABE-9339B48EA7F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


The SCIM working group will develop the core schema =
and RESTful interfaces
to address these problems. =
 Initially, the WG will focus on a schema definition
and =
set of operations for creation, modification, and deletion of users, =
as
well as schema discovery, search, and bulk operations =
followed by extensions
including client targeting of specific =
SCIM endpoints.  The approach will =
be
extensible.






On 2012-04-27, at 11:57 AM, Phil Hunt wrote:

Targeting appears to be missing =
(was in v7).

Trey had proposed inclusion into the =
core spec as permissible in the path to avoid an explicit extension =
endpoint.  Not sure what would happen with the schema =
extension. 

I think you should reference =
the target draft and we can decide later the best approach (separate =
extension or part of core) -- I can support either approach. =
 



Phil

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








On 2012-04-27, at 12:55 AM, Morteza Ansari (moransar) =
wrote:

Thanks everyone for reviews =
and suggestions and sorry for delay on my side in updating the text of =
charter.  Updated version is attached. The changes in this version =
are:
 
-Added most of the =
text Peter suggested (see my response to his email)
-Added the security consideration text from Peter & =
Melinda
-Reordered the milestone to =
emphasize initial focus on the core documents
-Fixed minor correction Kelly =
reported
 
Please review the text and send your comments. Hopefully =
this is good enough to hand it over to the ADs.
 
 
Cheers,
Morteza
*** =
charter7.txt          &n=
bsp;    2012-04-09 18:52:42.000000000 =
-0700
--- charter8.txt  2012-04-27 =
00:52:41.000000000 -0700
*** 9,21 =
****
       =
Archive:   
<charter8.txt>________=
_______________________________________
scim mailing list
scim@ietf.org
scim@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/scim

=

--Apple-Mail=_3E1512B3-65ED-42D1-BABE-9339B48EA7F7--

From Chris.Phillips@canarie.ca  Fri Apr 27 12:24:11 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008E521F8694 for ; Fri, 27 Apr 2012 12:24:10 -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.000,  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 s-0r2sEapyq7 for ; Fri, 27 Apr 2012 12:24:08 -0700 (PDT)
Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 71F8721F863D for ; Fri, 27 Apr 2012 12:24:07 -0700 (PDT)
Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Fri, 27 Apr 2012 15:24:06 -0400
From: Chris Phillips 
To: Barry Leiba 
Date: Fri, 27 Apr 2012 15:24:01 -0400
Thread-Topic: [scim] Draft charter - v8
Thread-Index: Ac0kq0+ECO4NBuPJSR2W6hgcyM0EHw==
Message-ID: 
References:  <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com> 
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
Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" 
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 19:24:13 -0000

Looks good to me..

C

/mobile_____________________
chris.phillips@canarie.ca

On Apr 27, 2012, at 1:52 PM, "Barry Leiba"  wrote:

>> Please review the text and send your comments. Hopefully this is good en=
ough
>> to hand it over to the ADs.
>=20
> Excellent; I'm basically happy with this version, and I think it's in
> good shape.  Attached is an updated version with some edits, which are
> all editorial (wording and formatting).  Please check the editorial
> changes to be sure I didn't distort what you meant, and let me know if
> anything is amiss.
>=20
> If this group is happy with this 8.1 version, I'm happy to send it to
> the IESG to start the review.
>=20
> Barry
> 
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

From moransar@cisco.com  Fri Apr 27 13:49:53 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D77D21F866A for ; Fri, 27 Apr 2012 13:49:53 -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 V9Mwqw+soNcx for ; Fri, 27 Apr 2012 13:49:52 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3E60121F864A for ; Fri, 27 Apr 2012 13:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=2007; q=dns/txt; s=iport; t=1335559792; x=1336769392; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UhZeFHhK6AgwWsdFBjaTsKJeNHqGP8PqG7MoGpLYzoM=; b=e29qd/W17XA0Tr20tXEBoMxb1V1GH7HTbJT6YMrumRyFlYIO6FvYGW9z T98STt4N3Oid1wTBOCy2hSlOYGJcz3VptaU9ljoTB42tMv6oMu2rEZifG 8E3I+hh45TQqLP894pI+gswAuCJrjZgKcVcpxg9rz6H2J7LKGgXp2uE8L M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJAFm0+tJV2a/2dsb2JhbABEsgSBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHZgWbRaAOiniFQmMEiGObcYFpgwaBNg
X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="78591930"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 27 Apr 2012 20:49:52 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3RKnpFw007524;  Fri, 27 Apr 2012 20:49:51 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);  Fri, 27 Apr 2012 15:49:51 -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, 27 Apr 2012 15:49:50 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE012F3694@XMB-RCD-313.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [scim] Draft charter - v8
Thread-Index: Ac0kno22hF9zTilOT9y26RMuCsYGsAAGFJUg
References: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com> 
From: "Morteza Ansari (moransar)" 
To: "Barry Leiba" 
X-OriginalArrivalTime: 27 Apr 2012 20:49:51.0700 (UTC) FILETIME=[4AD99140:01CD24B7]
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 20:49:53 -0000

I like the edits in 8.1.  But noticed a minor inconsistency between 4th
and 7th paragraph (BTW, this was inconsistent in my version).  You may
want to add this minor tweak to the text.  I am fine with it as is
though.


Cheers,
Morteza

*** charter8-1.txt	2012-04-27 11:30:36.000000000 -0700
--- charter9.txt	2012-04-27 11:32:29.000000000 -0700
***************
*** 40,49 ****
  - a schema definition
  - a set of operations for creation, modification, and deletion of
users
  - schema discovery
! - search
  - bulk operations
  It will follow that by considering extensions for client targeting of
! specific SCIM endpoints.  The approach will be extensible.
 =20
  The group will use, as starting points, the following drafts in the
  following ways:
--- 40,50 ----
  - a schema definition
  - a set of operations for creation, modification, and deletion of
users
  - 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:



-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of
Barry Leiba
Sent: Friday, April 27, 2012 10:53 AM
To: Morteza Ansari (moransar)
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v8

> Please review the text and send your comments. Hopefully this is good=20
> enough to hand it over to the ADs.

Excellent; I'm basically happy with this version, and I think it's in
good shape.  Attached is an updated version with some edits, which are
all editorial (wording and formatting).  Please check the editorial
changes to be sure I didn't distort what you meant, and let me know if
anything is amiss.

If this group is happy with this 8.1 version, I'm happy to send it to
the IESG to start the review.

Barry

From barryleiba.mailing.lists@gmail.com  Fri Apr 27 15:29: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 6DE7121E802B for ; Fri, 27 Apr 2012 15:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, 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 DeOGICudCDxd for ; Fri, 27 Apr 2012 15:29:40 -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 A375D21E8026 for ; Fri, 27 Apr 2012 15:29:39 -0700 (PDT)
Received: by lbbgm13 with SMTP id gm13so926334lbb.31 for ; Fri, 27 Apr 2012 15:29:38 -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 :content-transfer-encoding; bh=hPEgfx9cdNCk4v2b/wau0tu6bnN9mN76khXqb+DeOvM=; b=sGl1sbtBaReAzAVzIYrvhM25qg66jrnJ/i7nr4qdLjxNoE51Rrhgo9FelPZgYf3A1H 2ZzicN3qZSSg1e/4DOTe65O9iTqo3INJfuTsLaD+LPPJ8s/pnla8ZCow0ZjdDHrPuM0s 1nwVjN17rpeygI3Fr3w+snSbrtMdvISQb7q2OA4CPImpErNf2+T9CnzVby+fGeubl3os efeTaKiktITTRFqSP9xskSA4yW9n2Gr3uCmzKzuPVRAVndpXhplN7Au2hTcS/NeiS9Sh 29PAHgsu1v35xI2Zn/aAp/Xdnh8uozFwOFD9qYpbIJzbZWn3mtg88T1lMGrfEmh0HXSc Qu8A==
MIME-Version: 1.0
Received: by 10.112.100.8 with SMTP id eu8mr6306425lbb.16.1335565778665; Fri, 27 Apr 2012 15:29:38 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.7.7 with HTTP; Fri, 27 Apr 2012 15:29:38 -0700 (PDT)
In-Reply-To: <93C6FB63F046384C86EC8F7F3FFEC7BE012F3694@XMB-RCD-313.cisco.com>
References: <93C6FB63F046384C86EC8F7F3FFEC7BE012F338E@XMB-RCD-313.cisco.com>  <93C6FB63F046384C86EC8F7F3FFEC7BE012F3694@XMB-RCD-313.cisco.com>
Date: Fri, 27 Apr 2012 18:29:38 -0400
X-Google-Sender-Auth: F3nNYy88fzbkBkNeuUgkqPlkQAY
Message-ID: 
From: Barry Leiba 
To: "Morteza Ansari (moransar)" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: scim@ietf.org
Subject: Re: [scim] Draft charter - v8
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.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, 27 Apr 2012 22:29:40 -0000

> I like the edits in 8.1. =A0But noticed a minor inconsistency between 4th
> and 7th paragraph (BTW, this was inconsistent in my version). =A0You may
> want to add this minor tweak to the text.

Done in my version.  Now let's just come up with some draft dates for
the milestones, and I'll proceed with this.

[By the way: you'll notice that I'm not talking about the name
further.  I've given my opinion, and the group has given its.  I'm in
the rough on wanting to rename things, so "SCIM" it is for now.  The
IESG might or might not push back on the name; we'll see.  But no need
to discuss it further here.]

Barry

From moransar@cisco.com  Mon Apr 30 23:58:10 2012
Return-Path: 
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA66E21F87C4 for ; Mon, 30 Apr 2012 23:58:10 -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 sSAh2YBQiThm for ; Mon, 30 Apr 2012 23:58:06 -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 4534C21F8769 for ; Mon, 30 Apr 2012 23:58:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=14390; q=dns/txt; s=iport; t=1335855486; x=1337065086; h=mime-version:subject:date:message-id:from:to; bh=BCYVwri/2uNB8dJ+cfz8KPsJL7wS+/JsGUSoxoYAVdQ=; b=Ji27hdBM+bwKcSaSc3o07GlqTIVrahMzpLaH86a5sbTqNUgyzuSkfLp2 F3wrqs5vJmKi13ZUlRrDMXqAMRpMYCQ+iUeBkVJiFGjNWYPt7kyZCPzut 50nR2oPBxZqUca0vbCc7ZNWsV8AyQyVxqJ7XIomJnythGcZys6RPPiujY w=;
X-Files: charter9.txt : 4254
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAImIn0+tJXG+/2dsb2JhbAA6AQmCRq0hgwGBB4ILAQQBAQEPAQkRAz4dASoCBBgHASUxAQQRAggBGYdrC5h3gSifeIpzBgEIhSBjBIhkhhOBI5Q9gWmDBiCBFgg
X-IronPort-AV: E=Sophos;i="4.75,509,1330905600";  d="txt'?scan'208,217";a="79055200"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 01 May 2012 06:58:05 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q416w38p005782 for ; Tue, 1 May 2012 06:58:03 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);  Tue, 1 May 2012 01:58:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD2767.C0F5E13C"
Date: Tue, 1 May 2012 01:58:02 -0500
Message-ID: <93C6FB63F046384C86EC8F7F3FFEC7BE013764CC@XMB-RCD-313.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft charter - v9
Thread-Index: Ac0nZmZncbCZUJEjS0OzHhA3kcqByg==
From: "Morteza Ansari (moransar)" 
To: 
X-OriginalArrivalTime: 01 May 2012 06:58:03.0679 (UTC) FILETIME=[C100EAF0:01CD2767]
Subject: [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 06:58:10 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD2767.C0F5E13C
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CD2767.C0F5E13C"


------_=_NextPart_002_01CD2767.C0F5E13C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks,

=20

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.

=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


------_=_NextPart_002_01CD2767.C0F5E13C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


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

------_=_NextPart_002_01CD2767.C0F5E13C--

------_=_NextPart_001_01CD2767.C0F5E13C
Content-Type: text/plain;
	name="charter9.txt"
Content-Transfer-Encoding: base64
Content-Description: charter9.txt
Content-Disposition: attachment;
	filename="charter9.txt"

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
QVAgbWFwcGluZy4gIFRoZSBhcHByb2FjaAp3aWxsIGJlIGV4dGVuc2libGUuCgpUaGUgZ3JvdXAg
d2lsbCB1c2UsIGFzIHN0YXJ0aW5nIHBvaW50cywgdGhlIGZvbGxvd2luZyBkcmFmdHMgaW4gdGhl
CmZvbGxvd2luZyB3YXlzOgogICAgIGRyYWZ0LXNjaW0tdXNlLWNhc2VzLTAwIGFzIHRoZSBpbml0
aWFsIHVzZSBjYXNlcyBmb3IgU0NJTQogICAgIGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDAgYXMg
dGhlIHNjaGVtYSBzcGVjaWZpY2F0aW9uCiAgICAgZHJhZnQtc2NpbS1hcGktMDAgYXMgdGhlIHBy
b3RvY29sIHNwZWNpZmljYXRpb24KClRoZXNlIGRyYWZ0cyBhcmUgYmFzZWQgb24gZXhpc3Rpbmcg
c3BlY2lmaWNhdGlvbnMsIHdoaWNoIHRvZ2V0aGVyIGFyZQpjb21tb25seSBrbm93biBhcyBTQ0lN
IDEuMC4gIEFzIHN1Y2gsIHNvbWUgY29uc2lkZXJhdGlvbiBzaG91bGQgYmUKZ2l2ZW4gZm9yIGJh
Y2t3YXJkIGNvbXBhdGliaWxpdHkgYXMgdGhlIGdyb3VwIGRldmVsb3BzIHRoZSB3b3JrLiAgVGhp
cwpncm91cCB3aWxsIGNvbnNpZGVyIHRoZSBvcGVyYXRpb25hbCBleHBlcmllbmNlIGdhdGhlcmVk
IGZyb20gdGhlCmV4aXN0aW5nIHdvcmssIGFzIHdlbGwgYXMgZXhwZXJpZW5jZXMgd2l0aCB3b3Jr
IGRvbmUgYnkgb3RoZXIgYm9kaWVzLAppbmNsdWRpbmcgdGhlIE9BU0lTIFByb3Zpc2lvbmluZyBU
Qy4KClRoZSBncm91cCB3aWxsIHByb2R1Y2UgUHJvcG9zZWQgU3RhbmRhcmRzIGZvciBhIHNjaGVt
YSwgYSBSRVNULWJhc2VkCnByb3RvY29sLCBhIFNBTUwgYmluZGluZywgYW5kIGFuIExEQVAgbWFw
cGluZy4gIEluIGRvaW5nIHNvLCB0aGUgZ3JvdXAKd2lsbCBtYWtlIHRoZSB0ZXJtaW5vbG9neSBj
b25zaXN0ZW50LCBpZGVudGlmeSBhbnkgZnVuY3Rpb25hbCBnYXBzCnRoYXQgd291bGQgYmUgdXNl
ZnVsIGZvciBmdXR1cmUgd29yaywgYWRkcmVzcyBpbnRlcm5hdGlvbmFsaXphdGlvbiwKYW5kIHBy
b3ZpZGUgZ3VpZGVsaW5lcyBhbmQgbWVjaGFuaXNtcyBmb3IgZXh0ZW5zaWJpbGl0eS4KCkluIGFk
ZGl0aW9uLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGVuc3VyZSB0aGF0IHRoZSBTQ0lNIHByb3Rv
Y29sCmVtYm9kaWVzIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2VzLCBhbmQgd2lsbCBkb2N1bWVudCBn
YXBzIGluIGl0cwpjYXBhYmlsaXRpZXMgYW5kIHByb3Bvc2UgYSBwYXRoIGZvcndhcmQgZm9yIGFk
ZHJlc3NpbmcgdGhvc2UgZ2Fwcy4gCkdpdmVuIGJvdGggdGhlIHNlbnNpdGl2aXR5IG9mIHRoZSBp
bmZvcm1hdGlvbiBiZWluZyBjb252ZXllZCBpbiBTQ0lNCm1lc3NhZ2VzIGFuZCB0aGUgcmVndWxh
dG9yeSByZXF1aXJlbWVudHMgcmVnYXJkaW5nIHRoZSBwcml2YWN5IG9mCnBlcnNvbmFsbHkgaWRl
bnRpZmlhYmxlIGluZm9ybWF0aW9uLCB0aGUgd29ya2luZyBncm91cCB3aWxsIHBheQpwYXJ0aWN1
bGFyIGF0dGVudGlvbiB0byBpc3N1ZXMgYXJvdW5kIGF1dGhlbnRpY2l0eSBhbmQgcHJpdmFjeS4K
ClRoZSBncm91cCBjb25zaWRlcnMgdGhlIGZvbGxvd2luZyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMg
Z3JvdXA6CiAgICAgRGVmaW5pbmcgbmV3IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMKICAgICBEZWZp
bmluZyBuZXcgcG9saWN5L2F1dGhvcml6YXRpb24gc2NoZW1lcwoKTWlsZXN0b25lcwoKMDYvMjAx
MiAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gdXNlIGNhc2VzLCBhcyBhIGxpdmluZyBkb2N1
bWVudAowNi8yMDEyICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSBjb3JlIHNjaGVtYQowOC8y
MDEyICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSByZXN0ZnVsIGludGVyZmFjZSBkcmFmdAox
Mi8yMDEyICAgIFdHTEMgaW5pdGlhbCB2ZXJzaW9uIG9mIFNDSU0gdXNlIGNhc2VzCjEyLzIwMTIg
ICAgUHJvcG9zYWwgZm9yIGNsaWVudCB0YXJnZXRpbmcgb2YgU0NJTSBlbmRwb2ludHMKMDIvMjAx
MyAgICBXR0xDIFNDSU0gY29yZSBzY2hlbWEKMDUvMjAxMyAgICBXR0xDIFNDSU0gcmVzdGZ1bCBp
bnRlcmZhY2UKMDcvMjAxMyAgICBJbml0aWFsIGFkb3B0aW9uIG9mIFNDSU0gU0FNTCBiaW5kaW5n
cyBkcmFmdAowNy8yMDEzICAgIEluaXRpYWwgYWRvcHRpb24gb2YgU0NJTSBMREFQIG1hcHBpbmcg
ZHJhZnQKMDgvMjAxMyAgICBXR0xDIG9uIGNsaWVudCB0YXJnZXRpbmcgb2YgU0NJTSBlbmRwb2lu
dHMKMDkvMjAxMyAgICBQb3NzaWJsZSB1cGRhdGUgb2YgU0NJTSB1c2UgY2FzZXMKMTEvMjAxMyAg
ICBXR0xDIFNDSU0gU0FNTCBiaW5kaW5ncwoxMi8yMDEzICAgIFdHTEMgU0NJTSBMREFQIG1hcHBp
bmcKMDEvMjAxNCAgICBSZS1jaGFydGVyIGRpc2N1c3Npb24K

------_=_NextPart_001_01CD2767.C0F5E13C--