From nobody Fri Aug 1 09:25:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FCA1A0100 for ; Fri, 1 Aug 2014 09:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsCootRxsSSQ for ; Fri, 1 Aug 2014 09:25:20 -0700 (PDT) Received: from canmail.canarie.ca (canmail.canarie.ca [205.189.33.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5351B2801 for ; Fri, 1 Aug 2014 09:25:19 -0700 (PDT) Received: from THUNDERCHIEF.canarie.local (192.168.1.17) by Thunderchief.canarie.local (192.168.1.17) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 1 Aug 2014 12:25:00 -0400 Received: from THUNDERCHIEF.canarie.local ([::1]) by Thunderchief.canarie.local ([::1]) with mapi id 15.00.0775.031; Fri, 1 Aug 2014 12:25:00 -0400 From: Chris Phillips To: "scim@ietf.org" Thread-Topic: [scim] entitlements & roles attributes Thread-Index: AQHPrRFQ2HXe/o2TLEauzfwVHqmTXpu7DxaAgAAIz4CAADJ7AIAApcIA Date: Fri, 1 Aug 2014 16:25:00 +0000 Message-ID: References: <9aa56a2d1a8443e38705653f40a51997@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <9aa56a2d1a8443e38705653f40a51997@BN1PR04MB392.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [24.246.9.45] Content-Type: multipart/alternative; boundary="_000_D0011CD91AE255chrisphillipscanarieca_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/u5GjHwMdcYZk_KWLeJz_mHD22Ls Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:25:31 -0000 --_000_D0011CD91AE255chrisphillipscanarieca_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Just catching this thead during summer holidays, apologies if I didn't tra= ck it all and for late replies over the next week or so. To Kelly's question: What=92s the lesser of the evils? To have an underspecified standard attri= bute or a non-specified custom attribute that a bunch of folks will probabl= y want to use? I put forward that the lack of specificity is valuable. Anyone wanting to u= se their own groups, roles, and entitlements values can work within the co= re is better than always working in custom attributes and hoping your endpo= ints have them. I believe this highlights the question around WHERE you want to apply a pol= icy about what is contained in the attributes (to me, policy equates to con= straints not written into the spec) So where does policy begin and end? I believe the usually answer is around = who can connect to your endpoints. That's your permitter where your policy= is adhered to/enforced by someone/adopted by those who connect) To look back at another similar problem space to see what happened, take a = look at the HTML spec(RFC1866) around the forms section 8. It doesn't specify valid names nor valid values for form fields. The strength of this is that it has allowed any arbitrary combinations that= were not thought of when the spec was written. It was prescriptive 'enough= '. In one respect, SCIM is much like the HTML spec but for identity data. Prescriptive enough as a specification, but open ended enough to allow fle= xibility. Moving things around with respect to roles, groups, and entitlements was in= ticket #11[1] and was closed as 'won't fix. I (subjectively) think was due to lack of sufficient discussion about the = comments raised in the ticket due to larger fish to fry in other tickets. Now that some of the other items are behind us, and this topic is resurfaci= ng, maybe now is the time to dig a bit deeper to some of the points..? Chris. Other items related to this thread: Should attributes like this be collapsed?[2] Original use cases for the attributes: [3] One way entitlements can be described: [4] [1] http://trac.tools.ietf.org/wg/scim/trac/ticket/11 [2] https://www.ietf.org/mail-archive/web/scim/current/msg00237.html [3] http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6? [4] https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-= dir-eduperson-201203.html#eduPersonEntitlement From: Kelly Grizzle > Date: Thursday, 31 July, 2014 10:31 PM To: "Morteza Ansari (moransar)" >, Ian Glazer > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes I=92m not sure that I would say that there is no interoperability. The cli= ent just has to have some knowledge about what the server supports for valu= es here (maybe through /Entitlements and /Roles extended resource types?). = Of course, the same values probably wouldn=92t work on both SF and Cisco s= ervers. I agree with you, though, that complex attributes are warranted for some ca= ses of roles and entitlements. I=92d be interested to hear from some of th= e folks that have implemented SCIM servers if they make use of these or whe= ther they would have any opposition to dropping them. IIRC they were added because it was thought that most SPs would have some n= otion of roles, entitlements, groups, or some combination of them, and that= if they were left out of the schema that there would be more interop probl= ems because everyone would have custom extensions for these. What=92s the lesser of the evils? To have an underspecified standard attri= bute or a non-specified custom attribute that a bunch of folks will probabl= y want to use? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Thursday, July 31, 2014 6:31 PM To: Ian Glazer Cc: scim@ietf.org Subject: Re: [scim] entitlements & roles attributes I don=92t think there is any impact as there is no interoperability possibl= e given the semantics of the attributes are undefined. How could a client p= rovision a value for this attribute if the definition of that value is diff= erent from SF to Cisco to the next vendor? Cheers, Morteza From: Ian Glazer > Date: Thursday, July 31, 2014 at 6:59 PM To: Morteza Ansari > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes A fine can of worms you've cracked into ;-) I totally understand the need for complex attributes for roles. But I am li= ttle worried about the implications of dropping them from the core spec. An= y thoughts on what the impact would be? On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) > wrote: Speaking as an implementer: In our implementation, we have a new use case where we need the entitlement= and roles attributes to be complex. This is for cases where a user has an = entitlement to a service with further qualifier. Similarly for the roles a= ttribute there are cases where a simple string is not sufficient and role m= ay require additional parameters and a complex object would nicely solve th= e problem. The spec is very vague on these two attributes intentionally because the au= thorization model at various vendors are so different that it seemed imposs= ible to come up with a single model to cover them all. As such the attribu= tes were left in the spec but they are essentially implementation specific. As this use case came up I was thinking about this and to be honest I am no= t sure why we have these in the core spec to begin with. If we don=92t def= ine the semantics of the attributes we are not helping with interoperabilit= y and if anything we make it more difficult for clients and vendors to do w= hat they need for these attributes. I would like to propose we drop these t= wo attributes from the core spec and implementors either add these as their= specific extensions. This also has a very nice benefit that if at some po= int we come up with a common model to handle entitlements, we could define = an extension to the core user object with its semantics well defined for in= teroperability. Thoughts? Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D0011CD91AE255chrisphillipscanarieca_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2D335064BA219F43BFA91C1F3F179BA5@canarie.local> Content-Transfer-Encoding: quoted-printable
Hi,
Just catching this th= ead during summer holidays,  apologies if I didn't track it all and fo= r late replies over the next week or so.

To Kelly's question:<= /div>
What=92s t= he lesser of the evils?  To have an underspecified standard attribute = or a non-specified custom attribute that a bunch of folks will probably want to use?

I put for= ward that the lack of specificity is valuable. Anyone wanting to use their = own  groups, roles, and entitlements values can work within the core i= s better than always working in custom attributes and hoping your endpoints have them.

I believe= this highlights the question around WHERE you want to apply a policy ab= out what is contained in the attributes (to me, policy equates to constraints not written into the spec)
So where = does policy begin and end? I believe the usually answer is around who can c= onnect to your endpoints.  That's your permitter where your policy is = adhered to/enforced by someone/adopted by those who connect)

To look b= ack at another similar problem space to see what happened, take a look at t= he HTML spec(RFC1866) around the forms section 8.
It doesn'= t specify valid names nor valid values for form fields.
The stren= gth of this is that it has allowed any arbitrary combinations that were not= thought of when the spec was written. It was prescriptive 'enough'.=

In one respect, SCIM = is much like the HTML spec but for identity data.
Prescriptive enough a= s a specification, but open ended  enough to allow flexibility.

Moving things around = with respect to roles, groups, and entitlements was in ticket #11[1] and wa= s closed as 'won't fix. 
 I (subjectively= ) think was due to lack of sufficient discussion about the commen= ts raised in the ticket due to larger fish to fry in other tickets.

Now that some of the = other items are behind us, and this topic is resurfacing, maybe now is the = time to dig a bit deeper to some of the points..?

Chris.



Other items related t= o this thread:

Should attributes lik= e this be collapsed?[2] 
Original use cases fo= r the attributes: [3]
One way entitlements = can be described: [4]





From: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Date: Thursday, 31 July, 2014 10:31= PM
To: "Morteza Ansari (moransar)= " <moransar@cisco.com>= , Ian Glazer <iglazer@salesfor= ce.com>
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] entitlements &a= mp; roles attributes

I=92m not sure that I would say th= at there is no interoperability.  The client just has to have some kno= wledge about what the server supports for values here (maybe through /Entitlements and /Roles extended resource types?).&nb= sp; Of course, the same values probably wouldn=92t work on both SF and Cisc= o servers.

 

I agree with you, though, that com= plex attributes are warranted for some cases of roles and entitlements.&nbs= p; I=92d be interested to hear from some of the folks that have implemented SCIM servers if they make use of these or = whether they would have any opposition to dropping them.

 

IIRC they were added because it wa= s thought that most SPs would have some notion of roles, entitlements, grou= ps, or some combination of them, and that if they were left out of the schema that there would be more interop = problems because everyone would have custom extensions for these.


What=92s the lesser of the evils?  To have an underspecified standard = attribute or a non-specified custom attribute that a bunch of folks will pr= obably want to use?

 

From: scim [m= ailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Thursday, July 31, 2014 6:31 PM
To: Ian Glazer
Cc: scim@ietf.org
Subject: Re: [scim] entitlements & roles attributes

 

I don=92t think there is any impact as ther= e is no interoperability possible given the semantics of the attributes are= undefined. How could a client provision a value for this attribute if the definition of that value is different fr= om SF to Cisco to the next vendor?

 

 

Cheers,

Morteza

 

From: Ian Glazer <= iglazer@salesforce.com>
Date: Thursday, July 31, 2014 at 6:59 PM
To: Morteza Ansari <moransa= r@cisco.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] entitlements & roles attributes

 

A fine can of worms you've cracked into ;-)

 

I totally understand the need for complex a= ttributes for roles. But I am little worried about the implications of drop= ping them from the core spec. Any thoughts on what the impact would be?

 <= /o:p>

On Thu, Jul 31, 2014 at 6:46 PM, Morteza An= sari (moransar) <moransar@cisco.com> wrote:

Speaking as an implementer:

 

In our implementation, we have a new use ca= se where we need the entitlement and roles attributes to be complex. This i= s for cases where a user has an entitlement to a service with further qualifier.  Similarly for the roles attribu= te there are cases where a simple string is not sufficient and role may req= uire additional parameters and a complex object would nicely solve the prob= lem.

 

The spec is very vague on these two attribu= tes intentionally because the authorization model at various vendors are so= different that it seemed impossible to come up with a single model to cover them all.  As such the attrib= utes were left in the spec but they are essentially implementation specific= .

 

As this use case came up I was thinking abo= ut this and to be honest I am not sure why we have these in the core spec t= o begin with.  If we don=92t define the semantics of the attributes we are not helping with interoperability and i= f anything we make it more difficult for clients and vendors to do what the= y need for these attributes. I would like to propose we drop these two attr= ibutes from the core spec and implementors either add these as their specific extensions.  This also has a very = nice benefit that if at some point we come up with a common model to handle= entitlements, we could define an extension to the core user object with it= s semantics well defined for interoperability.

 

Thoughts?

 

 

Cheers,

Morteza 


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



 

--

Ian Glazer

Senior Director, Identity=

+1 202 255 3166

 --_000_D0011CD91AE255chrisphillipscanarieca_-- From nobody Fri Aug 1 09:39:01 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5661A0169 for ; Fri, 1 Aug 2014 09:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOTPh28MAw5a for ; Fri, 1 Aug 2014 09:38:58 -0700 (PDT) Received: from canmail.canarie.ca (canmail.canarie.ca [205.189.33.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE2F1A028B for ; Fri, 1 Aug 2014 09:38:58 -0700 (PDT) Received: from THUNDERCHIEF.canarie.local (192.168.1.17) by Thunderchief.canarie.local (192.168.1.17) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 1 Aug 2014 12:38:39 -0400 Received: from THUNDERCHIEF.canarie.local ([::1]) by Thunderchief.canarie.local ([::1]) with mapi id 15.00.0775.031; Fri, 1 Aug 2014 12:38:39 -0400 From: Chris Phillips To: "scim@ietf.org WG" Thread-Topic: [IDM] Grouper v2.2 released! Thread-Index: AQHPnQx08LlJHJSeSkuFMvuApbxa/5u8E/yA Date: Fri, 1 Aug 2014 16:38:38 +0000 Message-ID: References: <53BFE730.8060900@uchicago.edu> In-Reply-To: <53BFE730.8060900@uchicago.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [24.246.9.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <64F48D4056435C4DB6256927C8C5FD29@canarie.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/E13ql51V4Trx6FQ2HMXGCybSo0A Subject: [scim] FW: [IDM] Grouper v2.2 released! X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:39:00 -0000 Just passing on some info about tools integrating with SCIM.. A few weeks ago, Internet2 announced an update to their group management tool 'Grouper' with SCIM support. If you are looking for a tool to deal specifically with managing groups take a moment to check it out. While this release was in the last few weeks, you can catch some presentation material at the inCommon IAMOnline sessions here: http://www.incommon.org/iamonline/ Specifically the March 2013 session was recorded in Adobe Connect as well as PDFs of the presentations for the topic titled: Three Campus Case Studies of Managing Access with Grouper (recorded March 13, 2013) Chris. On 14-07-11 9:31 AM, "Tom Barton" wrote: >Dear Colleagues, > >On behalf of the Grouper team, I am very pleased to announce the release >of Grouper v2.2, which includes a reimagined Grouper User Interface, >including much-improved ease of use, mobile-friendly features, the use >of "favorites," easy tracking of all the groups an individual belongs >to, and more. In addition, the new Grouper UI uses responsive web >design, reducing barriers for people with disabilities. > >Other significant new Grouper v2.2 features include configuration >overlay files for easier deployment and upgrading, integration with >System for Cross-domain Identity Management (SCIM), and the ability to >tag folders and groups to create "services" in Grouper. > >We want to thank the many people in the Grouper community who provided >valuable input for this release, especially to help us understand what >was most important to accomplish for the new UI. We look forward to >continuing that dialog as you send us your feedback from your v2.2 >deployment. > >For further details about the Grouper v2.2 release, to download the >software and release notes, for upgrade instructions, and a link to a >Grouper demo, please visit > >https://spaces.internet2.edu/display/Grouper/Grouper+Downloads. > >Thanks, >Tom, on behalf of Chris, Shilen, Dave, and Emily > >--=20 >Tom Barton >Senior Director for Architecture, Integration, and Security >Chief Information Security Officer >IT Services >University of Chicago >+1 773 834 1700 From nobody Fri Aug 1 10:02:36 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7B1A0051 for ; Fri, 1 Aug 2014 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V-u-H6Q0CUH for ; Fri, 1 Aug 2014 10:02:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3C01B27A3 for ; Fri, 1 Aug 2014 10:02:14 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s71H2BJ5000970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Aug 2014 17:02:12 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71H2A8n015437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Aug 2014 17:02:11 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71H2AhM026499; Fri, 1 Aug 2014 17:02:10 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Aug 2014 10:02:08 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C30FFB3-4E08-48F9-8CEF-2D5E14F3009A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Fri, 1 Aug 2014 10:02:07 -0700 Message-Id: <4094C251-ECF9-40EB-9725-D9873AD1C84B@oracle.com> References: <9aa56a2d1a8443e38705653f40a51997@BN1PR04MB392.namprd04.prod.outlook.com> To: Chris Phillips X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/t8e0dBTn2ZP1N4WIzGrGJshJKMo Cc: "scim@ietf.org" Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:02:34 -0000 --Apple-Mail=_4C30FFB3-4E08-48F9-8CEF-2D5E14F3009A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1. Nice analysis. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 1, 2014, at 9:25 AM, Chris Phillips = wrote: > Hi, > Just catching this thead during summer holidays, apologies if I = didn't track it all and for late replies over the next week or so. >=20 > To Kelly's question: > What=92s the lesser of the evils? To have an underspecified standard = attribute or a non-specified custom attribute that a bunch of folks will = probably want to use? >=20 > I put forward that the lack of specificity is valuable. Anyone wanting = to use their own groups, roles, and entitlements values can work within = the core is better than always working in custom attributes and hoping = your endpoints have them. >=20 > I believe this highlights the question around WHERE you want to apply = a policy about what is contained in the attributes (to me, policy = equates to constraints not written into the spec) > So where does policy begin and end? I believe the usually answer is = around who can connect to your endpoints. That's your permitter where = your policy is adhered to/enforced by someone/adopted by those who = connect) >=20 > To look back at another similar problem space to see what happened, = take a look at the HTML spec(RFC1866) around the forms section 8. > It doesn't specify valid names nor valid values for form fields. > The strength of this is that it has allowed any arbitrary combinations = that were not thought of when the spec was written. It was prescriptive = 'enough'. >=20 > In one respect, SCIM is much like the HTML spec but for identity data. > Prescriptive enough as a specification, but open ended enough to = allow flexibility. >=20 > Moving things around with respect to roles, groups, and entitlements = was in ticket #11[1] and was closed as 'won't fix.=20 > I (subjectively) think was due to lack of sufficient discussion about = the comments raised in the ticket due to larger fish to fry in other = tickets. >=20 > Now that some of the other items are behind us, and this topic is = resurfacing, maybe now is the time to dig a bit deeper to some of the = points..? >=20 > Chris. >=20 >=20 >=20 > Other items related to this thread: >=20 > Should attributes like this be collapsed?[2]=20 > Original use cases for the attributes: [3] > One way entitlements can be described: [4] >=20 >=20 > [1] http://trac.tools.ietf.org/wg/scim/trac/ticket/11 > [2] https://www.ietf.org/mail-archive/web/scim/current/msg00237.html > [3] = http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6? > [4] = https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir= -eduperson-201203.html#eduPersonEntitlement >=20 >=20 >=20 > From: Kelly Grizzle > Date: Thursday, 31 July, 2014 10:31 PM > To: "Morteza Ansari (moransar)" , Ian Glazer = > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes >=20 > I=92m not sure that I would say that there is no interoperability. = The client just has to have some knowledge about what the server = supports for values here (maybe through /Entitlements and /Roles = extended resource types?). Of course, the same values probably wouldn=92t= work on both SF and Cisco servers. > =20 > I agree with you, though, that complex attributes are warranted for = some cases of roles and entitlements. I=92d be interested to hear from = some of the folks that have implemented SCIM servers if they make use of = these or whether they would have any opposition to dropping them. > =20 > IIRC they were added because it was thought that most SPs would have = some notion of roles, entitlements, groups, or some combination of them, = and that if they were left out of the schema that there would be more = interop problems because everyone would have custom extensions for = these. >=20 > What=92s the lesser of the evils? To have an underspecified standard = attribute or a non-specified custom attribute that a bunch of folks will = probably want to use? > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari = (moransar) > Sent: Thursday, July 31, 2014 6:31 PM > To: Ian Glazer > Cc: scim@ietf.org > Subject: Re: [scim] entitlements & roles attributes > =20 > I don=92t think there is any impact as there is no interoperability = possible given the semantics of the attributes are undefined. How could = a client provision a value for this attribute if the definition of that = value is different from SF to Cisco to the next vendor? > =20 > =20 > Cheers, > Morteza > =20 > From: Ian Glazer > Date: Thursday, July 31, 2014 at 6:59 PM > To: Morteza Ansari > Cc: "scim@ietf.org" > Subject: Re: [scim] entitlements & roles attributes > =20 > A fine can of worms you've cracked into ;-) > =20 > I totally understand the need for complex attributes for roles. But I = am little worried about the implications of dropping them from the core = spec. Any thoughts on what the impact would be? > =20 >=20 > On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) = wrote: > Speaking as an implementer: > =20 > In our implementation, we have a new use case where we need the = entitlement and roles attributes to be complex. This is for cases where = a user has an entitlement to a service with further qualifier. = Similarly for the roles attribute there are cases where a simple string = is not sufficient and role may require additional parameters and a = complex object would nicely solve the problem. > =20 > The spec is very vague on these two attributes intentionally because = the authorization model at various vendors are so different that it = seemed impossible to come up with a single model to cover them all. As = such the attributes were left in the spec but they are essentially = implementation specific. > =20 > As this use case came up I was thinking about this and to be honest I = am not sure why we have these in the core spec to begin with. If we = don=92t define the semantics of the attributes we are not helping with = interoperability and if anything we make it more difficult for clients = and vendors to do what they need for these attributes. I would like to = propose we drop these two attributes from the core spec and implementors = either add these as their specific extensions. This also has a very = nice benefit that if at some point we come up with a common model to = handle entitlements, we could define an extension to the core user = object with its semantics well defined for interoperability. > =20 > Thoughts? > =20 > =20 > Cheers, > Morteza=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_4C30FFB3-4E08-48F9-8CEF-2D5E14F3009A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1. =  Nice analysis.


On Aug 1, 2014, at 9:25 AM, Chris Phillips = <Chris.Phillips@canarie.ca>= ; wrote:

Hi,
Just catching this thead during summer = holidays,  apologies if I didn't track it all and for late replies = over the next week or so.

To Kelly's question:
What=92s the lesser = of the evils?  To have an underspecified standard attribute or a = non-specified custom attribute that a bunch of folks will probably want to use?

I put = forward that the lack of specificity is valuable. Anyone wanting to use = their own  groups, roles, and entitlements values can work within = the core is better than always working in custom attributes and hoping your endpoints have them.

I = believe this highlights the question around WHERE you want to = apply a policy about what is contained in the attributes (to me, = policy equates to constraints not written into the spec)
So = where does policy begin and end? I believe the usually answer is around = who can connect to your endpoints.  That's your permitter where = your policy is adhered to/enforced by someone/adopted by those who connect)

To = look back at another similar problem space to see what happened, take a = look at the HTML spec(RFC1866) around the forms section 8.
It = doesn't specify valid names nor valid values for form = fields.
The = strength of this is that it has allowed any arbitrary combinations that = were not thought of when the spec was written. It was prescriptive = 'enough'.

In one respect, SCIM is much like the = HTML spec but for identity data.
Prescriptive enough as a specification, = but open ended  enough to allow flexibility.

Moving things around with respect to = roles, groups, and entitlements was in ticket #11[1] and was closed as = 'won't fix. 
 I (subjectively) think was = due to lack of sufficient discussion about the comments raised in = the ticket due to larger fish to fry in other tickets.

Now that some of the other items are = behind us, and this topic is resurfacing, maybe now is the time to dig a = bit deeper to some of the points..?

Chris.



Other items related to this = thread:

Should attributes like this be = collapsed?[2] 
Original use cases for the attributes: = [3]
One way entitlements can be described: = [4]






I=92m not sure that I would say that there is no = interoperability.  The client just has to have some knowledge about = what the server supports for values here (maybe through /Entitlements and /Roles extended resource = types?).  Of course, the same values probably wouldn=92t work on = both SF and Cisco servers.
I agree with you, though, that complex attributes are = warranted for some cases of roles and entitlements.  I=92d be = interested to hear from some of the folks that have implemented SCIM servers if they make use of these = or whether they would have any opposition to dropping them.
IIRC they were added because it was thought that most SPs = would have some notion of roles, entitlements, groups, or some = combination of them, and that if they were left out of the schema that there would be more = interop problems because everyone would have custom extensions for = these.

What=92s the lesser of the evils?  To have an underspecified = standard attribute or a non-specified custom attribute that a bunch of = folks will probably want to use?
 
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Thursday, July 31, 2014 6:31 PM
To: Ian Glazer
Cc: scim@ietf.org
Subject: Re: [scim] entitlements & roles = attributes
 
I don=92t think there is any impact = as there is no interoperability possible given the semantics of the = attributes are undefined. How could a client provision a value for this attribute if the definition of that value is different = from SF to Cisco to the next vendor?
 
 
Cheers,
Morteza
 
From: Ian Glazer <iglazer@salesforce.com>
Date: Thursday, July 31, 2014 at 6:59 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] entitlements & roles = attributes
 
A fine can of worms you've cracked = into ;-)
 
I totally understand the need for = complex attributes for roles. But I am little worried about the = implications of dropping them from the core spec. Any thoughts on what the impact would be?

 

On Thu, Jul 31, 2014 at 6:46 PM, = Morteza Ansari (moransar) <moransar@cisco.com> = wrote:
Speaking as an = implementer:
 
In our implementation, we have a new = use case where we need the entitlement and roles attributes to be = complex. This is for cases where a user has an entitlement to a service with further qualifier.  Similarly for the roles = attribute there are cases where a simple string is not sufficient and = role may require additional parameters and a complex object would nicely = solve the problem.
 
The spec is very vague on these two = attributes intentionally because the authorization model at various = vendors are so different that it seemed impossible to come up with a single model to cover them all.  As such the = attributes were left in the spec but they are essentially implementation = specific.
 
As this use case came up I was = thinking about this and to be honest I am not sure why we have these in = the core spec to begin with.  If we don=92t define the semantics of the attributes we are not helping with interoperability = and if anything we make it more difficult for clients and vendors to do = what they need for these attributes. I would like to propose we drop = these two attributes from the core spec and implementors either add these as their specific extensions.  This also has a = very nice benefit that if at some point we come up with a common model = to handle entitlements, we could define an extension to the core user = object with its semantics well defined for = interoperability.
 
Thoughts?
 
 
Cheers,
Morteza 


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



 
--
Ian Glazer
Senior Director, = Identity
+1 202 255 = 3166
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_4C30FFB3-4E08-48F9-8CEF-2D5E14F3009A-- From nobody Fri Aug 1 14:32:24 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB71A0108 for ; Fri, 1 Aug 2014 14:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp9mjkUSaDn0 for ; Fri, 1 Aug 2014 14:32:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802C31A0084 for ; Fri, 1 Aug 2014 14:32:17 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s71LWFJd024709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Aug 2014 21:32:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71LWFCx021113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 21:32:15 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71LWFWi004052; Fri, 1 Aug 2014 21:32:15 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Aug 2014 14:32:14 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_590B748E-CB75-495D-B855-9F2D1433EE03" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Fri, 1 Aug 2014 14:32:12 -0700 Message-Id: <2C6A5504-C911-4D6C-9F54-820C2D12CF7B@oracle.com> References: To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/tlzLDuUsVyVUmBfFUWK8REVNbBI Cc: "scim@ietf.org" Subject: Re: [scim] API comments section 3.5 to end X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 21:32:21 -0000 --Apple-Mail=_590B748E-CB75-495D-B855-9F2D1433EE03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, There are some important considerations here. Please see commend below: Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 31, 2014, at 8:13 PM, Kelly Grizzle = wrote: > Last set of comments for the API doc. > =20 > > 3.5 status A complex type that contains information about the = success > > or failure of one operation within the bulk job. = REQUIRED in a > > response. > >=20 > > code The HTTP response code that would have been = returned if a > > a single HTTP request would have been used. = REQUIRED. > >=20 > > description A human readable error message. REQUIRED = when an > > error occurred. > =20 > Should the bulk response status attribute be updated to be more in = line with the updated error response (status, scimType, and detail = sub-attributes)? I am going to suggest we change =93status=94 back to correspond with = HTTP Status. We should also have a =93response=94 block which contains the optional = payload response. In the case of an error condition, the normal http = response body is included in =93response=94 which would include the = error JSON message e.g. =93response=94:{ "schemas": ["urn:scim:api:messages:2.0:Error"], "scimType":"mutability" "detail":"Attribute 'id' is readOnly", "status":"400" }, =93status=94:=94400" =20 =3D=3D=3D> Question. Do we want to make the server give the normal JSON = responses for all operations and provide them in response? E.g. after a = POST show the record as processed by the service provider. > =20 > =20 > > 3.5 If a bulk job is processed successfully the HTTP response = code 200 OK > > MUST be returned, otherwise an appropriate HTTP error code = MUST be > > returned. > =20 > A 200 is returned even if some of the operations failed, correct? = Might be worth clarifying. Yes. I think so. The only reason not to return 200 would be a syntax = error in the request, or other fatal error condition. In the context of a bulk request, an individual transaction failure is = indicated within the status/response for the operation. > =20 > =20 > > 3.5 The client MAY override > > this behavior by specifying a value for failOnErrors attribute. > =20 > Change to "for the failOnErrors attribute=94. Ok. > =20 > =20 > > 3.5 A location attribute that includes the > > resource's end point MUST be returned for all operations = excluding > > failed POSTs. > =20 > Typo. Change "end point" to "endpoint". > =20 Ok > =20 > > 3.5 The following example shows how to add, update, and remove a = user. > > ... > > The service provider returns the following response. > > ... > > { > > "location": = "https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a", > > "method": "POST", > > "bulkId": "qwerty", > > "version": "W\/\"oY4m4wn58tkVjJxK\"", > > "status": { > > "code": "201" > > } > > }, > =20 > The text above says the following regarding creating a new resource: > =20 > the service provider MUST return the same bulkId together with the = newly > created resource. > =20 > It seems like the example response should include the full resource. = Would this fit in the "data" sub-attribute? If so, the description of = the "data" sub-attribute should be changed to indicate this. Same = comment for other bulk examples that contain POSTs. See comment above. > =20 > =20 > > 3.5 The following example creates a User with the userName 'Alice' = and a > > Group with the displayName 'Tour Guides' with Alice as a = member. > > ... > > "members": [ > > { > > "type": "user", > > "value": "bulkId:qwerty" > > } > > ] > =20 > The type should be "User" since the canonical values for type on = member are capitalized (see schema in section 11.7 of schemas draft). ok > =20 > =20 > > 3.5 "members": [ > > { > > "type": "group", > =20 > Same comment as above ... need to capitalize "Group". > =20 >=20 ok > =20 > > 3.5 The following example the client sent a request exceeding the = service > > provider's max payload size of 1 megabyte. > > ... > > HTTP/1.1 413 Request Entity Too Large > > Content-Type: application/scim+json > > Location: https://example.com/v2/Bulk/yfCrVJhFIJagAHj8 > =20 > This response includes a Location header with a unique ID. Do bulk = requests have unique IDs and locations? If not, the location should be = removed I think the spec should be ambiguous on the point and thus location = could be removed. > =20 > =20 > > 3.6 MAY specify the desired response data > > format via an HTTP "Accept" header ( Section 5.3.2 [RFC7231] ); = e.g., > > "Accept: application/scim+json" or via URI suffix; e.g., > >=20 > > GET /Users/2819c223-7f76-453a-919d-413861904646.scim > =20 > It seems like we shouldn't need to support URI suffixes anymore since = JSON is the only supported format. My approach here was to comply with mime type registration. In reality = some may choose to implement other formats like XML even though we = haven=92t specified it. Or, a future SCIM extension might call for a = new format. This sets the foundation. I think it is fair to say JSON is the default (and currently only = supported method). Will try to think about the language a bit and try to get a better = balance. > =20 > =20 > > 3.7 The defaut attribute set are those attributes whose schema = have > =20 > Typo on "defaut". > =20 >=20 Got it > =20 > > 3.7 GET = /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName > > ... > > Accept: application/json > > ... > > HTTP/1.1 200 OK > > Content-Type: application/json > =20 > This example uses application/json for the Accept and Content-Type = headers. Should change this to application/scim+json. > =20 > =20 >=20 OK > > 3.10 The following attributes are defined inclusion in a SCIM error = response > > using a JSON body: > =20 > Not sure what the text is supposed to be here, but "defined inclusion" = doesn't make sense to me. Maybe =93The following attributes are = included in a SCIM error response using a JSON body=94? > =20 >=20 Should be: =93The following attributes are defined for a SCIM error response=85." > =20 > > 3.10 status > > The HTTP status value (e.g. 400). REQUIRED > =20 > We should indicate that this is an integer. >=20 Changed this to point to Section 6, RFC7231 (a 3 digit Integer). > =20 > > 3.10 Implementers SHOULD handle the identified errors as = described below > =20 > 307 and 308 statuses are not really errors. Should they be included = here? Agreed. I=92ve re-worked the title of the section and the text to = reflect that is it SCIM HTTP Status Code Handling > =20 > =20 > > 3.10 tooMany a filter such as "userName eq "*"" would return all = entries with a "userName" > =20 > The wildcard operator is not supported. This filter should be = "userName pr=94. d=92oh - fixed > =20 > =20 > > 3.12 Content-Type: application/json > =20 > Examples in this section are not using application/scim+json for = Content-Type. > =20 > =20 > > 6.2 A detialed error, > > "confidential_restricted" may be returned indicating the = request must > > be submitted using POST. > =20 > Typo on "detialed". Also, should this error code be made into a = scimType and use the camelCase convention used for other scimTypes? The = example in this section could be rewritten as: > =20 > { > "schemas": ["urn:scim:api:messages:2.0:Error"], > "scimType":"confidentialRestricted" > "detail":"Query filter involving 'name' is restricted or = confidential", > "status":403 > } > =20 >=20 check > =20 > > 7.1 SCIM services may be offered by web applications wishin to offer > =20 > Typo on "wishin=94. I=92m wishin=92 I was done! > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_590B748E-CB75-495D-B855-9F2D1433EE03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all,

There are some important considerations here. = Please see commend below:


On Jul 31, 2014, at 8:13 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Last set of comments = for the API doc.

 

> = 3.5  status  A complex type that contains information about = the success

>        &n= bsp;     or failure of one operation within the bulk = job.  REQUIRED in a

>        &n= bsp;     response.

> 

>        &n= bsp;     code  The HTTP response code that = would have been returned if a

>        &n= bsp;        a single HTTP request = would have been used.  REQUIRED.

> 

>        &n= bsp;     description  A human readable error = message.  REQUIRED when an

>        &n= bsp;        error = occurred.

 

Should the bulk response status attribute be updated = to be more in line with the updated error response (status, scimType, = and detail sub-attributes)?


I = am going to suggest we change =93status=94 back to correspond with HTTP = Status.




In = the context of a bulk request, an individual transaction failure is = indicated within the status/response for the operation.

 

 

> 3.5 = The client MAY override

>     this behavior by = specifying a value for failOnErrors attribute.

 

Change = to "for the failOnErrors = attribute=94.


Ok.

 

 

> 3.5 = A location attribute that includes the

>     resource's end point = MUST be returned for all operations excluding

>     failed = POSTs.

 

Typo.  Change "end point" to = "endpoint".

 

Ok

 

> = 3.5  The following example shows how to add, update, and remove a = user.

>      = ...

>      The service = provider returns the following response.

>      = ...

>         = {

>        &n= bsp;    "location": "https://example.com/v2/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",

>        &n= bsp;    "method": "POST",

>        &n= bsp;    "bulkId": "qwerty",

>        &n= bsp;    "version": = "W\/\"oY4m4wn58tkVjJxK\"",

>        &n= bsp;    "status": {

>        &n= bsp;        "code": = "201"

>        &n= bsp;    }

>         = },

 

The text above says the following regarding creating = a new resource:

 

  = the service provider MUST return the same bulkId together with the = newly

  created = resource.

 

It seems like the example response should include = the full resource.  Would this fit in the "data" = sub-attribute?  If so, the description of the "data" sub-attribute = should be changed to indicate this.  Same comment for other bulk = examples that contain POSTs.


See = comment above.

 

 

> = 3.5  The following example creates a User with the userName 'Alice' = and a

>      Group with the = displayName 'Tour Guides' with Alice as a member.

>      = ...

>        &n= bsp;   "members": [

>        &n= bsp;    {

>        &n= bsp;      "type": "user",

>        &n= bsp;      "value": = "bulkId:qwerty"

>        &n= bsp;    }

>        &n= bsp;  ]

 

The type should be "User" since the canonical values = for type on member are capitalized (see schema in section 11.7 of = schemas draft).

ok

 

 

> = 3.5            = "members": [

>        &n= bsp;      {

>        &n= bsp;        "type": = "group",

 

Same comment as above ... need to capitalize = "Group".

 


ok

 

> = 3.5  The following example the client sent a request exceeding the = service

>      provider's max = payload size of 1 megabyte.

>      = ...

>      HTTP/1.1 413 = Request Entity Too Large

>      Content-Type: = application/scim+json

>      Location: https://example.com/= v2/Bulk/yfCrVJhFIJagAHj8

 

This = response includes a Location header with a unique ID.  Do bulk = requests have unique IDs and locations?  If not, the location = should be removed


I think the = spec should be ambiguous on the point and thus location could be = removed.

 

 

> 3.6 = MAY specify the desired response data

>     format via an HTTP = "Accept" header ( Section 5.3.2 [RFC7231] ); e.g.,

>     "Accept: = application/scim+json" or via URI suffix; e.g.,

> 

>      GET = /Users/2819c223-7f76-453a-919d-413861904646.scim

 

It seems = like we shouldn't need to support URI suffixes anymore since JSON is the = only supported format.


My = approach here was to comply with mime type registration.  In = reality some may choose to implement other formats like XML even though = we haven=92t specified it.  Or, a future SCIM extension might call = for a new format.  This sets the = foundation.

I think it is fair to say JSON is = the default (and currently only supported = method).

Will try to think about the language a = bit and try to get a better balance.

 

 

> = 3.7   The defaut attribute set are those attributes whose = schema have

 

Typo on "defaut".

 


Got it

 

> = 3.7     GET = /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName

>         = ...

>         = Accept: application/json

>         = ...

>         = HTTP/1.1 200 OK

>         = Content-Type: application/json

 

This = example uses application/json for the Accept and Content-Type = headers.  Should change this to = application/scim+json.

 

 


OK

> = 3.10  The following attributes are defined inclusion in a SCIM = error response

>       using a = JSON body:

 

Not sure what the text is supposed to be here, but = "defined inclusion" doesn't make sense to me.  Maybe =93The = following attributes are included in a SCIM error response using a JSON = body=94?

 


Should be:

=93The following attributes = are defined for a SCIM error response=85."

 

> 3.10  status

>         = The HTTP status value (e.g. 400).  REQUIRED

 

We = should indicate that this is an = integer.


Changed this to = point to Section 6, RFC7231  (a 3 digit Integer).

 

> 3.10    Implementers SHOULD = handle the identified errors as described below

 

307 and = 308 statuses are not really errors.  Should they be included = here?


Agreed. I=92ve = re-worked the title of the section and the text to reflect that is it = SCIM HTTP Status Code Handling

 

 

> = 3.10  tooMany   a filter such as "userName eq "*"" would = return all entries with a "userName"

 

The = wildcard operator is not supported.  This filter should be = "userName pr=94.


d=92oh - = fixed

 

 

> = 3.12    Content-Type:  = application/json

 

Examples = in this section are not using application/scim+json for = Content-Type.

 

 

> = 6.2  A detialed error,

>      = "confidential_restricted" may be returned indicating the request = must

>      be submitted = using POST.

 

Typo on "detialed".  Also, should this error = code be made into a scimType and use the camelCase convention used for = other scimTypes?  The example in this section could be rewritten = as:

 

   {

     "schemas": = ["urn:scim:api:messages:2.0:Error"],

     = "scimType":"confidentialRestricted"

     "detail":"Query filter = involving 'name' is restricted or confidential",

     = "status":403

   = }

 


check

 

> 7.1 = SCIM services may be offered by web applications wishin to offer

 

Typo on = "wishin=94.


I=92m wishin=92 I = was done!

 

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

= --Apple-Mail=_590B748E-CB75-495D-B855-9F2D1433EE03-- From nobody Fri Aug 1 14:57:36 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6789F1A010F; Fri, 1 Aug 2014 14:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s02LBZCtHRMe; Fri, 1 Aug 2014 14:57:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F71A0084; Fri, 1 Aug 2014 14:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801215732.6930.1780.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 14:57:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Sr_jDoef6YFLFvChidN9tn0cXsQ Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-07.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 21:57:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Kelly Grizzle Phil Hunt Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-07.txt Pages : 64 Date : 2014-08-01 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON format. This schema is intended for exchange and use with cloud service providers. An HTTP protocol binding document is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 1 15:05:32 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ADD1B28C3; Fri, 1 Aug 2014 15:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPY1fwVdX37S; Fri, 1 Aug 2014 15:05:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F491B28B6; Fri, 1 Aug 2014 15:05:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801220500.6930.71385.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 15:05:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/k2tysG7yza0HRms8LYFn3WfoSlg Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-08.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:05:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management:Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-08.txt Pages : 71 Date : 2014-08-01 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in multi-domain based applications and services easier using HTTP Protocol. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 1 15:12:27 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83591B28B6 for ; Fri, 1 Aug 2014 15:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lcOx6qfgqGt for ; Fri, 1 Aug 2014 15:12:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE1E1A0175 for ; Fri, 1 Aug 2014 15:12:15 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s71MCDvK029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Aug 2014 22:12:14 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71MCCQl024599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Aug 2014 22:12:13 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s71MCCMd029245 for ; Fri, 1 Aug 2014 22:12:12 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Aug 2014 15:12:12 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_0EC9C9ED-166F-4932-85EF-4DD06831982D" Message-Id: Date: Fri, 1 Aug 2014 15:12:10 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/l2BXK0rHHNDa8Ln4_gYtqfIPAPs Subject: [scim] API 08 and Core Schema 07 drafts posted X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:12:22 -0000 --Apple-Mail=_0EC9C9ED-166F-4932-85EF-4DD06831982D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For your info, the core-schema and api drafts have been updated to = reflect all of the recently received comments, including those from our = Toronto meeting. https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ https://datatracker.ietf.org/doc/draft-ietf-scim-api/ A couple of editorial notes: * Bulk Requests - Kelly pointed out that the error responses were not = correct (based on the new detail error format) and asked if responses = should include the normal per operation response body. I have updated = the spec in a least disruptive fashion for now. That is to say, that = errors are provided in a =93response=94 attribute for each attribute and = the =93status=94 attribute is now a simple attribute reporting the HTTP = status code. For successful operation responses, the =93response=94 = attribute (holding the normal response body) remains optional. * IANA - I have not yet updated the IANA registry and schema namepsaces = per the Toronto meeting. The plan is that all Schema URIs will change = from urn:scim:=85 to urn:ietf:params:scim=85 Apologies, I will be away on vacation and will catch up on feedback late = next week. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_0EC9C9ED-166F-4932-85EF-4DD06831982D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 For = your info, the core-schema and api drafts have been updated to reflect = all of the recently received comments, including those from our Toronto = meeting.
<= a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-scim-api/">https://dat= atracker.ietf.org/doc/draft-ietf-scim-api/

A = couple of editorial notes:

* Bulk Requests - = Kelly pointed out that the error responses were not correct (based on = the new detail error format) and asked if responses should include the = normal per operation response body.  I have updated the spec in a = least disruptive fashion for now.  That is to say, that errors are = provided in a =93response=94 attribute for each attribute and the = =93status=94 attribute is now a simple attribute reporting the HTTP = status code. For successful operation responses, the =93response=94 = attribute (holding the normal response body) remains = optional.

* IANA - I have not yet updated the = IANA registry and schema namepsaces per the Toronto meeting. The plan is = that all Schema URIs will change from urn:scim:=85 to = urn:ietf:params:scim=85

Apologies, I will be = away on vacation and will catch up on feedback late next = week.

= --Apple-Mail=_0EC9C9ED-166F-4932-85EF-4DD06831982D-- From nobody Mon Aug 4 00:48:48 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB471B27E9 for ; Mon, 4 Aug 2014 00:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLneiDBhLzX1 for ; Mon, 4 Aug 2014 00:48:43 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5871A0AC3 for ; Mon, 4 Aug 2014 00:48:42 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id u10so4955417lbd.7 for ; Mon, 04 Aug 2014 00:48:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JDmjBHQxP/ci98ncYboDphxQRD0Lw+b4MTe2D94UT90=; b=m4H9zIdYUAO4sFUHO3mrFjYwFE7XnGTlhAXT0Njs6lINPpS1lirdbtC8aRoZT2j+dm tqDhRbzxLUjN1UZFY+LWJvuOEqKt6gVRC/TiAyiH7zR1wwZu+fUsPEuJ9b21AJJF+Gdl ETB5rxsLfwxYO1JRCTahNq+xegl0aCTeY7fYPnvvyn69imEc1o+S2V5prS0mrsao6J/3 9k3lx6CRSwG9mfVmN2APOypvP0OTJ4xcHyOwIhSjoCuPscDJ6aCtns9a2so/bgFiO48h h7v5Se+VjtWYQ2mLhI3SK315PpuebOk1SxmA/D5dskGzGbaucp2ExTm/Vtis9DAdVehU 8toA== X-Gm-Message-State: ALoCoQmxXiTQfC1z3Axs+DhdiKWpBSL30P03EWCWPfvBRKQDiAtWSnCp57GVoFMP8PPWHOFToZbz X-Received: by 10.152.115.162 with SMTP id jp2mr22065698lab.43.1407138520913; Mon, 04 Aug 2014 00:48:40 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id tj1sm26538926lbb.40.2014.08.04.00.48.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Aug 2014 00:48:40 -0700 (PDT) Message-ID: <53DF3AD8.7020009@mnt.se> Date: Mon, 04 Aug 2014 09:48:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/iP4NLNBc7tPRDUUcxj7qxWk7gT4 Subject: Re: [scim] entitlements & roles attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 07:48:46 -0000 On 2014-08-01 00:59, Ian Glazer wrote: > A fine can of worms you've cracked into ;-) > > I totally understand the need for complex attributes for roles. But I am > little worried about the implications of dropping them from the core > spec. Any thoughts on what the impact would be? > I agree. I'd say we should keep entitlement explicitly a string value and leave more complex ACIs for extensions. As an aside there have been several successful deployments of parametrized ACIs that nevertheless are represented as strings. One such is http://www.swami.se/download/18.248ad5af12aa8136533800044/gmai.pdf and another is MIT PERMIT. Most of them seem to fall into a same subject-object-constraints. From nobody Thu Aug 7 09:38:12 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0E1B2DD2 for ; Thu, 7 Aug 2014 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_-Z_PIviFY2 for ; Thu, 7 Aug 2014 09:38:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5FF1B2DC9 for ; Thu, 7 Aug 2014 09:38:03 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s77Gc1AM018128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Aug 2014 16:38:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s77Gc1Z6020597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2014 16:38:01 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s77Gbxer010158 for ; Thu, 7 Aug 2014 16:38:00 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Aug 2014 09:37:59 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_FF05AF3D-244F-41E1-95C1-2898A3B6EAB2" Message-Id: <859DA2C9-8DFE-4A05-B988-585B6CA6EC8D@oracle.com> Date: Thu, 7 Aug 2014 09:37:58 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/H9DBE_WfFeuA7Pzxtc_yJCzv4Bs Subject: [scim] URI errors in latest drafts X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:38:11 -0000 --Apple-Mail=_FF05AF3D-244F-41E1-95C1-2898A3B6EAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It has been pointed out to me that there are 4 instances of URNs = urn:scim:api:messages:2.0:User in the API draft. Not sure how that = happened and apologize for any confusion. These should all be: urn:scim:schemas:core:2.0:User The rule of thumb, if it is a data element, then the prefix is = urn:scim:schemas, if it is a protocol element, it is urn:scim:api NOTE: we also discussed in Toronto that we will change from urn:scim = namespace to urn:ietf:params namespace. So urn:scim:api:messages:2.0:BulkRequest will become something like = urn:ietf:params:scim:api:messages:2.0:BulkRequest I plan to make this correction in the next draft. Regards, Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_FF05AF3D-244F-41E1-95C1-2898A3B6EAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It has = been pointed out to me that there are 4 instances of = URNs urn:scim:api:messages:2.0:User in the API draft.  Not = sure how that happened and apologize for any = confusion.

These should all = be: urn:scim:schemas:core:2.0:User

The = rule of thumb, if it is a data element, then the prefix is = urn:scim:schemas,  if it is a protocol element, it is = urn:scim:api

NOTE: we also discussed in = Toronto that we will change from urn:scim namespace to urn:ietf:params = namespace.

So urn:scim:api:messages:2.0:BulkRequest will become something = like urn:ietf:params:scim:api:messages:2.0:BulkRequest
<= br>
I plan to make this correction in the next = draft.

Regards,

= --Apple-Mail=_FF05AF3D-244F-41E1-95C1-2898A3B6EAB2-- From nobody Thu Aug 7 09:59:49 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDECD1B2E94 for ; Thu, 7 Aug 2014 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72kzf0Ind4Qz for ; Thu, 7 Aug 2014 09:59:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660991B2E80 for ; Thu, 7 Aug 2014 09:59:42 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s77GxfQL011340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Aug 2014 16:59:41 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s77Gxe1M001279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2014 16:59:40 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s77Gxbu6001265 for ; Thu, 7 Aug 2014 16:59:38 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Aug 2014 09:59:37 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_EFD99BDE-2F2E-437D-AC80-6E838A5CF695" Message-Id: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> Date: Thu, 7 Aug 2014 09:59:35 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Wo7c0F2xE8VWmaBni3qyD0xti1I Subject: [scim] Another URN issue X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:59:47 -0000 --Apple-Mail=_EFD99BDE-2F2E-437D-AC80-6E838A5CF695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The example on page 19 of the API document is wrong. { "totalResults":100, "itemsPerPage":10, "startIndex":1, "schemas":["urn:scim:api:messages:2.0"], "Resources":[{ ... }] } Should be: { "totalResults":100, "itemsPerPage":10, "startIndex":1, "schemas":["urn:scim:api:messages:2.0:ListResponse"], "Resources":[{ ... }] } Note also. We=92ve kept ListResponse for consistency reasons. Should we = change this to be =93SearchResponse=94 so that it is consistent with the = other URIs (e.g. urn:scim:api:messages:2.0:SearchRequest =97 only used = in the POST search variant)? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_EFD99BDE-2F2E-437D-AC80-6E838A5CF695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = example on page 19 of the API document is wrong.
   {
     "totalResults":100,
     "itemsPerPage":10,
     "startIndex":1,
     "schemas":["urn:scim:api:messages:2.0"],
     "Resources":[{
       ...
     }]
   }

Should be:
   {
     "totalResults":100,
     "itemsPerPage":10,
     "startIndex":1,
     "schemas":["urn:scim:api:messages:2.0:ListResponse"],
     "Resources":[{
       ...
     }]
   }

Note also. We=92ve kept = ListResponse for consistency reasons.  Should we change this to be = =93SearchResponse=94 so that it is consistent with the other URIs = (e.g. urn:scim:api:messages:2.0:SearchRequest =97 only used in the POST search = variant)?


= --Apple-Mail=_EFD99BDE-2F2E-437D-AC80-6E838A5CF695-- From nobody Thu Aug 7 12:49:57 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C899F1A04B1 for ; Thu, 7 Aug 2014 12:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRZB7zAOnOaW for ; Thu, 7 Aug 2014 12:49:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6224B1A0417 for ; Thu, 7 Aug 2014 12:49:54 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 19:49:51 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 19:49:51 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] Another URN issue Thread-Index: AQHPsmECO90M/mZYh02KtA9I644uxZvFjHxg Date: Thu, 7 Aug 2014 19:49:50 +0000 Message-ID: References: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> In-Reply-To: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 50C76C80007D1250C76DCD x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(79102001)(15975445006)(107886001)(19617315012)(66066001)(64706001)(74662001)(74502001)(101416001)(19625215002)(81542001)(77982001)(77096002)(76576001)(86362001)(81342001)(4396001)(46102001)(33646002)(16236675004)(76482001)(74316001)(80022001)(107046002)(15202345003)(31966008)(83072002)(76176999)(87936001)(19300405004)(2656002)(85852003)(83322001)(19580395003)(19580405001)(21056001)(54356999)(106356001)(85306004)(16601075003)(92566001)(106116001)(50986999)(20776003)(99396002)(99286002)(105586002)(95666004)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b38b041cfed14e38b950940635cca47eBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZYc5GTIpeA6u54SvrwDZu-3quPQ Subject: Re: [scim] Another URN issue X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 19:49:56 -0000 --_000_b38b041cfed14e38b950940635cca47eBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > We've kept ListResponse for consistency reasons. Should we change this t= o be > "SearchResponse" so that it is consistent with the other URIs I would vote to keep ListResponse since this may be a response to a simple = GET /Users without any search filters applied. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, August 07, 2014 12:00 PM To: SCIM WG Subject: [scim] Another URN issue The example on page 19 of the API document is wrong. { "totalResults":100, "itemsPerPage":10, "startIndex":1, "schemas":["urn:scim:api:messages:2.0"], "Resources":[{ ... }] } Should be: { "totalResults":100, "itemsPerPage":10, "startIndex":1, "schemas":["urn:scim:api:messages:2.0:ListResponse"], "Resources":[{ ... }] } Note also. We've kept ListResponse for consistency reasons. Should we chan= ge this to be "SearchResponse" so that it is consistent with the other URIs= (e.g. urn:scim:api:messages:2.0:SearchRequest - only used in the POST sear= ch variant)? Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_b38b041cfed14e38b950940635cca47eBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> We’ve kept ListResponse for consistency reasons.  Should = we change this to be

> “SearchResponse” so that it is cons= istent with the other URIs

 <= /p>

I would vote to keep List= Response since this may be a response to a simple GET /Users without any se= arch filters applied.

 <= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, August 07, 2014 12:00 PM
To: SCIM WG
Subject: [scim] Another URN issue

 

The example on page 19 of the API document is wrong.= 

&n=
bsp;  {
&n=
bsp;    "totalResults":100,

&n=
bsp;    "itemsPerPage":10,


&n=
bsp;    "startIndex":1,


&n=
bsp;    "schemas":["urn:scim:api:messages:2.0=
"],


&n=
bsp;    "Resources":[{


&n=
bsp;      ...


&n=
bsp;    }]


&n=
bsp;  }

 

Should be:

&n=
bsp;  {
&n=
bsp;    "totalResults":100,

&n=
bsp;    "itemsPerPage":10,


&n=
bsp;    "startIndex":1,


&n=
bsp;    "schemas":["urn:scim:api:messages:2.0=
:ListResponse"],


&n=
bsp;    "Resources":[{


&n=
bsp;      ...


&n=
bsp;    }]


&n=
bsp;  }

 

Note also. We’ve kept ListResponse for consist= ency reasons.  Should we change this to be “SearchResponse”= ; so that it is consistent with the other URIs (e.g. urn:scim:api:mess= ages:2.0:SearchRequest — only used in the POST search varia= nt)?

 

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_b38b041cfed14e38b950940635cca47eBN1PR04MB392namprd04pro_-- From nobody Thu Aug 7 13:42:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1E1A031D for ; Thu, 7 Aug 2014 13:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDePYbYcSuvF for ; Thu, 7 Aug 2014 13:42:24 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5611A00D4 for ; Thu, 7 Aug 2014 13:42:23 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so3180938lbv.30 for ; Thu, 07 Aug 2014 13:42:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3heydlXW/OCEtRymNeHM3Qoz/bBdAOGpexXp8T6OjO4=; b=JsszPe/pXs3pWHjKV3ChBRWGxP5Mg+WRMp4B6oLGPzoHKFbHpBuJB4n+FGMCbrvyG+ DLscpIV8t3GwAuYXgCxqhaE9167pfGZSJIr+FrGukk7H6wyhB7++3f2W/z9FfUgmI+Ze vVwJxj+PqWsRkAF/X7oP5Bq5CzWQ3NZuOkEJjMgLxhNmEeFEi1dvOrLrl7f+y3387aw0 8+10Cp2S3qr4qDUzRKPx7DemB8GnG6LklOWD4F2SMTCyZHlvMLGSK4ab8L6gzgz6FR1B jbK+leXPwIS4eHB67TA6ThrfmMISmih/3S7x7i22HFcsRWh/DrX3vt00rgDBfcubCHdT YYiw== X-Gm-Message-State: ALoCoQn1QcGO7nJJIUu8neL3IinPxBUMYBoJcJrgdO76XHmo8WVSsC/M9pVn4JJeibYHqFxVBsLm X-Received: by 10.112.137.97 with SMTP id qh1mr17623225lbb.57.1407444142169; Thu, 07 Aug 2014 13:42:22 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id j20sm1285425lbo.3.2014.08.07.13.42.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2014 13:42:21 -0700 (PDT) Message-ID: <53E3E4AD.5050102@mnt.se> Date: Thu, 07 Aug 2014 22:42:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: scim@ietf.org References: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> In-Reply-To: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HaCwHRMvIgjEJkBQikrilxAh1KM Subject: Re: [scim] Another URN issue X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:42:26 -0000 On 2014-08-07 18:59, Phil Hunt wrote: > The example on page 19 of the API document is wrong. > > { > "totalResults":100, > "itemsPerPage":10, > "startIndex":1, > "schemas":["urn:scim:api:messages:2.0"], Thats another urn that needs changing. > "Resources":[{ > ... > }] > } > > > Should be: > > { > "totalResults":100, > "itemsPerPage":10, > "startIndex":1, > "schemas":["urn:scim:api:messages:2.0:ListResponse"], > "Resources":[{ > ... > }] > } > > > Note also. We’ve kept ListResponse for consistency reasons. Should we > change this to be “SearchResponse” so that it is consistent with the > other URIs (e.g. urn:scim:api:messages:2.0:SearchRequest — only used in > the POST search variant)? > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Thu Aug 7 13:50:16 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426FF1B27F8 for ; Thu, 7 Aug 2014 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU1tlKrHHcnQ for ; Thu, 7 Aug 2014 13:50:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97421A035C for ; Thu, 7 Aug 2014 13:50:12 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s77KoBmH023666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Aug 2014 20:50:12 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s77Ko9ew004751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Aug 2014 20:50:11 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s77Ko959006652; Thu, 7 Aug 2014 20:50:09 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Aug 2014 13:50:08 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <53E3E4AD.5050102@mnt.se> Date: Thu, 7 Aug 2014 13:50:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26255C18-8EF5-41E5-8821-6BE3395EFBE4@oracle.com> References: <2C30DDF1-8F31-4A0F-92BA-FB960FF1DEF9@oracle.com> <53E3E4AD.5050102@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kPIBUhQM6MloKvvpttA96oqZXMY Cc: scim@ietf.org Subject: Re: [scim] Another URN issue X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:50:15 -0000 On it. I=92m going through the docs top to bottom by hand and will make = sure they are all good. Apologies. It appears my xml editor search and = replace is a bit buggy! I will also revise to the new urn:ietf:params:scim namespace as well. =20= Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 7, 2014, at 1:42 PM, Leif Johansson wrote: > On 2014-08-07 18:59, Phil Hunt wrote: >> The example on page 19 of the API document is wrong. >>=20 >> { >> "totalResults":100, >> "itemsPerPage":10, >> "startIndex":1, >> "schemas":["urn:scim:api:messages:2.0"], >=20 > Thats another urn that needs changing. >=20 >> "Resources":[{ >> ... >> }] >> } >>=20 >>=20 >> Should be: >>=20 >> { >> "totalResults":100, >> "itemsPerPage":10, >> "startIndex":1, >> "schemas":["urn:scim:api:messages:2.0:ListResponse"], >> "Resources":[{ >> ... >> }] >> } >>=20 >>=20 >> Note also. We=92ve kept ListResponse for consistency reasons. Should = we >> change this to be =93SearchResponse=94 so that it is consistent with = the >> other URIs (e.g. urn:scim:api:messages:2.0:SearchRequest =97 only = used in >> the POST search variant)? >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Fri Aug 8 09:44:41 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102B1B2BBF for ; Fri, 8 Aug 2014 09:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVr0S2ijUXr9 for ; Fri, 8 Aug 2014 09:44:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF601B2BA7 for ; Fri, 8 Aug 2014 09:44:34 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s78GiWsa010344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Aug 2014 16:44:33 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78GiWMP008564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Aug 2014 16:44:32 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78GiVtD003539 for ; Fri, 8 Aug 2014 16:44:31 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 09:44:31 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_53B158D1-79FC-4639-9EFF-677EE0DCA6CD" Message-Id: <4CCCDADF-855A-4A07-9470-7729C97CB1C8@oracle.com> Date: Fri, 8 Aug 2014 09:44:20 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HDQiXq1mpQsn78L91bpkSw1aTLg Subject: [scim] Proposed PATCH Change: 1 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:44:37 -0000 --Apple-Mail=_53B158D1-79FC-4639-9EFF-677EE0DCA6CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 After some feedback at IETF90 and on this list, I would like to propose = to optimization changes to PATCH that should make it more consistent and = less verbose. Please indicate your -1 if you have any objections or questions. If no = objections, I will include this in the next update late Monday = afternoon. Proposal 1: Move schemas attribute to outer message element. Currently, the PATCH body consists of an array of objects, each with a = single operation and its own =93schemas=94 attribute. Here is some = proposed amended text that indicates =93schemas=94 only needs to be = provided in the outer most JSON element: | The body of each request MUST contain the following "schemas" URI: | "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an = array | of one or more operations. For example: =20 | { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], | [ | { | "op":"add", | "path":"members", | "value":[ | { | "display": "Babs Jensen", | "$ref": = "https://example.com/v2/Users/2819c223...413861904646", | "value": "2819c223-7f76-453a-919d-413861904646" | } | ] | }, | ... + additional operations if needed ... | ] | } | | Example JSON body for SCIM PATCH Request Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_53B158D1-79FC-4639-9EFF-677EE0DCA6CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 After = some feedback at IETF90 and on this list, I would like to propose to = optimization changes to PATCH that should make it more consistent and = less verbose.

Please indicate your -1 if you have any = objections or questions.  If no objections, I will include this in = the next update late Monday afternoon.

Proposal = 1:  Move schemas attribute to outer message = element.

Currently, the PATCH body consists of = an array of objects, each with a single operation and its own =93schemas=94= attribute. Here is some proposed amended text that indicates =93schemas=94= only needs to be provided in the outer most JSON = element:

|   The body of each request MUST contain the =
following "schemas" URI:
|   "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an =
array
|   of one or more operations.  For example:
=20
| { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
|   [
|     {
|      "op":"add",
|      "path":"members",
|      "value":[
|       {
|         "display": "Babs Jensen",
|         "$ref": "https://exam=
ple.com/v2/Users/2819c223...413861904646",
|         "value": "2819c223-7f76-453a-919d-413861904646"
|       }
|      ]
|     },
|     ... + additional operations if needed ...
|   ]
| }
|
|                 Example JSON body for SCIM PATCH =
Request

= --Apple-Mail=_53B158D1-79FC-4639-9EFF-677EE0DCA6CD-- From nobody Fri Aug 8 09:50:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205521A0407 for ; Fri, 8 Aug 2014 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mROofBESllx for ; Fri, 8 Aug 2014 09:50:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58A71B2BF9 for ; Fri, 8 Aug 2014 09:50:29 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s78GoSk2017454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Aug 2014 16:50:29 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78GoRn3023532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 2014 16:50:28 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78GoRkx023523 for ; Fri, 8 Aug 2014 16:50:27 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 09:50:27 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_C6A55475-D7C1-46F9-948D-9F3D242AE0A4" Message-Id: <8E92E999-4B43-49E7-A655-33CCE01BE20A@oracle.com> Date: Fri, 8 Aug 2014 09:50:18 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HyEzLcrdx5zHbyOivP8jZMcSeXI Subject: [scim] Proposed PATCH Change: 2 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:50:32 -0000 --Apple-Mail=_C6A55475-D7C1-46F9-948D-9F3D242AE0A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Further to my last message, a second optimization to PATCH is to allow = path to specify the resource itself (by omitting the value). This = allows clients to patch resources and add or replace more than one = attribute in a single PATCH operation. This greatly reduces verbosity = when adding/replacing more than one attribute. Please indicate your -1 if you have any questions or concerns. Proposed text changes: =46rom the introduction section: | A "path" attribute value is a "String" containing an attribute path | describing the target of the operation. A delete operation MUST = have | one value. An add or replace operation MAY have up to one value = (see | operation descriptions below for more information). =46rom Add Operation: The result of the add operation depends upon what the target = location indicated by "path" references: =20 | o If omitted, the target location is assumed to be the resource | itself. The "value" parameter contains a set of attributes to be | added to the resource. | o If the target location does not exist, the attribute and value is added. =20 | o If the target location specifies a complex attribute, a set of | sub-attributes SHALL be specified in the "value" parameter. | and=85 | The following example shows how to add one or more attributes to a | User resource without using a "path" attribute. | | PATCH /Users/2819c223-7f76-453a-919d-413861904646 | Host: example.com | Accept: application/scim+json | Content-Type: application/scim+json | Authorization: Bearer h480djs93hd8 | If-Match: W/"a330bc54f0671c9" | | { | "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], | [{ | "op":"add", | "value":"{ | "emails":[ | { | "value":"babs@jensen.org", | "type":"home" | } | ], | "nickname":"Babs" | }] | } | | In the above example, an additional value is added to the multi- | valued attribute "emails". The second attribute, "nickname" is = added | to the User resource. If the resource already had an existing | "nickname", the value is replaced per the processing rules above for | single-valued attributes. There is similar text for the replace operation. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_C6A55475-D7C1-46F9-948D-9F3D242AE0A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Further to my last message, a second optimization to = PATCH is to allow path to specify the resource itself (by omitting the = value).  This allows clients to patch resources and add or replace = more than one attribute in a single PATCH operation.  This greatly = reduces verbosity when adding/replacing more than one = attribute.

Please indicate your -1 if you have any = questions or concerns.

Proposed text = changes:

=46rom the introduction = section:
|   A "path" attribute value is a "String" containing an =
attribute path
|   describing the target of the operation.  A delete operation MUST =
have
|   one value.  An add or replace operation MAY have up to one value =
(see
|   operation descriptions below for more information).
=46rom Add Operation:

    The result =
of the add operation depends upon what the target location
    indicated by "path" references:
=20
|   o  If omitted, the target location is assumed to be the resource
|      itself.  The "value" parameter contains a set of attributes to be
|      added to the resource.
|
    o  If the target location does not exist, the attribute and value is
       added.
=20
|   o  If the target location specifies a complex attribute, a set of
|      sub-attributes SHALL be specified in the "value" parameter.
|
and=85
|   The following example shows how to add one =
or more attributes to a
|   User resource without using a "path" attribute.
|
|   PATCH /Users/2819c223-7f76-453a-919d-413861904646
|   Host: example.com
|   Accept: application/scim+json
|   Content-Type: application/scim+json
|   Authorization: Bearer h480djs93hd8
|   If-Match: W/"a330bc54f0671c9"
|
|   {
|     "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
|     [{
|       "op":"add",
|       "value":"{
|         "emails":[
|           {
|             "value":"babs@jensen.org",
|             "type":"home"
|           }
|         ],
|         "nickname":"Babs"
|     }]
|   }
|
|   In the above example, an additional value is added to the multi-
|   valued attribute "emails".  The second attribute, "nickname" is =
added
|   to the User resource.  If the resource already had an existing
|   "nickname", the value is replaced per the processing rules above for
|   single-valued attributes.
There is similar text for the = replace operation.

= --Apple-Mail=_C6A55475-D7C1-46F9-948D-9F3D242AE0A4-- From nobody Fri Aug 8 10:01:01 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C352F1A0407 for ; Fri, 8 Aug 2014 10:00:59 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xOXNqCgjFyM for ; Fri, 8 Aug 2014 10:00:57 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5431B2BB6 for ; Fri, 8 Aug 2014 10:00:52 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 17:00:36 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 17:00:36 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] Proposed PATCH Change: 1 of 2 Thread-Index: AQHPsygPaxcXHhV7+kaGmLJGcLRa1JvG7T1g Date: Fri, 8 Aug 2014 17:00:35 +0000 Message-ID: <94bf5e8260a4481188f198f7e8b307ff@BN1PR04MB392.namprd04.prod.outlook.com> References: <4CCCDADF-855A-4A07-9470-7729C97CB1C8@oracle.com> In-Reply-To: <4CCCDADF-855A-4A07-9470-7729C97CB1C8@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 5552D577007D2C5552D6C4 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019004)(199002)(189002)(377454003)(106356001)(76176999)(16601075003)(64706001)(76576001)(50986999)(15975445006)(87936001)(20776003)(107046002)(106116001)(81542001)(80022001)(19609705001)(74502001)(19300405004)(54356999)(107886001)(46102001)(105586002)(66066001)(31966008)(74662001)(101416001)(76482001)(74316001)(19625215002)(85306004)(83322001)(99286002)(95666004)(4396001)(561944003)(19580395003)(19580405001)(92566001)(2656002)(81342001)(86362001)(77096002)(99396002)(33646002)(16236675004)(77982001)(19617315012)(85852003)(15202345003)(21056001)(83072002)(79102001)(24736002)(108616003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_94bf5e8260a4481188f198f7e8b307ffBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/fKkWVda4pncr5a8SwRUFL-TR6hk Subject: Re: [scim] Proposed PATCH Change: 1 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:01:00 -0000 --_000_94bf5e8260a4481188f198f7e8b307ffBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. Although, I would change the URN to be urn:ietf:params:scim:api:messag= es:2.0:PatchRequest (instead of PatchOp). This would make it more consiste= nt with SearchRequest and BulkRequest. IMO a PatchRequest could contain mu= ltiple PatchOps, where an operation would be a single add/remove/replace re= quest). --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, August 08, 2014 11:44 AM To: SCIM WG Subject: [scim] Proposed PATCH Change: 1 of 2 After some feedback at IETF90 and on this list, I would like to propose to = optimization changes to PATCH that should make it more consistent and less = verbose. Please indicate your -1 if you have any objections or questions. If no obj= ections, I will include this in the next update late Monday afternoon. Proposal 1: Move schemas attribute to outer message element. Currently, the PATCH body consists of an array of objects, each with a sing= le operation and its own "schemas" attribute. Here is some proposed amended= text that indicates "schemas" only needs to be provided in the outer most = JSON element: | The body of each request MUST contain the following "schemas" URI: | "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an array | of one or more operations. For example: | { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], | [ | { | "op":"add", | "path":"members", | "value":[ | { | "display": "Babs Jensen", | "$ref": "https://example.com/v2/Users/2819c223...413861904646", | "value": "2819c223-7f76-453a-919d-413861904646" | } | ] | }, | ... + additional operations if needed ... | ] | } | | Example JSON body for SCIM PATCH Request Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_94bf5e8260a4481188f198f7e8b307ffBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.  Although, I= would change the URN to be urn:ietf:params:scim:api:messages:2.0:PatchRequ= est (instead of PatchOp).  This would make it more consistent with SearchRequest and BulkRequest.  IMO a PatchRequest could contain mult= iple PatchOps, where an operation would be a single add/remove/replace requ= est).

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:44 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 1 of 2

 

After some feedback at IETF90 and on this list, I wo= uld like to propose to optimization changes to PATCH that should make it mo= re consistent and less verbose.

 

Please indicate your -1 if you have any objections o= r questions.  If no objections, I will include this in the next update= late Monday afternoon.

 

Proposal 1:  Move schemas attribute to outer me= ssage element.

 

Currently, the PATCH body consists of an array of ob= jects, each with a single operation and its own “schemas” attri= bute. Here is some proposed amended text that indicates “schemas̶= 1; only needs to be provided in the outer most JSON element:

 

|   The=
 body of each request MUST contain the following "schemas" URI:
|   "urn:ietf:params:scim:api:messages:2.0:PatchOp"=
;, followed by an array
|   of one or more operations.  For example:=

 
| { "schemas": ["urn:ietf:params:scim:api:messages:2.0:=
PatchOp"],
|   [
|     {
|      "op":"add",
|      "path":"members",<=
o:p>
|      "value":[
|       {
|         "display":=
 "Babs Jensen",
|         "$ref": &q=
uot;https:=
//example.com/v2/Users/2819c223...413861904646",
|         "value": &=
quot;2819c223-7f76-453a-919d-413861904646"
|       }
|      ]
|     },
|     ... + additional operations if needed ..=
.
|   ]
| }
|
|           &nb=
sp;     Example JSON body for SCIM PATCH Request

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_94bf5e8260a4481188f198f7e8b307ffBN1PR04MB392namprd04pro_-- From nobody Fri Aug 8 10:07:14 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF71A1B2CAF for ; Fri, 8 Aug 2014 10:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wJNzgZqiQsG for ; Fri, 8 Aug 2014 10:07:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DD81B2CA6 for ; Fri, 8 Aug 2014 10:07:08 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 17:07:06 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 17:07:06 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] Proposed PATCH Change: 2 of 2 Thread-Index: AQHPsyjiDFpxNd1XMUmE/x2+7mJxx5vG7tSA Date: Fri, 8 Aug 2014 17:07:06 +0000 Message-ID: <1d3f72a6b4624319b442f932be077029@BN1PR04MB392.namprd04.prod.outlook.com> References: <8E92E999-4B43-49E7-A655-33CCE01BE20A@oracle.com> In-Reply-To: <8E92E999-4B43-49E7-A655-33CCE01BE20A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 5558CB98007D2C5558CCE5 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019004)(377454003)(199002)(189002)(106116001)(54356999)(76176999)(107886001)(2656002)(107046002)(21056001)(80022001)(46102001)(50986999)(101416001)(31966008)(76576001)(19625215002)(105586002)(74662001)(87936001)(4396001)(15202345003)(74502001)(76482001)(74316001)(83072002)(85852003)(106356001)(99396002)(15975445006)(66066001)(92566001)(16601075003)(86362001)(79102001)(19580395003)(19617315012)(85306004)(83322001)(77096002)(19580405001)(81342001)(20776003)(81542001)(16236675004)(99286002)(19609705001)(19300405004)(95666004)(33646002)(77982001)(64706001)(24736002)(108616003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_1d3f72a6b4624319b442f932be077029BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bQ5DcrxkI2d6q6-PGqvAfOaKmoQ Subject: Re: [scim] Proposed PATCH Change: 2 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:07:13 -0000 --_000_1d3f72a6b4624319b442f932be077029BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This adds some ambiguity to the syntax as to whether the value is a complex= attribute (eg - name) or multiple attributes. I guess the "path" will be = enough to differentiate the two. I think I'm alright with this change. > An add or replace operation MAY have up to one value Should this be something more like "An add or replace operation MUST have a= t least one value"? I'm not sure if I'm reading that text correctly or not. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, August 08, 2014 11:50 AM To: SCIM WG Subject: [scim] Proposed PATCH Change: 2 of 2 Further to my last message, a second optimization to PATCH is to allow path= to specify the resource itself (by omitting the value). This allows clien= ts to patch resources and add or replace more than one attribute in a singl= e PATCH operation. This greatly reduces verbosity when adding/replacing mo= re than one attribute. Please indicate your -1 if you have any questions or concerns. Proposed text changes: >From the introduction section: | A "path" attribute value is a "String" containing an attribute path | describing the target of the operation. A delete operation MUST have | one value. An add or replace operation MAY have up to one value (see | operation descriptions below for more information). >From Add Operation: The result of the add operation depends upon what the target location indicated by "path" references: | o If omitted, the target location is assumed to be the resource | itself. The "value" parameter contains a set of attributes to be | added to the resource. | o If the target location does not exist, the attribute and value is added. | o If the target location specifies a complex attribute, a set of | sub-attributes SHALL be specified in the "value" parameter. | and... | The following example shows how to add one or more attributes to a | User resource without using a "path" attribute. | | PATCH /Users/2819c223-7f76-453a-919d-413861904646 | Host: example.com | Accept: application/scim+json | Content-Type: application/scim+json | Authorization: Bearer h480djs93hd8 | If-Match: W/"a330bc54f0671c9" | | { | "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], | [{ | "op":"add", | "value":"{ | "emails":[ | { | "value":"babs@jensen.org", | "type":"home" | } | ], | "nickname":"Babs" | }] | } | | In the above example, an additional value is added to the multi- | valued attribute "emails". The second attribute, "nickname" is added | to the User resource. If the resource already had an existing | "nickname", the value is replaced per the processing rules above for | single-valued attributes. There is similar text for the replace operation. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_1d3f72a6b4624319b442f932be077029BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This adds some ambiguity = to the syntax as to whether the value is a complex attribute (eg – na= me) or multiple attributes.  I guess the “path” will be en= ough to differentiate the two.  I think I’m alright with this change= .

 <= /p>

> An add or replace operation MAY have up to one value

 

Should this be something = more like “An add or replace operation MUST have at least one value&#= 8221;?

 <= /p>

I’m not sure if I&#= 8217;m reading that text correctly or not.

 <= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:50 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 2 of 2

 

Further to my last message, a second optimization to= PATCH is to allow path to specify the resource itself (by omitting the val= ue).  This allows clients to patch resources and add or replace more t= han one attribute in a single PATCH operation.  This greatly reduces verbosity when adding/replacing more than one a= ttribute.

 

Please indicate your -1 if you have any questions or= concerns.

 

Proposed text changes:

 

From the introduction section:

|   A &=
quot;path" attribute value is a "String" containing an attri=
bute path
|   describing the target of the operation.  A delete o=
peration MUST have
|   one value.  An add or replace operation MAY have up=
 to one value (see
|   operation descriptions below for more information).=

From Add Operation:

 

   &nbs=
p;The result of the add operation depends upon what the target location
    indicated by "path" references:
 
|   o  If omitted, the target location is assumed to be=
 the resource
|      itself.  The "value" pa=
rameter contains a set of attributes to be
|      added to the resource.

|


    o  If the target location does not exist, the =
attribute and value is


       added.


 


|   o  If the target location specifies a complex attri=
bute, a set of


|      sub-attributes SHALL be specified in t=
he "value" parameter.


|

and…

|   The=
 following example shows how to add one or more attributes to a<=
/pre>

|   User resource without using a "path" attribute=
.


|


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


|   Host: example.com


|   Accept: application/scim+json


|   Content-Type: application/scim+json


|   Authorization: Bearer h480djs93hd8


|   If-Match: W/"a330bc54f0671c9"


|


|   {


|     "schemas": ["urn:ietf:params:=
scim:api:messages:2.0:PatchOp"],


|     [{


|       "op":"add",<=
o:p>


|       "value":"{


|         "emails":[=



|           {


|           &nb=
sp; "value":"babs@jensen.=
org",


|           &nb=
sp; "type":"home"


|           }


|         ],


|         "nickname"=
:"Babs"


|     }]


|   }


|


|   In the above example, an additional value is added to th=
e multi-


|   valued attribute "emails".  The second at=
tribute, "nickname" is added


|   to the User resource.  If the resource already had =
an existing


|   "nickname", the value is replaced per the proc=
essing rules above for


|   single-valued attributes.




There is similar text for the replace operation.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_1d3f72a6b4624319b442f932be077029BN1PR04MB392namprd04pro_-- From nobody Fri Aug 8 10:07:58 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0605C1B2CB1 for ; Fri, 8 Aug 2014 10:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0z9hrYtpW5r for ; Fri, 8 Aug 2014 10:07:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA30D1B2CA6 for ; Fri, 8 Aug 2014 10:07:53 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s78H7qXV012433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 17:07:53 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78H7poQ004520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 17:07:52 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78H7pkC021377; Fri, 8 Aug 2014 17:07:51 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 10:07:49 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_515C4AC7-2319-4C8A-9722-6319D1C5F2F4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <94bf5e8260a4481188f198f7e8b307ff@BN1PR04MB392.namprd04.prod.outlook.com> Date: Fri, 8 Aug 2014 10:07:35 -0700 Message-Id: References: <4CCCDADF-855A-4A07-9470-7729C97CB1C8@oracle.com> <94bf5e8260a4481188f198f7e8b307ff@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Rou4XdpGBnleM7LIcEhT06euVLI Cc: SCIM WG Subject: Re: [scim] Proposed PATCH Change: 1 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:07:57 -0000 --Apple-Mail=_515C4AC7-2319-4C8A-9722-6319D1C5F2F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Good catch. Agreed. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 8, 2014, at 10:00 AM, Kelly Grizzle = wrote: > +1. Although, I would change the URN to be = urn:ietf:params:scim:api:messages:2.0:PatchRequest (instead of PatchOp). = This would make it more consistent with SearchRequest and BulkRequest. = IMO a PatchRequest could contain multiple PatchOps, where an operation = would be a single add/remove/replace request). > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, August 08, 2014 11:44 AM > To: SCIM WG > Subject: [scim] Proposed PATCH Change: 1 of 2 > =20 > After some feedback at IETF90 and on this list, I would like to = propose to optimization changes to PATCH that should make it more = consistent and less verbose. > =20 > Please indicate your -1 if you have any objections or questions. If = no objections, I will include this in the next update late Monday = afternoon. > =20 > Proposal 1: Move schemas attribute to outer message element. > =20 > Currently, the PATCH body consists of an array of objects, each with a = single operation and its own =93schemas=94 attribute. Here is some = proposed amended text that indicates =93schemas=94 only needs to be = provided in the outer most JSON element: > =20 > | The body of each request MUST contain the following "schemas" URI: > | "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an = array > | of one or more operations. For example: > =20 > | { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > | [ > | { > | "op":"add", > | "path":"members", > | "value":[ > | { > | "display": "Babs Jensen", > | "$ref": = "https://example.com/v2/Users/2819c223...413861904646", > | "value": "2819c223-7f76-453a-919d-413861904646" > | } > | ] > | }, > | ... + additional operations if needed ... > | ] > | } > | > | Example JSON body for SCIM PATCH Request > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 --Apple-Mail=_515C4AC7-2319-4C8A-9722-6319D1C5F2F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Good = catch. Agreed.



On Aug 8, 2014, at 10:00 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

+1.  Although, I would change the URN to be = urn:ietf:params:scim:api:messages:2.0:PatchRequest (instead of = PatchOp).  This would make it more consistent with SearchRequest and BulkRequest.  IMO a PatchRequest could contain = multiple PatchOps, where an operation would be a single = add/remove/replace request).

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:44 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 1 of = 2

 

After some feedback at IETF90 and on this list, I = would like to propose to optimization changes to PATCH that should make = it more consistent and less verbose.

 

Please indicate your -1 if you have any = objections or questions.  If no objections, I will include this in = the next update late Monday afternoon.

 

Proposal 1:  Move schemas attribute to = outer message element.

 

Currently, the PATCH body consists of an = array of objects, each with a single operation and its own =93schemas=94 = attribute. Here is some proposed amended text that indicates =93schemas=94= only needs to be provided in the outer most JSON = element:

 

|   =
The body of each request MUST contain the following "schemas" =
URI:
|   "urn:ietf:params:scim:api:messages:2.0:PatchOp", =
followed by an array
|   of one or more operations.  For =
example:
 
| { "schemas": =
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
|   [
|     {
|      "op":"add",
|      "path":"members",
|      "value":[
|       {
|         "display": "Babs =
Jensen",
|         "$ref": "https://exam=
ple.com/v2/Users/2819c223...413861904646",
|         "value": =
"2819c223-7f76-453a-919d-413861904646"
|       }
|      ]
|     },
|     ... + additional operations if needed =
...
|   ]
| }
|
= 
|           &n=
bsp;     Example JSON body for SCIM PATCH =
Request

 

 

 

 


= --Apple-Mail=_515C4AC7-2319-4C8A-9722-6319D1C5F2F4-- From nobody Fri Aug 8 10:11:22 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1621E1B284F for ; Fri, 8 Aug 2014 10:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvtWSzShuiSx for ; Fri, 8 Aug 2014 10:11:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB381B2860 for ; Fri, 8 Aug 2014 10:11:04 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s78HB3Ea007909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 17:11:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78HB2xh012561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Aug 2014 17:11:03 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s78HB2CJ012538; Fri, 8 Aug 2014 17:11:02 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 10:11:01 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0FC76BBF-6124-45F6-84B3-0C4A63B25648" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <1d3f72a6b4624319b442f932be077029@BN1PR04MB392.namprd04.prod.outlook.com> Date: Fri, 8 Aug 2014 10:10:48 -0700 Message-Id: <2FD9E40C-5C18-411D-B9F5-75C2F5DA9D04@oracle.com> References: <8E92E999-4B43-49E7-A655-33CCE01BE20A@oracle.com> <1d3f72a6b4624319b442f932be077029@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HcJRarALBf4n3jtjv7SUhBh9YM8 Cc: SCIM WG Subject: Re: [scim] Proposed PATCH Change: 2 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:11:20 -0000 --Apple-Mail=_0FC76BBF-6124-45F6-84B3-0C4A63B25648 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See below.. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 8, 2014, at 10:07 AM, Kelly Grizzle = wrote: > This adds some ambiguity to the syntax as to whether the value is a = complex attribute (eg =96 name) or multiple attributes. I guess the = =93path=94 will be enough to differentiate the two. I think I=92m = alright with this change. > =20 > > An add or replace operation MAY have up to one value > =20 > Should this be something more like =93An add or replace operation MUST = have at least one value=94? > =20 > I=92m not sure if I=92m reading that text correctly or not. The reason it is "MAY have up to one value" is so that it is permissible = not to have a =93path=94. Still trying to figure a better way to express = that in normative language. 8-) It may be simpler to say it must always = be provided, but that for add and replace, =93path=94:null is acceptable = in order to reference the resource itself. > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, August 08, 2014 11:50 AM > To: SCIM WG > Subject: [scim] Proposed PATCH Change: 2 of 2 > =20 > Further to my last message, a second optimization to PATCH is to allow = path to specify the resource itself (by omitting the value). This = allows clients to patch resources and add or replace more than one = attribute in a single PATCH operation. This greatly reduces verbosity = when adding/replacing more than one attribute. > =20 > Please indicate your -1 if you have any questions or concerns. > =20 > Proposed text changes: > =20 > =46rom the introduction section: > | A "path" attribute value is a "String" containing an attribute = path > | describing the target of the operation. A delete operation MUST = have > | one value. An add or replace operation MAY have up to one value = (see > | operation descriptions below for more information). > =46rom Add Operation: > =20 > The result of the add operation depends upon what the target = location > indicated by "path" references: > =20 > | o If omitted, the target location is assumed to be the resource > | itself. The "value" parameter contains a set of attributes to = be > | added to the resource. > | > o If the target location does not exist, the attribute and value = is > added. > =20 > | o If the target location specifies a complex attribute, a set of > | sub-attributes SHALL be specified in the "value" parameter. > | > and=85 > | The following example shows how to add one or more attributes to a > | User resource without using a "path" attribute. > | > | PATCH /Users/2819c223-7f76-453a-919d-413861904646 > | Host: example.com > | Accept: application/scim+json > | Content-Type: application/scim+json > | Authorization: Bearer h480djs93hd8 > | If-Match: W/"a330bc54f0671c9" > | > | { > | "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > | [{ > | "op":"add", > | "value":"{ > | "emails":[ > | { > | "value":"babs@jensen.org", > | "type":"home" > | } > | ], > | "nickname":"Babs" > | }] > | } > | > | In the above example, an additional value is added to the multi- > | valued attribute "emails". The second attribute, "nickname" is = added > | to the User resource. If the resource already had an existing > | "nickname", the value is replaced per the processing rules above = for > | single-valued attributes. > There is similar text for the replace operation. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 --Apple-Mail=_0FC76BBF-6124-45F6-84B3-0C4A63B25648 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = below..


On Aug 8, 2014, at 10:07 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

This adds some ambiguity to the syntax as to = whether the value is a complex attribute (eg =96 name) or multiple = attributes.  I guess the =93path=94 will be enough to differentiate the two.  I think I=92m alright with this = change.

 

> An add or replace operation MAY have up to one = value

 

Should this be something more like =93An add or = replace operation MUST have at least one value=94?

 

I=92m not sure if I=92m reading that text = correctly or not.


The = reason it is "MAY have up to one value" is so that it is permissible not = to have a =93path=94. Still trying to figure a better way to express = that in normative language. 8-)  It may be simpler to say it must = always be provided, but that for add and replace, =93path=94:null is = acceptable in order to reference the resource = itself.

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:50 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 2 of = 2

 

Further to my last message, a second optimization to = PATCH is to allow path to specify the resource itself (by omitting the = value).  This allows clients to patch resources and add or replace = more than one attribute in a single PATCH operation.  This greatly reduces verbosity when adding/replacing more than = one attribute.

 

Please indicate your -1 if you have any = questions or concerns.

 

Proposed text changes:

 

=46rom the introduction = section:

|   =
A "path" attribute value is a "String" containing an attribute =
path
|   describing the target of the operation.  A =
delete operation MUST have
|   one value.  An add or replace operation MAY have =
up to one value (see
|   operation descriptions below for more =
information).

=46rom Add Operation:

 

 =
   The result of the add operation depends upon what the =
target location
    indicated by "path" references:
 
|   o  If omitted, the target location is assumed to =
be the resource
|      itself.  The "value" parameter =
contains a set of attributes to be
|      added to the =
resource.
|
    o  If the target location does not exist, =
the attribute and value is
       added.
 
|   o  If the target location specifies a complex =
attribute, a set of
|      sub-attributes SHALL be specified =
in the "value" parameter.
|

and=85

|   =
The following example shows how to add one or more attributes to =
a
|   User resource without using a "path" =
attribute.
|
|   PATCH =
/Users/2819c223-7f76-453a-919d-413861904646
|   Host: example.com
|   Accept: application/scim+json
|   Content-Type: application/scim+json
|   Authorization: Bearer h480djs93hd8
|   If-Match: W/"a330bc54f0671c9"
|
|   {
|     "schemas": =
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
|     [{
|       "op":"add",
|       "value":"{
|         =
"emails":[
|           =
{
= 
|           &n=
bsp; "value":"babs@jensen.org",
= 
|           &n=
bsp; "type":"home"
|           =
}
|         =
],
|         =
"nickname":"Babs"
|     }]
|   }
|
|   In the above example, an additional value is added to =
the multi-
|   valued attribute "emails".  The second =
attribute, "nickname" is added
|   to the User resource.  If the resource already =
had an existing
|   "nickname", the value is replaced per the processing =
rules above for
|   single-valued attributes.

There is similar text for the replace = operation.

 

 

 

 


= --Apple-Mail=_0FC76BBF-6124-45F6-84B3-0C4A63B25648-- From nobody Fri Aug 8 10:15:24 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7A1A0046 for ; Fri, 8 Aug 2014 10:15:24 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZcbiD4_k4qm for ; Fri, 8 Aug 2014 10:15:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A071A0002 for ; Fri, 8 Aug 2014 10:15:20 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 17:15:18 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.154]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 17:15:18 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Proposed PATCH Change: 2 of 2 Thread-Index: AQHPsyjiDFpxNd1XMUmE/x2+7mJxx5vG7tSAgAACPwCAAAE3YA== Date: Fri, 8 Aug 2014 17:15:18 +0000 Message-ID: References: <8E92E999-4B43-49E7-A655-33CCE01BE20A@oracle.com> <1d3f72a6b4624319b442f932be077029@BN1PR04MB392.namprd04.prod.outlook.com> <2FD9E40C-5C18-411D-B9F5-75C2F5DA9D04@oracle.com> In-Reply-To: <2FD9E40C-5C18-411D-B9F5-75C2F5DA9D04@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 55604DC2007D2C55604F0F x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019004)(377454003)(199002)(189002)(51444003)(24454002)(106116001)(54356999)(76176999)(2656002)(107046002)(21056001)(80022001)(46102001)(50986999)(101416001)(31966008)(76576001)(19625215002)(105586002)(74662001)(87936001)(4396001)(15202345003)(74502001)(76482001)(74316001)(83072002)(85852003)(106356001)(99396002)(15975445006)(66066001)(92566001)(16601075003)(86362001)(79102001)(19580395003)(19617315012)(85306004)(83322001)(77096002)(19580405001)(81342001)(20776003)(81542001)(16236675004)(110136001)(99286002)(19609705001)(19300405004)(95666004)(33646002)(15395725005)(77982001)(64706001)(24736002)(108616003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d9a3de9114c34ccf9d08ff3aac6b4a00BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ll71MtlQdSvM_rTqUYDBAAyKi5o Cc: SCIM WG Subject: Re: [scim] Proposed PATCH Change: 2 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:15:24 -0000 --_000_d9a3de9114c34ccf9d08ff3aac6b4a00BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that would make more sense to me. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Friday, August 08, 2014 12:11 PM To: Kelly Grizzle Cc: SCIM WG Subject: Re: [scim] Proposed PATCH Change: 2 of 2 See below.. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 8, 2014, at 10:07 AM, Kelly Grizzle > wrote: This adds some ambiguity to the syntax as to whether the value is a complex= attribute (eg - name) or multiple attributes. I guess the "path" will be = enough to differentiate the two. I think I'm alright with this change. > An add or replace operation MAY have up to one value Should this be something more like "An add or replace operation MUST have a= t least one value"? I'm not sure if I'm reading that text correctly or not. The reason it is "MAY have up to one value" is so that it is permissible no= t to have a "path". Still trying to figure a better way to express that in = normative language. 8-) It may be simpler to say it must always be provide= d, but that for add and replace, "path":null is acceptable in order to refe= rence the resource itself. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, August 08, 2014 11:50 AM To: SCIM WG Subject: [scim] Proposed PATCH Change: 2 of 2 Further to my last message, a second optimization to PATCH is to allow path= to specify the resource itself (by omitting the value). This allows clien= ts to patch resources and add or replace more than one attribute in a singl= e PATCH operation. This greatly reduces verbosity when adding/replacing mo= re than one attribute. Please indicate your -1 if you have any questions or concerns. Proposed text changes: >From the introduction section: | A "path" attribute value is a "String" containing an attribute path | describing the target of the operation. A delete operation MUST have | one value. An add or replace operation MAY have up to one value (see | operation descriptions below for more information). >From Add Operation: The result of the add operation depends upon what the target location indicated by "path" references: | o If omitted, the target location is assumed to be the resource | itself. The "value" parameter contains a set of attributes to be | added to the resource. | o If the target location does not exist, the attribute and value is added. | o If the target location specifies a complex attribute, a set of | sub-attributes SHALL be specified in the "value" parameter. | and... | The following example shows how to add one or more attributes to a | User resource without using a "path" attribute. | | PATCH /Users/2819c223-7f76-453a-919d-413861904646 | Host: example.com | Accept: application/scim+json | Content-Type: application/scim+json | Authorization: Bearer h480djs93hd8 | If-Match: W/"a330bc54f0671c9" | | { | "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], | [{ | "op":"add", | "value":"{ | "emails":[ | { | "value":"babs@jensen.org", | "type":"home" | } | ], | "nickname":"Babs" | }] | } | | In the above example, an additional value is added to the multi- | valued attribute "emails". The second attribute, "nickname" is added | to the User resource. If the resource already had an existing | "nickname", the value is replaced per the processing rules above for | single-valued attributes. There is similar text for the replace operation. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_d9a3de9114c34ccf9d08ff3aac6b4a00BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that would make m= ore sense to me.

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Friday, August 08, 2014 12:11 PM
To: Kelly Grizzle
Cc: SCIM WG
Subject: Re: [scim] Proposed PATCH Change: 2 of 2<= /p>

 

See below..

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Aug 8, 2014, at 10:07 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:



This adds some ambiguity = to the syntax as to whether the value is a complex attribute (eg – na= me) or multiple attributes.  I guess the “path” will be en= ough to differentiate the two.  I think I’m alright with this change= .

 <= /p>

> An add or replace operation MAY have up to one value

 

Should this be something = more like “An add or replace operation MUST have at least one value&#= 8221;?

 <= /p>

I’m not sure if I&#= 8217;m reading that text correctly or not.

 

The reason it is "MAY have up to one value"= ; is so that it is permissible not to have a “path”. Still tryi= ng to figure a better way to express that in normative language. 8-)  = It may be simpler to say it must always be provided, but that for add and replace, “path”:null is acceptable in order to ref= erence the resource itself.

 

 <= /p>

 <= /p>

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:50 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 2 of 2

 

Further to my last message, a second optimization to= PATCH is to allow path to specify the resource itself (by omitting the val= ue).  This allows clients to patch resources and add or replace more t= han one attribute in a single PATCH operation.  This greatly reduces verbosity when adding/replacing more than one a= ttribute.

 

Please indicate your -1 if you have any questions or= concerns.

 

Proposed text changes:

 

From the introduction section:

|   A &=
quot;path" attribute value is a "String" containing an attri=
bute path
|   describing the target of the operation.  A delete o=
peration MUST have
|   one value.  An add or replace operation MAY have up=
 to one value (see
|   operation descriptions below for more information).=

From Add Operation:

 

   &nbs=
p;The result of the add operation depends upon what the target location
    indicated by "path" references:
 
|   o  If omitted, the target location is assumed to be=
 the resource
|      itself.  The "value" pa=
rameter contains a set of attributes to be
|      added to the resource.

|


    o  If the target location does not exist, the =
attribute and value is


       added.


 


|   o  If the target location specifies a complex attri=
bute, a set of


|      sub-attributes SHALL be specified in t=
he "value" parameter.


|

and…

|   The=
 following example shows how to add one or more attributes to a<=
/pre>

|   User resource without using a "path" attribute=
.


|


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


|   Host: example.com


|   Accept: application/scim+json


|   Content-Type: application/scim+json


|   Authorization: Bearer h480djs93hd8


|   If-Match: W/"a330bc54f0671c9"


|


|   {


|     "schemas": ["urn:ietf:params:=
scim:api:messages:2.0:PatchOp"],


|     [{


|       "op":"add",<=
o:p>


|       "value":"{


|         "emails":[=



|           {


|           &nb=
sp; "value":"babs@jensen.=
org",


|           &nb=
sp; "type":"home"


|           }


|         ],


|         "nickname"=
:"Babs"


|     }]


|   }


|


|   In the above example, an additional value is added to th=
e multi-


|   valued attribute "emails".  The second at=
tribute, "nickname" is added


|   to the User resource.  If the resource already had =
an existing


|   "nickname", the value is replaced per the proc=
essing rules above for


|   single-valued attributes.




There is similar text for the replace operation.

 

 

 

 

 

--_000_d9a3de9114c34ccf9d08ff3aac6b4a00BN1PR04MB392namprd04pro_-- From nobody Fri Aug 8 13:18:53 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E951B27E8 for ; Fri, 8 Aug 2014 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oSiaAcz_EtT for ; Fri, 8 Aug 2014 13:18:48 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FDE1A854D for ; Fri, 8 Aug 2014 13:18:47 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so4257897lbg.12 for ; Fri, 08 Aug 2014 13:18:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xmfmvuDkdAlolIuPs7XstKS3hEZRcYPqvNZi7Wv3/uk=; b=mKS13ka6DD22HADIo+vEoZcSY1lkPJ40pz1YCAB/3ByhJcuzudXehjqwVLFL5fmvmd TRICWZE1dUdkpjoI29Qgp54J/yyYh2Q9pULsydDbxgj2IUjXTmDPOpL3xIitz3IZFXyr sofngUdO0J8XL944DgVCvuZSypeUKgCIzdQG104LGdT5Tf7rP4vQaeMznSDc4DiiT+KT kOMJDQ85+WNhjrr5akikfu+ry9OtGziCelVUOcldZE2NWbbU/+VdgZkmZaN2MryldJqT liRKrWigmljZqeiqOB54Z1fY6P8XelKrZ2lBDO3CT0MHxSJCR1mwqAHkwDbR/4ez92Su mBVg== X-Gm-Message-State: ALoCoQk+roWKKLic7wTPixlmI1NvYfTS7FgOm7tIjqCfrUvmMcOQQ4LUel0eR0FmueHURPgRCURB X-Received: by 10.112.134.169 with SMTP id pl9mr3640128lbb.75.1407529125813; Fri, 08 Aug 2014 13:18:45 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id wc7sm5811800lbb.39.2014.08.08.13.18.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Aug 2014 13:18:45 -0700 (PDT) Message-ID: <53E530A4.5030700@mnt.se> Date: Fri, 08 Aug 2014 22:18:44 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: scim@ietf.org References: <4CCCDADF-855A-4A07-9470-7729C97CB1C8@oracle.com> <94bf5e8260a4481188f198f7e8b307ff@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <94bf5e8260a4481188f198f7e8b307ff@BN1PR04MB392.namprd04.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/b4WziaaROEZjgyIWwhKyjRK4NB0 Subject: Re: [scim] Proposed PATCH Change: 1 of 2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:18:52 -0000 On 2014-08-08 19:00, Kelly Grizzle wrote: > +1. Although, I would change the URN to be > urn:ietf:params:scim:api:messages:2.0:PatchRequest (instead of > PatchOp). This would make it more consistent with SearchRequest and > BulkRequest. IMO a PatchRequest could contain multiple PatchOps, where > an operation would be a single add/remove/replace request). > +1 for consistency :-) > > > --Kelly > > > > *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Friday, August 08, 2014 11:44 AM > *To:* SCIM WG > *Subject:* [scim] Proposed PATCH Change: 1 of 2 > > > > After some feedback at IETF90 and on this list, I would like to propose > to optimization changes to PATCH that should make it more consistent and > less verbose. > > > > Please indicate your -1 if you have any objections or questions. If no > objections, I will include this in the next update late Monday afternoon. > > > > Proposal 1: Move schemas attribute to outer message element. > > > > Currently, the PATCH body consists of an array of objects, each with a > single operation and its own “schemas” attribute. Here is some proposed > amended text that indicates “schemas” only needs to be provided in the > outer most JSON element: > > > > | The body of each request MUST contain the following "schemas" URI: > > | "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an array > > | of one or more operations. For example: > > > > | { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > > | [ > > | { > > | "op":"add", > > | "path":"members", > > | "value":[ > > | { > > | "display": "Babs Jensen", > > | "$ref": "https://example.com/v2/Users/2819c223...413861904646", > > | "value": "2819c223-7f76-453a-919d-413861904646" > > | } > > | ] > > | }, > > | ... + additional operations if needed ... > > | ] > > | } > > | > > | Example JSON body for SCIM PATCH Request > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Mon Aug 11 11:02:08 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF21A04AB; Mon, 11 Aug 2014 11:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqMmTvPXVvXm; Mon, 11 Aug 2014 11:02:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC21A0478; Mon, 11 Aug 2014 11:02:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811180203.28236.31276.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:02:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/vhwaTLh2W_qYBgwVHhbZrNALcvk Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-08.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:02:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Kelly Grizzle Phil Hunt Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-08.txt Pages : 65 Date : 2014-08-11 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON format. This schema is intended for exchange and use with cloud service providers. An HTTP protocol binding document is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 11 11:07:15 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6031A05D3 for ; Mon, 11 Aug 2014 11:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6fasdidw-U7 for ; Mon, 11 Aug 2014 11:07:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3211A04A4 for ; Mon, 11 Aug 2014 11:07:07 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7BI756v024391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Aug 2014 18:07:06 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7BI74JX025612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Aug 2014 18:07:05 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7BI6XtN014382 for ; Mon, 11 Aug 2014 18:07:03 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Aug 2014 11:06:32 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <20140811180203.28236.31276.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:06:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140811180203.28236.31276.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VEus7ifULXXgYkhzvLBNmWwUNEc Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-08.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:07:09 -0000 FYI=85 As per the discussion in Toronto at IETF90, the urn namespace for all = schema values has been switched to urn:ietf:params:scim:=85 to align = with RFC3553. I plan to post a parallel API draft update later today. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 11, 2014, at 11:02 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Kelly Grizzle > Phil Hunt > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-08.txt > Pages : 65 > Date : 2014-08-11 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite builds > upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > Its intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move identity in to, out of, and around the cloud. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups in JSON format. This schema is > intended for exchange and use with cloud service providers. An HTTP > protocol binding document is also provided. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Aug 12 08:54:00 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E061A0996; Tue, 12 Aug 2014 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzwwWZhn3LbB; Tue, 12 Aug 2014 08:53:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7791A03DF; Tue, 12 Aug 2014 08:53:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812155351.18320.88291.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 08:53:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qH2opftlPPf_XsMcPZD6V_-5P1M Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-09.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:53:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management:Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-09.txt Pages : 76 Date : 2014-08-12 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in multi-domain based applications and services easier using HTTP Protocol. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 09:08:08 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4BC1A0043 for ; Tue, 12 Aug 2014 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LwwphUOjN9U for ; Tue, 12 Aug 2014 09:08:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896D01A0067 for ; Tue, 12 Aug 2014 09:08:06 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7CG84Ch009117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Aug 2014 16:08:05 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7CG83wI023587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Aug 2014 16:08:04 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7CG82Od011162 for ; Tue, 12 Aug 2014 16:08:03 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Aug 2014 09:08:02 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <20140812155351.18320.88291.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 09:08:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <403B344B-994E-4BE8-8CD6-D7EFD9E4EB3B@oracle.com> References: <20140812155351.18320.88291.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/fcKN2mT6Ux5RfnIRJI_0-nE3WwU Subject: Re: [scim] I-D Action: draft-ietf-scim-api-09.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:08:08 -0000 This draft includes the following updates: 1. Aligned schema URIs for SCIM schema and APIs to use the = urn:ietf:params:scim namespace (as with the core-schema document) 2. Clarified/simplified =93schemas" usage with PATCH so that it is = handled consistently with other SCIM API commands. 3. In PATCH, the path element may be omitted so that the resource = itself can be the target of operations to add / replace of attributes. = Clarifying text was also added for complex attributes (previously = missing). Items 2-3 had some preliminary text shared on the list, and after = receiving some feedback, I=92ve updated the drafts to reflect that = input. =20 As of this draft, we should be going into a clarification/editorial = clean-up phase with the documents. I=92m not aware of any other major = TODOs at this time. If there are any, please let the list know as soon = as possible. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 12, 2014, at 8:53 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity = Management:Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Technology Nexus > Chuck Mortimore > Filename : draft-ietf-scim-api-09.txt > Pages : 76 > Date : 2014-08-12 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in multi-domain based > applications and services easier using HTTP Protocol. Examples > include but are not limited to enterprise to cloud service = providers, > and inter-cloud based scenarios. The specification suite seeks to > build upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > It's intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move users in to, out of, and around the cloud. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From grahameg@gmail.com Fri Aug 15 16:26:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4215E1A083F for ; Fri, 15 Aug 2014 16:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.022 X-Spam-Level: ** X-Spam-Status: No, score=2.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8puf4aEdrXnp for ; Fri, 15 Aug 2014 16:26:57 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C897C1A07D4 for ; Fri, 15 Aug 2014 16:26:57 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g18so2530721oah.34 for ; Fri, 15 Aug 2014 16:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=dM65CHvWP+VzsSZnKqkPwBEQLZXrozS6T9OujckX6WQ=; b=FGfmIkKL2QfCbg4WqSuVS44m9rWtm8tntLu/5D6fndgDl9njfmdaoqgpCEds+Fncsu mGC9/sp3f5ZIZlChM2F2uUuhMuMzS/SSDENI6jJDfaWIuDosD6vucsZGxpXJXk4uLobq DmKvEH49B+CAXjAbKhJIHwEFSArdw6Z0QpBBq1Rz5L6RaA6QNJWPUQiiO4v7IiqtwrdF WmLUkBwghG+rgunpLgoODi60bSPtBLz9unozdOm5aNEcZ5AUQhsj8zg96fHRJsjrdczT Xnb13ADGeTt6o1rZH2pH7qTT4gOQ2oNkFZob6rXp8CCjMesbNHk87jZ69jNA3Yn2my1r 2RaQ== MIME-Version: 1.0 X-Received: by 10.60.15.37 with SMTP id u5mr23270113oec.12.1408145217341; Fri, 15 Aug 2014 16:26:57 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.43.225 with HTTP; Fri, 15 Aug 2014 16:26:57 -0700 (PDT) Date: Sat, 16 Aug 2014 09:26:57 +1000 X-Google-Sender-Auth: gw66g-V_NqNbzdZAC4kkQqqThPQ Message-ID: From: Grahame Grieve To: scim@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/R0vDqAY0wdHg6gtPB46SIZh64Uw Subject: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 05:29:39 -0000 hi I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am just adding SCIM support to my FHIR reference server - partly to allow me to use SCIM for it's purpose in my server, and partly so we can explore what is required to write up how to integrate SCIM into FHIR (and therefore encourage users in health to adopt it - it's still over the horizon for health, but not long now) I have a few questions that the documentation doesn't really explain: 1. can you PUT after a DELETE to bring a user back to life? 2. When you do a PUT, the document says: Attributes whose mutability is "readWrite", that are omitted from the request body, MAY be assumed to be not asserted by the client. The service provider MAY assume any existing values are to be cleared or the service provider MAY assign a default value to the final resource representation. Service providers MAY take into account whether a client has access to, or understands, all of the resource's attributes when deciding whether non-asserted attributes SHALL be removed or defaulted. Clients that would like to override a server defaults, MAY specify "null" for a single-valued attribute or an empty array "[]" for a multi-valued attribute to clear all values. I find this little obscure for multi-valued attributes. If the client provides a single email address, then all the existing ones are over-written? It would be nice if this were clear. Also, this doesn't address the question of a extension schemas - I haven't found anywhere about whether a server is allowed to accept extension schemas it doesn't know about (or required to), but if it can/does, how does that work with updates? 3. if the server exposes the same interface on multiple host names (this is common), what happens to meta.location? 4. there's nothing like a namespace on the user name. If you're using SCIM with OAuth, and auto-creating user accounts on the fly, where would the OAuth user identity go? (The intent here is that you autocreate the user resource, but then a user can edit the details associated with the account after it is created) 5. Regarding query, it says "SCIM service SHOULD ignore any query parameters they do not recognize" - the specification doesn't give guidance about what to do if a single parameter in a value path or a logical conjunction is not recognised (treat it as true or false or ignore the whole group?). And there doesn't seem like a way for the client to know what has been accepted or not? But later the specification says "Providers MUST decline to filter results if the specified filter operation is not recognized" - This doesn't seem reliably consistent 6. I am mystified by the /ServiceProviderConfigs end-point. As far as I can figure out, there is only ever one config, so do you have to search for it? or does it have some kind of fixed identity that I have missed? thanks -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Sat Aug 16 04:37:23 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0731A8762 for ; Sat, 16 Aug 2014 04:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNe9Zj3WTD-x for ; Sat, 16 Aug 2014 04:37:19 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF181A8765 for ; Sat, 16 Aug 2014 04:37:18 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id i138so2379953oig.13 for ; Sat, 16 Aug 2014 04:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=0Th+hQurNOcI++FH6bTsILGhcGsKUM3CHTxtnoiRrnI=; b=u6nSwXDahWZOrNFk3pasNFGFNI9U+jE3YauP3rhdiZA8tiNTt/izwxzU4gZGJMfEfF LrPlwjAd3DlpsS61KGsLxNhfTFZbbZh0n1Q4LZlyUGzKjKbySPc2iFiJzUCNCLb2aecM owzO/JcXuDrrmpK6oNVN4/YSVbKYqepmJT2QnSxck+G/ihhWLzyd9eyLwWGodBO+BFTm +/Uk6FzFJ90PD1zLxQivkDRmKUtS/OdbkADU7vLmfHyKzbo6p27t6e9eXxs3yBC6W9cT z965i/2ryEkAgQ7t7IzFez/rSvd/A2vyhUtm3z+OccpOGFh9biaenMqSLlbhgtVZRs0o 2dmw== MIME-Version: 1.0 X-Received: by 10.60.63.166 with SMTP id h6mr1377222oes.79.1408189038259; Sat, 16 Aug 2014 04:37:18 -0700 (PDT) Received: by 10.60.43.225 with HTTP; Sat, 16 Aug 2014 04:37:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Aug 2014 21:37:18 +1000 Message-ID: From: Grahame Grieve To: scim@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/8LHlVjBSTpHTXjRu1HVc6Nq-8kQ Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: grahame@healthintersections.com.au List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 11:37:20 -0000 A follow up question: Concerning the filters, it says: If the specified attribute in a filter expression is a multi-valued attribute, the resource MUST match if any of the instances of the given attribute match the specified criterion; e.g. if a User has multiple emails values, only one has to match for the entire User to match. This has unexpected consequences when the filter operator is "ne", and there is more than one item Grahame On Sat, Aug 16, 2014 at 9:20 AM, Grahame Grieve wrote: > hi > > I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am > just adding SCIM support to my FHIR reference server - partly to allow > me to use SCIM for it's purpose in my server, and partly so we can > explore what is required to write up how to integrate SCIM into FHIR > (and therefore encourage users in health to adopt it - it's still over > the horizon for health, but not long now) > > I have a few questions that the documentation doesn't really explain: > > 1. can you PUT after a DELETE to bring a user back to life? > > 2. When you do a PUT, the document says: > > Attributes whose mutability is "readWrite", that are omitted from the > request body, MAY be assumed to be not asserted by the client. The > service provider MAY assume any existing values are to be cleared or > the service provider MAY assign a default value to the final resource > representation. Service providers MAY take into account whether a > client has access to, or understands, all of the resource's > attributes when deciding whether non-asserted attributes SHALL be > removed or defaulted. Clients that would like to override a server > defaults, MAY specify "null" for a single-valued attribute or an > empty array "[]" for a multi-valued attribute to clear all values. > > I find this little obscure for multi-valued attributes. If the client > provides a single email address, then all the existing ones are > over-written? It would be nice if this were clear. Also, this doesn't > address the question of a extension schemas - I haven't found anywhere > about whether a server is allowed to accept extension schemas it > doesn't know about (or required to), but if it can/does, how does that > work with updates? > > 3. if the server exposes the same interface on multiple host names > (this is common), what happens to meta.location? > > 4. there's nothing like a namespace on the user name. If you're using > SCIM with OAuth, and auto-creating user accounts on the fly, where > would the OAuth user identity go? (The intent here is that you > autocreate the user resource, but then a user can edit the details > associated with the account after it is created) > > 5. Regarding query, it says "SCIM service SHOULD ignore any query > parameters they do not recognize" - the specification doesn't give > guidance about what to do if a single parameter in a value path or a > logical conjunction is not recognised (treat it as true or false or > ignore the whole group?). And there doesn't seem like a way for the > client to know what has been accepted or not? But later the > specification says "Providers MUST decline to filter results if the > specified filter operation is not recognized" - This doesn't seem > reliably consistent > > 6. I am mystified by the /ServiceProviderConfigs end-point. As far as > I can figure out, there is only ever one config, so do you have to > search for it? or does it have some kind of fixed identity that I have > missed? > > > thanks > Grahame > > -- > ----- > http://www.healthintersections.com.au / > grahame@healthintersections.com.au / +61 411 867 065 -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au From nobody Sat Aug 16 10:53:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A0D1A0040 for ; Sat, 16 Aug 2014 10:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EccI2nViKdjA for ; Sat, 16 Aug 2014 10:53:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F5F1A0039 for ; Sat, 16 Aug 2014 10:53:30 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7GHrSWf030784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Aug 2014 17:53:29 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GHrSfO009631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 16 Aug 2014 17:53:28 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GHrRQE009627; Sat, 16 Aug 2014 17:53:27 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 Aug 2014 10:53:27 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 16 Aug 2014 10:53:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Grahame Grieve X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/8DlmxC-2Ju-VqYCHZwXK2Z6O_90 Cc: scim@ietf.org Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 17:53:33 -0000 Grahame, Thanks for your comments. Its always useful to say any issues around = clarity as we are going through the final editorial revisions now. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 15, 2014, at 4:26 PM, Grahame Grieve = wrote: > hi >=20 > I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am > just adding SCIM support to my FHIR reference server - partly to allow > me to use SCIM for it's purpose in my server, and partly so we can > explore what is required to write up how to integrate SCIM into FHIR > (and therefore encourage users in health to adopt it - it's still over > the horizon for health, but not long now) >=20 > I have a few questions that the documentation doesn't really explain: >=20 > 1. can you PUT after a DELETE to bring a user back to life? Per RFC2119 regarding keywords, the use of SHOULD is critical here under = the definition of the DELETE operation. In this case, my read of the draft is that a PUT after a DELETE, SHOULD = NOT be possible. This is because the identifier and any unique keys = SHOULD be released. A delete is a delete.=20 Note: this used to be a MUST. After some discussion in Toronto, we = weakened compliance to SHOULD. =20 If an implementer chooses not to follow the SHOULD language, it might be = possible that this would work. There has been some discussion on tombstoning, but the group decided to = delay its definition (as far as I recall). IMO, you are better to use =93active=94 to deactivate an account and = reactivate it for now. >=20 > 2. When you do a PUT, the document says: >=20 > Attributes whose mutability is "readWrite", that are omitted from the > request body, MAY be assumed to be not asserted by the client. The > service provider MAY assume any existing values are to be cleared or > the service provider MAY assign a default value to the final = resource > representation. Service providers MAY take into account whether a > client has access to, or understands, all of the resource's > attributes when deciding whether non-asserted attributes SHALL be > removed or defaulted. Clients that would like to override a server > defaults, MAY specify "null" for a single-valued attribute or an > empty array "[]" for a multi-valued attribute to clear all values. >=20 > I find this little obscure for multi-valued attributes. If the client > provides a single email address, then all the existing ones are > over-written? It would be nice if this were clear. Also, this doesn't > address the question of a extension schemas - I haven't found anywhere > about whether a server is allowed to accept extension schemas it > doesn't know about (or required to), but if it can/does, how does that > work with updates? The meaning of PUT is an entire replace.=20 A couple of considerations: 1. What happens if a client does a GET, changes one of the attributes = client-side and then puts the object back with a PUT (kind of like a = =93bean=94). 2. In order to be simple for the client, the server should be flexible = in what it accepts. The rules indicate what the server will do when = certain conditions arise around attribute mutability =97 e.g. can a = client replace a read only attribute For multi-valued attributes or complex attributes, the overall intent of = PUT is still to replace the entire resource. If you want to replace = specific values, you need to use the PATCH operation or have the client = manipulate the values itself and provide the full set of values to = replace. >=20 > 3. if the server exposes the same interface on multiple host names > (this is common), what happens to meta.location? I would defer to normal HTTP/1.1 rules on this. In practice, the = meta-location (and Location header) you return should be the one that = you expect the client to use next time. >=20 > 4. there's nothing like a namespace on the user name. I=92m not sure what you mean here. Yes, the userName is not associated = with any particular use. I would have to defer to the original SCIM 1 = authors on this decision. > If you're using > SCIM with OAuth, and auto-creating user accounts on the fly, where > would the OAuth user identity go? (The intent here is that you > autocreate the user resource, but then a user can edit the details > associated with the account after it is created) SCIM like OAuth would have nothing to say about how you build this = process much like OAuth doesn=92t have anything to say about usernames. In practice, it might be reasonable to have an authenticated UI = component that has been authorized by oAuth based on its client = credentials to perform registration of users that are anonymous to the = client. This would mean the SCIM POST contains an authorization header = that has a token representing the UI client component. In other cases, you might allow completely anonymous POST to the /Users = endpoint to create a User resource. I would proceed with caution as you = want to be concerned about DoS attacks. That said, once a User object is created in the service provider, it is = not for SCIM to say what happens next. It could be that a provisioning = workflow kicks in and things like email confirmations happen. Many have = commented that initially a new SCIM User does not have full entitlements = or maybe even active status until the workflow for provisioning is done. = This is up to you to define. >=20 > 5. Regarding query, it says "SCIM service SHOULD ignore any query > parameters they do not recognize" - the specification doesn't give > guidance about what to do if a single parameter in a value path or a > logical conjunction is not recognised (treat it as true or false or > ignore the whole group?). And there doesn't seem like a way for the > client to know what has been accepted or not? But later the > specification says "Providers MUST decline to filter results if the > specified filter operation is not recognized" - This doesn't seem > reliably consistent This is tricky languages that most specifications run into. The = objective is to allow future specifications to define new parameters = while ensuring the older servers will still work in a predictable way. In this case, filter is an optional parameter. A server may choose to = ignore it. But if it chooses to support it, it must understand the = entire parameter. In other words, if the server supports filters, then = all filters must be valid. The server can=92t partially understand a = filter value. If the server doesn=92t understand part of the parameter = the whole operation must fail. If the server doesn=92t understand or = support filters at all the server may ignore filters. >=20 > 6. I am mystified by the /ServiceProviderConfigs end-point. As far as > I can figure out, there is only ever one config, so do you have to > search for it? or does it have some kind of fixed identity that I have > missed? Yes, this one is an oddball. There is only one resource, but it does = need its own end-point. Hence /ServiceProviderConfig. We could allow = /ServiceProviderConfig.scim (or .json) to make it appear more like the = single resource it is rather than look like a container (like /Users). >=20 >=20 > thanks >=20 > --=20 > ----- > http://www.healthintersections.com.au / > grahame@healthintersections.com.au / +61 411 867 065 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sat Aug 16 11:11:43 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5503C1A00D8 for ; Sat, 16 Aug 2014 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfisl1j06b78 for ; Sat, 16 Aug 2014 11:11:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB64F1A00D4 for ; Sat, 16 Aug 2014 11:11:40 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7GIBcrj010194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Aug 2014 18:11:39 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GIBcpx009631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Aug 2014 18:11:38 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GIBblI016132; Sat, 16 Aug 2014 18:11:37 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 Aug 2014 11:11:37 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 16 Aug 2014 11:11:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <254F6FF2-FDB4-4C03-8E32-B7EA07BAFCE4@oracle.com> References: To: grahame@healthintersections.com.au X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZK6mFtsNoZE_c80cm5MUiz9K4Lo Cc: scim@ietf.org Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 18:11:42 -0000 We may need to revise the text a bit here. The issue with filters is that filters are used to match =93resources=94 = rather than specific =93values=94 of a multi-valued attribute. So a match with any value means that all values are returned (with the = resource). Likewise, for a ne, then no values must be equal. I will take a look at the text and try to clean it up. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 16, 2014, at 4:37 AM, Grahame Grieve wrote: > A follow up question: >=20 > Concerning the filters, it says: >=20 > If the specified attribute in a filter expression is a multi-valued > attribute, the resource MUST match if any of the instances of the > given attribute match the specified criterion; e.g. if a User has > multiple emails values, only one has to match for the entire User to > match. >=20 > This has unexpected consequences when the filter operator is "ne", and > there is more than one item >=20 > Grahame >=20 >=20 > On Sat, Aug 16, 2014 at 9:20 AM, Grahame Grieve > wrote: >> hi >>=20 >> I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am >> just adding SCIM support to my FHIR reference server - partly to = allow >> me to use SCIM for it's purpose in my server, and partly so we can >> explore what is required to write up how to integrate SCIM into FHIR >> (and therefore encourage users in health to adopt it - it's still = over >> the horizon for health, but not long now) >>=20 >> I have a few questions that the documentation doesn't really explain: >>=20 >> 1. can you PUT after a DELETE to bring a user back to life? >>=20 >> 2. When you do a PUT, the document says: >>=20 >> Attributes whose mutability is "readWrite", that are omitted from the >> request body, MAY be assumed to be not asserted by the client. The >> service provider MAY assume any existing values are to be cleared = or >> the service provider MAY assign a default value to the final = resource >> representation. Service providers MAY take into account whether a >> client has access to, or understands, all of the resource's >> attributes when deciding whether non-asserted attributes SHALL be >> removed or defaulted. Clients that would like to override a server >> defaults, MAY specify "null" for a single-valued attribute or an >> empty array "[]" for a multi-valued attribute to clear all values. >>=20 >> I find this little obscure for multi-valued attributes. If the client >> provides a single email address, then all the existing ones are >> over-written? It would be nice if this were clear. Also, this doesn't >> address the question of a extension schemas - I haven't found = anywhere >> about whether a server is allowed to accept extension schemas it >> doesn't know about (or required to), but if it can/does, how does = that >> work with updates? >>=20 >> 3. if the server exposes the same interface on multiple host names >> (this is common), what happens to meta.location? >>=20 >> 4. there's nothing like a namespace on the user name. If you're using >> SCIM with OAuth, and auto-creating user accounts on the fly, where >> would the OAuth user identity go? (The intent here is that you >> autocreate the user resource, but then a user can edit the details >> associated with the account after it is created) >>=20 >> 5. Regarding query, it says "SCIM service SHOULD ignore any query >> parameters they do not recognize" - the specification doesn't give >> guidance about what to do if a single parameter in a value path or a >> logical conjunction is not recognised (treat it as true or false or >> ignore the whole group?). And there doesn't seem like a way for the >> client to know what has been accepted or not? But later the >> specification says "Providers MUST decline to filter results if the >> specified filter operation is not recognized" - This doesn't seem >> reliably consistent >>=20 >> 6. I am mystified by the /ServiceProviderConfigs end-point. As far as >> I can figure out, there is only ever one config, so do you have to >> search for it? or does it have some kind of fixed identity that I = have >> missed? >>=20 >>=20 >> thanks >> Grahame >>=20 >> -- >> ----- >> http://www.healthintersections.com.au / >> grahame@healthintersections.com.au / +61 411 867 065 >=20 >=20 >=20 > --=20 > ----- > http://www.healthintersections.com.au / = grahame@healthintersections.com.au >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sat Aug 16 14:42:57 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C441A03EB for ; Sat, 16 Aug 2014 14:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k0wBsTdlIGn for ; Sat, 16 Aug 2014 14:42:52 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1DA61A03E8 for ; Sat, 16 Aug 2014 14:42:52 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id m1so3007103oag.19 for ; Sat, 16 Aug 2014 14:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=hn79TpP/eB2yS5bcRsKl9gz/E8JYQOsOL0Cmx+8AZI4=; b=seF5Gj7EDaMhnUzlY+P61EQrvCP696WLS4MqXt7RIENPPWYiIwp2jEqCzZrMfQgTIT mv32Xvh+K2gU0AVHy6I4o0IwePN4nFtT0+yvNtSKyMHGpvjb4CIvtC02xs/ljofaaFjw i11jRv97CpffoyhSt3/HDR/3ZYDNbWRsVlOQeo7REoJtP3ylUWiZuXFrYgdu/ijIpOAW Nr/qMUxxCRZDcdN5x1SEONz+qimnbHBtr/a8N1iwux/ZC50G/CNJ5RxrKVJ3G9+eUJIl vwA9R9AvHrsx/MjDatZd7vF+9Lc9l3rsKoEVayoqjQ2+o+8zd3nObrf/1qzh0F/QzajU APvA== MIME-Version: 1.0 X-Received: by 10.182.128.34 with SMTP id nl2mr28350067obb.44.1408225371967; Sat, 16 Aug 2014 14:42:51 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.43.225 with HTTP; Sat, 16 Aug 2014 14:42:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Aug 2014 07:42:51 +1000 X-Google-Sender-Auth: 4YB-86a4GLyX0nP_6puKgtaoyW4 Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/cQUeOMaYRHv-jRlv4O2kdvk4HVw Cc: scim@ietf.org Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:42:54 -0000 Thanks. Comments in line. Grahame >> 1. can you PUT after a DELETE to bring a user back to life? > Per RFC2119 regarding keywords, the use of SHOULD is critical here under = the definition of the DELETE operation. > > In this case, my read of the draft is that a PUT after a DELETE, SHOULD N= OT be possible. This is because the identifier and any unique keys SHOULD = be released. A delete is a delete. I don't see a SHOULD in the delete section. (http://tools.ietf.org/html/draft-ietf-scim-api-09#section-3.4) I guess this refers to the first must. in which case, well, ok, but adding "including a PUT" would clarify > A couple of considerations: > 1. What happens if a client does a GET, changes one of the attributes cli= ent-side and then puts the object back with a PUT (kind of like a =E2=80=9C= bean=E2=80=9D). > 2. In order to be simple for the client, the server should be flexible in= what it accepts. The rules indicate what the server will do when certain c= onditions arise around attribute mutability =E2=80=94 e.g. can a client rep= lace a read only attribute > > For multi-valued attributes or complex attributes, the overall intent of = PUT is still to replace the entire resource. If you want to replace specifi= c values, you need to use the PATCH operation or have the client manipulate= the values itself and provide the full set of values to replace. I think that the mixed language confuses things. If it's an entire replace, why the confusing language around attributes that are null or not? just make the put a put and a use patch for patching. I think that this mixed model is the worst of both worlds >> 3. if the server exposes the same interface on multiple host names >> (this is common), what happens to meta.location? > > I would defer to normal HTTP/1.1 rules on this. In practice, the meta-lo= cation (and Location header) you return should be the one that you expect t= he client to use next time. well, I don't know what the normal rules are, since the meta is *content* not header. I don't understand what it's presence is for except to make this case confusing. >> If you're using >> SCIM with OAuth, and auto-creating user accounts on the fly, where >> would the OAuth user identity go? (The intent here is that you >> autocreate the user resource, but then a user can edit the details >> associated with the account after it is created) > > SCIM like OAuth would have nothing to say about how you build this proces= s much like OAuth doesn=E2=80=99t have anything to say about usernames. but shouldn't something somewhere say something about this? I suppose you'd put a URI representing the OAuth user identification in the externalId. It just seems to me that given the scope of SCIM, this combination will be very common - auto creating accounts persuant to OAuth, and then exposing those accounts on an authenticated SCIM interface so permissions etc can be managed. Shouldn't someone somewhere say something about how a client might recognise the right user account? > This is tricky languages that most specifications run into. The objective= is to allow future specifications to define new parameters while ensuring = the older servers will still work in a predictable way. well, ok, and I see I misread that. > In this case, filter is an optional parameter. A server may choose to ign= ore it. But if it chooses to support it, it must understand the entire para= meter. In other words, if the server supports filters, then all filters mu= st be valid. The server can=E2=80=99t partially understand a filter value.= If the server doesn=E2=80=99t understand part of the parameter the whole o= peration must fail. If the server doesn=E2=80=99t understand or support fi= lters at all the server may ignore filters. well, ok, but it makes future extensibility a problem >> 6. I am mystified by the /ServiceProviderConfigs end-point. As far as >> I can figure out, there is only ever one config, so do you have to >> search for it? or does it have some kind of fixed identity that I have >> missed? > Yes, this one is an oddball. There is only one resource, but it does need= its own end-point. Hence /ServiceProviderConfig. We could allow /ServiceP= roviderConfig.scim (or .json) to make it appear more like the single resou= rce it is rather than look like a container (like /Users). if there's only one resource, can the spec assign a fixed identifier to it so that it's easy to get it? how is that supposed to work - you search for it using what parameter? Grahame From nobody Sat Aug 16 14:44:02 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBE31A03F5 for ; Sat, 16 Aug 2014 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTwkClhaxxAn for ; Sat, 16 Aug 2014 14:43:52 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5441A03ED for ; Sat, 16 Aug 2014 14:43:52 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wm4so2998287obc.2 for ; Sat, 16 Aug 2014 14:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lA5h+CKlZ6UcPS2unVXoDOoHfGb6rKZaaFwarB4fKrc=; b=Jbv3o351J5nfjd9bJHB0fc2uQZQh+nR19Jjh/1Gp7F+Sh1eGsxnuLB5xR4tJcuAnZD RJesi6BhLdGWsLiPIHfYM4E5hL4WDt0GYMGMRMO7pKL06Hbx5X6BS7dAftUMS+S9oEAh boRC10IHBMupP6mXeAA05AQgCa8XzVlCoD/2dRRDuHxc6Zb/fAVmGx553nARF1WGweJa lCIknOxiQkZNUkwYs2UU2SyghrHFmP3Hw5uu007vQj8qmjZSJ68lcLDAGR9PbJ4gk5H/ wTfsjohNOEaFJfg5HJZUrsbYSgosA5mJ3CQXgVhaFngSHEhJVlO8JrWQMCgyweJJblv6 9zug== MIME-Version: 1.0 X-Received: by 10.60.98.206 with SMTP id ek14mr27862860oeb.51.1408225432050; Sat, 16 Aug 2014 14:43:52 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.43.225 with HTTP; Sat, 16 Aug 2014 14:43:51 -0700 (PDT) In-Reply-To: <254F6FF2-FDB4-4C03-8E32-B7EA07BAFCE4@oracle.com> References: <254F6FF2-FDB4-4C03-8E32-B7EA07BAFCE4@oracle.com> Date: Sun, 17 Aug 2014 07:43:51 +1000 X-Google-Sender-Auth: thtHLNPIYEJK2uq7iXqSTjFVXAI Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZOCeu_y3GcADHTznL8GltgLWV54 Cc: scim@ietf.org Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:43:54 -0000 I think revision is definitely required, because this is not "likewise" to me - if it were likewise then for ne, a match would be returned if there was any value with no match Grahame On Sun, Aug 17, 2014 at 4:11 AM, Phil Hunt wrote: > We may need to revise the text a bit here. > > The issue with filters is that filters are used to match =E2=80=9Cresourc= es=E2=80=9D rather than specific =E2=80=9Cvalues=E2=80=9D of a multi-valued= attribute. > > So a match with any value means that all values are returned (with the r= esource). Likewise, for a ne, then no values must be equal. > > I will take a look at the text and try to clean it up. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Aug 16, 2014, at 4:37 AM, Grahame Grieve wrote: > >> A follow up question: >> >> Concerning the filters, it says: >> >> If the specified attribute in a filter expression is a multi-valued >> attribute, the resource MUST match if any of the instances of the >> given attribute match the specified criterion; e.g. if a User has >> multiple emails values, only one has to match for the entire User to >> match. >> >> This has unexpected consequences when the filter operator is "ne", and >> there is more than one item >> >> Grahame >> >> >> On Sat, Aug 16, 2014 at 9:20 AM, Grahame Grieve >> wrote: >>> hi >>> >>> I am the lead editor for FHIR, a healthcare equivalent to SCIM. I am >>> just adding SCIM support to my FHIR reference server - partly to allow >>> me to use SCIM for it's purpose in my server, and partly so we can >>> explore what is required to write up how to integrate SCIM into FHIR >>> (and therefore encourage users in health to adopt it - it's still over >>> the horizon for health, but not long now) >>> >>> I have a few questions that the documentation doesn't really explain: >>> >>> 1. can you PUT after a DELETE to bring a user back to life? >>> >>> 2. When you do a PUT, the document says: >>> >>> Attributes whose mutability is "readWrite", that are omitted from the >>> request body, MAY be assumed to be not asserted by the client. The >>> service provider MAY assume any existing values are to be cleared or >>> the service provider MAY assign a default value to the final resource >>> representation. Service providers MAY take into account whether a >>> client has access to, or understands, all of the resource's >>> attributes when deciding whether non-asserted attributes SHALL be >>> removed or defaulted. Clients that would like to override a server >>> defaults, MAY specify "null" for a single-valued attribute or an >>> empty array "[]" for a multi-valued attribute to clear all values. >>> >>> I find this little obscure for multi-valued attributes. If the client >>> provides a single email address, then all the existing ones are >>> over-written? It would be nice if this were clear. Also, this doesn't >>> address the question of a extension schemas - I haven't found anywhere >>> about whether a server is allowed to accept extension schemas it >>> doesn't know about (or required to), but if it can/does, how does that >>> work with updates? >>> >>> 3. if the server exposes the same interface on multiple host names >>> (this is common), what happens to meta.location? >>> >>> 4. there's nothing like a namespace on the user name. If you're using >>> SCIM with OAuth, and auto-creating user accounts on the fly, where >>> would the OAuth user identity go? (The intent here is that you >>> autocreate the user resource, but then a user can edit the details >>> associated with the account after it is created) >>> >>> 5. Regarding query, it says "SCIM service SHOULD ignore any query >>> parameters they do not recognize" - the specification doesn't give >>> guidance about what to do if a single parameter in a value path or a >>> logical conjunction is not recognised (treat it as true or false or >>> ignore the whole group?). And there doesn't seem like a way for the >>> client to know what has been accepted or not? But later the >>> specification says "Providers MUST decline to filter results if the >>> specified filter operation is not recognized" - This doesn't seem >>> reliably consistent >>> >>> 6. I am mystified by the /ServiceProviderConfigs end-point. As far as >>> I can figure out, there is only ever one config, so do you have to >>> search for it? or does it have some kind of fixed identity that I have >>> missed? >>> >>> >>> thanks >>> Grahame >>> >>> -- >>> ----- >>> http://www.healthintersections.com.au / >>> grahame@healthintersections.com.au / +61 411 867 065 >> >> >> >> -- >> ----- >> http://www.healthintersections.com.au / grahame@healthintersections.com.= au >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Sat Aug 16 15:53:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63721A03C8 for ; Sat, 16 Aug 2014 15:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpXd-JeeHjyi for ; Sat, 16 Aug 2014 15:53:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E9A1A0058 for ; Sat, 16 Aug 2014 15:53:18 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7GMrGEK027368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Aug 2014 22:53:17 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GMrFTS016818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Aug 2014 22:53:16 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7GMrFtc016815; Sat, 16 Aug 2014 22:53:15 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 Aug 2014 15:53:15 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 16 Aug 2014 15:53:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16C0961A-34E5-412B-BA30-37D1194AE181@oracle.com> References: To: Grahame Grieve X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Bqf8ZTQ6I1-G2DJNDFk7u6vfoGo Cc: scim@ietf.org Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:53:20 -0000 Graham, Regarding delete, the text is: > Clients request resource removal via DELETE. Service providers MAY > choose not to permanently delete the resource, but MUST return a = 404 > error code for all operations associated with the previously = deleted > Id. Service providers MUST also omit the resource from future = query > results. In addition the service provider SHOULD NOT consider the > deleted resource in conflict calculation. For example if a User > resource is deleted, a CREATE request for a User resource with the > same userName as the previously deleted resource should not fail = with > a 409 error due to userName conflict. When a delete has occurred the resource MUST return a 404. Therefore an = attempt to do a PUT, MUST return a 404. What I was speaking to is the fact that it might actually work on some = servers (see second part of paragraph), but only because the entry is = being maintained in some =93hidden=94 fashion keeping the identifier and = userName =93reserved". How those people intend to resurrect the entry = is not defined in a standard way. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 16, 2014, at 2:42 PM, Grahame Grieve = wrote: > Thanks. Comments in line. >=20 > Grahame >=20 >>> 1. can you PUT after a DELETE to bring a user back to life? >> Per RFC2119 regarding keywords, the use of SHOULD is critical here = under the definition of the DELETE operation. >>=20 >> In this case, my read of the draft is that a PUT after a DELETE, = SHOULD NOT be possible. This is because the identifier and any unique = keys SHOULD be released. A delete is a delete. >=20 > I don't see a SHOULD in the delete section. > (http://tools.ietf.org/html/draft-ietf-scim-api-09#section-3.4) > I guess this refers to the first must. in which case, well, ok, but > adding "including a PUT" would clarify >=20 >> A couple of considerations: >> 1. What happens if a client does a GET, changes one of the attributes = client-side and then puts the object back with a PUT (kind of like a = =93bean=94). >> 2. In order to be simple for the client, the server should be = flexible in what it accepts. The rules indicate what the server will do = when certain conditions arise around attribute mutability =97 e.g. can a = client replace a read only attribute >>=20 >> For multi-valued attributes or complex attributes, the overall intent = of PUT is still to replace the entire resource. If you want to replace = specific values, you need to use the PATCH operation or have the client = manipulate the values itself and provide the full set of values to = replace. >=20 > I think that the mixed language confuses things. If it's an entire > replace, why the confusing language around attributes that are null or > not? just make the put a put and a use patch for patching. I think > that this mixed model is the worst of both worlds I agree. Refinement is likely necessary. However the determine = functionality was arrived at by consensus. if you wish to propose = alternate text, I=92m sure the group would consider it if it improves = clarity. Before you do so, I invite you to read through the mail logs. = There are quite a number of inter-related issues. >=20 >>> 3. if the server exposes the same interface on multiple host names >>> (this is common), what happens to meta.location? >>=20 >> I would defer to normal HTTP/1.1 rules on this. In practice, the = meta-location (and Location header) you return should be the one that = you expect the client to use next time. >=20 > well, I don't know what the normal rules are, since the meta is > *content* not header. I don't understand what it's presence is for > except to make this case confusing. There is a =93location=94 header. Meta.location is intended to be the = same. >=20 >>> If you're using >>> SCIM with OAuth, and auto-creating user accounts on the fly, where >>> would the OAuth user identity go? (The intent here is that you >>> autocreate the user resource, but then a user can edit the details >>> associated with the account after it is created) >>=20 >> SCIM like OAuth would have nothing to say about how you build this = process much like OAuth doesn=92t have anything to say about usernames. >=20 > but shouldn't something somewhere say something about this? I suppose > you'd put a URI representing the OAuth user identification in the > externalId. It just seems to me that given the scope of SCIM, this > combination will be very common - auto creating accounts persuant to > OAuth, and then exposing those accounts on an authenticated SCIM > interface so permissions etc can be managed. Shouldn't someone > somewhere say something about how a client might recognise the right > user account? Speaking as an OAuth WG member, OAuth does NOT provide authentication = information to clients. It provides authorization to clients to access a = resource (in this case a SCIM SP). You=92ll want OpenID Connect if you = want ID Profile information to be passed to clients. That said, we did add an =93alias=94 which is =93/Me=94. A client = performing a GET =93/Me=94 will get the resource matching the currently = authenticated =93subject=94 as far as the SCIM resource server is = concerned. Note: If there is no User, this might be an OAuth =93Client=94= or other application credential. This is why the alias is not GET = =93/Users/me=94. I agree, How you choose to integrate these is open to you (at present). = OAuth is but one of many possible authorization model. Please keep in = mind that the current charter only covers provisioning. So scenarios = like SCIM acting as a directory are not yet in scope (though as you say = quite likely). >=20 >> This is tricky languages that most specifications run into. The = objective is to allow future specifications to define new parameters = while ensuring the older servers will still work in a predictable way. >=20 > well, ok, and I see I misread that. >=20 >> In this case, filter is an optional parameter. A server may choose to = ignore it. But if it chooses to support it, it must understand the = entire parameter. In other words, if the server supports filters, then = all filters must be valid. The server can=92t partially understand a = filter value. If the server doesn=92t understand part of the parameter = the whole operation must fail. If the server doesn=92t understand or = support filters at all the server may ignore filters. >=20 > well, ok, but it makes future extensibility a problem How so?=20 >=20 >>> 6. I am mystified by the /ServiceProviderConfigs end-point. As far = as >>> I can figure out, there is only ever one config, so do you have to >>> search for it? or does it have some kind of fixed identity that I = have >>> missed? >> Yes, this one is an oddball. There is only one resource, but it does = need its own end-point. Hence /ServiceProviderConfig. We could allow = /ServiceProviderConfig.scim (or .json) to make it appear more like the = single resource it is rather than look like a container (like /Users). >=20 > if there's only one resource, can the spec assign a fixed identifier > to it so that it's easy to get it? how is that supposed to work - you > search for it using what parameter? >=20 > Grahame From nobody Sun Aug 17 05:53:17 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AC1A089C for ; Sun, 17 Aug 2014 05:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLsRtOL3qQYL for ; Sun, 17 Aug 2014 05:53:13 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19621A089B for ; Sun, 17 Aug 2014 05:53:12 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id uz6so1275596obc.28 for ; Sun, 17 Aug 2014 05:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Osgo5NITbYlM8mujRVYshLh4qW+RtVHzWJ6PcgTSXoQ=; b=zyL9d89RcfHuSQGD76hhrE9jvEnb4RKKTSCIXZEsP9DY55MdA3JLa2f/bQQ/2sT8MQ cZYdSgWvRvsMhddqshAkwagGQuBoddrA0BCpeD6ehXYfu4xjZ3otXYKUpVJTevqR6d6Q ykwY1NF9Q//PqerONd3smNLLDrD9VKGxSlqPp5YlEkaGoNETmm8tDgkSqQXxAZlshfl3 kVrYpC5Acw4agLQPqPLPZEA4Frdx3ozR7vPk4yQR1zAg0dYEFOW0yoMd4M91GaxjHdQC GjGBWHf/tHcWf7AaIGBYwyA1OFc1rtpbFId9dNHoFf9k1nhjS+ci15lvm4uVVaQFthYy ep2g== MIME-Version: 1.0 X-Received: by 10.60.178.243 with SMTP id db19mr31968016oec.32.1408279992198; Sun, 17 Aug 2014 05:53:12 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.43.225 with HTTP; Sun, 17 Aug 2014 05:53:12 -0700 (PDT) In-Reply-To: <16C0961A-34E5-412B-BA30-37D1194AE181@oracle.com> References: <16C0961A-34E5-412B-BA30-37D1194AE181@oracle.com> Date: Sun, 17 Aug 2014 22:53:12 +1000 X-Google-Sender-Auth: CTMq2Fw5QQlMuI0OuSDo3QowK94 Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: multipart/alternative; boundary=089e01176ac5adeb500500d2bcf4 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/29_KTTva_2Dldax8SEhsjcYRIv4 Cc: "scim@ietf.org" Subject: Re: [scim] Implementer Questions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 12:53:14 -0000 --089e01176ac5adeb500500d2bcf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > When a delete has occurred the resource MUST return a 404. Therefore an > attempt to do a PUT, MUST return a 404. Y. I guess in didn't think through the consequences of that sentence did I? On Aug 16, 2014, at 2:42 PM, Grahame Grieve < grahame@healthintersections.com.au> wrote: >> In this case, my read of the draft is that a PUT after a DELETE, SHOULD > NOT be possible. This is because the identifier and any unique keys SHOU= LD > be released. A delete is a delete. Heh. There's no such thing as true delete in healthcare. People feel very strongly about that. So we in health would never say "a delete is a delete". But for scim I don't have any requirements like that, and I'm fine with it > I think that the mixed language confuses things. If it's an entire > > replace, why the confusing language around attributes that are null or > > not? just make the put a put and a use patch for patching. I think > > that this mixed model is the worst of both worlds > > I agree. Refinement is likely necessary. However the determine > functionality was arrived at by consensus. if you wish to propose alterna= te > text, I=E2=80=99m sure the group would consider it if it improves clarity= . Before > you do so, I invite you to read through the mail logs. I said to myself when I started this that I wasn't going to argue. I don't have time to give it justice. So I'll leave this I don't understand what it's presence is for > > except to make this case confusing. > > There is a =E2=80=9Clocation=E2=80=9D header. Meta.location is intended = to be the same. Oh. And the definition even says that. Oops. So why us it there if it's in the header? Most similar specs will simply mandate that there be a location header (ah, here I go again. But some explanation of why it's duplicated would be good) >> > >> SCIM like OAuth would have nothing to say about how you build this > process much like OAuth doesn=E2=80=99t have anything to say about userna= mes. > > > > but shouldn't something somewhere say something about this? I suppose > > you'd put a URI representing the OAuth user identification in the > > externalId. It just seems to me that given the scope of SCIM, this > > combination will be very common - auto creating accounts persuant to > > OAuth, and then exposing those accounts on an authenticated SCIM > > interface so permissions etc can be managed. Shouldn't someone > > somewhere say something about how a client might recognise the right > > user account? > > Speaking as an OAuth WG member, OAuth does NOT provide authentication > information to clients. Well, ok, it doesn't. There is, though, almost always some introspection endpoint that does openid connect based (or some derivation) user id. Perhaps I phrased the question badly, but still: who's business would it be to describe how they should work together? > > > well, ok, but it makes future extensibility a problem > > How so? oh no, you'll go for v3 then? I guess that would work. > if there's only one resource, can the spec assign a fixed identifier > > to it so that it's easy to get it? how is that supposed to work - you > > search for it using what parameter? > no answer on this one? Grahame --089e01176ac5adeb500500d2bcf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When a delete has occurred the resource MUST return a 404. Therefore an att= empt to do a PUT, MUST return a 404.

Y. I g= uess in didn't think through the consequences of that sentence did I?

On Aug 16, 2014, at 2:42 PM, Grahame Grieve <grah= ame@healthintersections.com.au> wrote:

>> In this case, my read of the draft is that a PUT after a DELETE, S= HOULD NOT be possible.=C2=A0 This is because the identifier and any unique = keys SHOULD be released. A delete is a delete.

<= div> Heh. There's no such thing as true delete in healthcare. People feel ve= ry strongly about that. So=C2=A0we in health would never say "a delete= is a delete". But for scim I don't have any requirements like tha= t, and I'm fine with it=C2=A0

> I think that the mixed language confuses things. If it's an entire=
> replace, why the confusing language around attributes that are null or=
> not? just make the put a put and a use patch for patching. I think
> that this mixed model is the worst of both worlds

I agree. Refinement is likely necessary. However the determine functionalit= y was arrived at by consensus. if you wish to propose alternate text, I=E2= =80=99m sure the group would consider it if it improves clarity. Before you= do so, I invite you to read through the mail logs.=C2=A0

I said to m= yself when I started this that I wasn't going to argue. I don't hav= e time to give it justice. So I'll leave this=C2=A0

=C2=A0I don't understand = what it's presence is for
> except to make this case confusing.

There is a =E2=80=9Clocation=E2=80=9D header.=C2=A0 Meta.location is intend= ed to be the same.

Oh. And the definition e= ven says that. Oops.=C2=A0So why us it there if it's in the header? Mos= t=C2=A0similar specs will simply mandate that=C2=A0there be a location head= er (ah, here I go again. But some explanation of why it's duplicated wo= uld be good)

>>
>> SCIM like OAuth would have nothing to say about how you build this= process much like OAuth doesn=E2=80=99t have anything to say about usernam= es.
>
> but shouldn't something somewhere say something about this? I supp= ose
> you'd put a URI representing the OAuth user identification in the<= br> > externalId. It just seems to me that given the scope of SCIM, this
> combination will be very common - auto creating accounts persuant to > OAuth, and then exposing those accounts on an authenticated SCIM
> interface so permissions etc can be managed. Shouldn't someone
> somewhere say something about how a client might recognise the right > user account?

Speaking as an OAuth WG member, OAuth does NOT provide authentication infor= mation to clients.=C2=A0

Well, ok, it doesn't. There is, though, almost alwa= ys some introspection endpoint that does openid connect based (or some deri= vation) user id. Perhaps I phrased the question badly, but still: who's= =C2=A0business would it be to describe how they should work together?

>
> well, ok, but it makes future extensibility a problem

How so?

oh no, you'll go for v3 then? I= guess that would work.=C2=A0

> if there's only one resource, can the spec assign a fixed identifi= er
> to it so that it's easy to get it? how is that supposed to work - = you
> search for it using what parameter?

no answer on this one?

Grahame
=C2=A0
--089e01176ac5adeb500500d2bcf4-- From nobody Fri Aug 29 13:27:49 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3F1A067F; Fri, 29 Aug 2014 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stvP8iszoiUj; Fri, 29 Aug 2014 13:27:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5961A0AFB; Fri, 29 Aug 2014 13:27:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829202746.31059.78509.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 13:27:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DjWZx3tZ93FP0s8vD8xcdgTttMY Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-09.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:27:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Kelly Grizzle Phil Hunt Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-09.txt Pages : 65 Date : 2014-08-29 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/