On May 1, 2014, at 10:30 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Works for me.

From: Leif Johansson [mailto:leifj@mnt.se]
Sent: Thursday, May 01, 2014 12:17 PM
To: Ian Glazer
Cc: Julian Reschke; scim@ietf.org WG; Phil Hunt; Kelly = Grizzle
Subject: Re: [scim] Ticket 65 HTTP Method = Override

thus I propose closinf with = wontfix

1 maj 2014 kl. 17:34 skrev Ian Glazer <iglazer@salesforce.com>:

We've got out own problems to worry about; = we don't need to clean up other people's backyards for = them.

On Thu, May 1, 2014 at 6:00 AM, Leif = Johansson <leifj@mnt.se> wrote:

> 1 maj 2014 kl. 10:04 skrev Julian Reschke <julian.reschke@gmx.de>:<= /o:p>

>
>> On 2014-05-01 09:26, Leif Johansson wrote:
>> It sure feels like bb needs to fix their browser... Or if tjhey = feel
>> strongly about it, turn up and spec out a standard http = header.... and
>> get others to play.
>> ...
>
> Is this about XMLHTTPRequest in the Blackberry browser? Is this a = known bug? Has it been reported to Blackberry?
>

who knows. not sure scim needs to care = though...

> Best regards, Julian

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

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

@iglazer

= --Apple-Mail=_55360905-B607-43DA-966B-6DD46902EE00-- From nobody Thu May 1 12:00: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 085821A891B for ; Thu, 1 May 2014 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 o4kyjoMrxK0a for ; Thu, 1 May 2014 12:00:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D3FED1A7D81 for ; Thu, 1 May 2014 12:00:25 -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 s41J0N09015389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 May 2014 19:00:23 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 s41J0MnN008860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 May 2014 19:00:22 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s41J0MZg024261 for ; Thu, 1 May 2014 19:00:22 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 May 2014 12:00:21 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_BF0010EA-8DF2-4A84-91A4-39E70CC27DCD" Message-Id: <290C8267-675D-4B98-B37C-F90595428586@oracle.com> Date: Thu, 1 May 2014 12:00:20 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uI_vzhQlp8DuhIB4tLz1S5wWQqE Subject: [scim] Ticket 3: excludedAttributes parameter proposal X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:00:31 -0000 --Apple-Mail=_BF0010EA-8DF2-4A84-91A4-39E70CC27DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Regarding the proposal to have an excludedAttributes parameter. We had = a discussion on the call this week, and there was some agreement that = while the parameter is not critical to the needs of the protocol, it is = useful from the standpoint of developer and operational utility. For = example, administrators attempting to query a SCIM endpoint directly may = find it useful to specify which attributes they do not want far more = easier than listing all attributes that could be returned to omit the = one they do not returned. There was also some value in using excludedAttributes when doing a = multi-resourceType search. The existing text on the =93attributes=94 parameter: Section 3.7 Additional retrieval query parameters Clients MAY request a partial resource representation on any operation that returns a resource within the response by specifying the URL query parameter 'attributes'. When specified, each resource returned MUST contain the minimal set of resource attributes and MUST contain no other attributes or Sub-Attributes than those explicitly requested. The query parameter attributes value is a comma separated list of resource attribute names in standard attribute notation (Section 3.8) form (e.g. userName, name, emails). Section 3.2.3 Query Resources Using HTTP POST attributes A multi-valued list of strings indicating the names of resource attributes to return in the response. Attribute names MUST be in standard attribute notation (Section 3.8) form. See additional retrieval query parameters (Section 3.7). OPTIONAL. Proposed text: Section 3.7 Additional Operation Response Parameters For any SCIM operation where a resource representation is returned = (e.g. GET), the attributes normally returned are defined as the minimum attribute = set=20 plus the default attributes. The minimum attribute set are those = attributes=20 whose schema have =93returned=94 set to =93always=94 (e.g. =93id=94). = The default=20 attribute set are those attributes whose schema have =93returned=94 = set to=20 =93default=94. Clients MAY request a partial resource representation on any operation that returns a resource by specifying either the URL query = parameter=20 =93attributes=94 OR =93excludedAttributes=94 as follows: attributes When specified, each resource returned MUST contain the = minimal set=20 of resource attributes and MUST contain no other attributes or = sub-attributes other than those explicitly requested. The query parameter = attributes value is a=20 comma separated list of resource attribute names in standard = attribute notation (Section 3.8) form (e.g. userName, name, emails). excludedAttributes When specified, each resourcereturned MUST contain = the minimal=20 set of resource attributes and any attributes normally returned by = =93default=94=20 minus those attributes listed in =93excludedAttributes=94. The = query parameter=20 excludedAttributes value is a comma separated list of resource = attribute names in=20 standard attribute notation (Section 3.8) form (e.g. userName, = name, emails). Section 3.2.3 Query Resources Using HTTP POST attributes A multi-valued list of strings indicating the names of resource attributes to return in the response overriding the set of attributes that would be returned by default. Attribute names MUST be in standard attribute notation (Section 3.8) form. See additional operation response parameters (Section 3.7). OPTIONAL. excludedAttributes A multi-valued list of strings indicating the names of attributes to be removed from the default set of attributes to=20= be returned. =93excludedAttributes=94 SHALL have no affect on = attributes whose =93returned=94 characteristic is =93always=94 (Section 11 = [core-schema]).=20 Attribute names MUST be in standard attribute notation (Section = 3.8) form. See additional operation response parameters (Section 3.7). = OPTIONAL. Does this work? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_BF0010EA-8DF2-4A84-91A4-39E70CC27DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Regarding the proposal to have an = excludedAttributes parameter. We had a discussion on the call this = week, and there was some agreement that while the parameter is not = critical to the needs of the protocol, it is useful from the standpoint = of developer and operational utility. For example, administrators = attempting to query a SCIM endpoint directly may find it useful to = specify which attributes they do not want far more easier than listing = all attributes that could be returned to omit the one they do not = returned.

There was also some value in using = excludedAttributes when doing a multi-resourceType = search.

The existing text on the = =93attributes=94 parameter:

Section 3.7 = Additional retrieval query parameters

   Clients MAY request a partial resource =
representation on any
   operation that returns a resource within the response by specifying
   the URL query parameter 'attributes'.  When specified, each resource
   returned MUST contain the minimal set of resource attributes and MUST
   contain no other attributes or Sub-Attributes than those explicitly
   requested.  The query parameter attributes value is a comma separated
   list of resource attribute names in standard attribute notation
   (Sec=
tion 3.8) form (e.g.  userName, name, =
emails).

Section 3.2.3 Query = Resources Using HTTP POST

attributes  A multi-valued list of strings =
indicating the names of
      resource attributes to return in the response.  Attribute names
      MUST be in standard attribute notation (Sec=
tion 3.8) form.  See
      additional retrieval query parameters (Sec=
tion 3.7).  =
OPTIONAL.

Proposed = text:

Section 3.7 Additional Operation = Response Parameters

   For =
any SCIM operation where a resource representation is returned (e.g. =
GET),

   the attributes =
normally returned are defined as the minimum attribute set

   plus the default =
attributes. The minimum attribute set are those attributes

   whose schema have =
=93returned=94 set to =93always=94 (e.g. =93id=94). The default =

   attribute set are =
those attributes whose schema have =93returned=94 set to

   =93default=94.

   Clients MAY request a =
partial resource representation on any
   operation that returns a resource by specifying either the URL query =
parameter

   =
=93attributes=94 OR =93excludedAttributes=94 as follows:

   attributes When specified, each resource =
returned MUST contain the minimal =
set

      of resource attributes and MUST =
contain no other attributes or =
sub-attributes

      other than those =
explicitly requested.  The query =
parameter attributes value is a

      comma =
separated list of resource =
attribute names in standard attribute notation

      (Sec=
tion 3.8) form (e.g.  userName, name, emails).

   excludedAttributes =
When specified, each =
resourcereturned MUST contain the =
minimal

      set of resource =
attributes and any attributes normally =
returned by =93default=94

      minus =
those attributes listed in =93excludedAttributes=94. The query =
parameter

      excludedAttributes value =
is a comma separated list of =
resource attribute names in

      =
standard attribute notation (Section 3.8) form (e.g.  userName, name, emails).

Section 3.2.3 Query Resources Using =
HTTP POST
attributes  A =
multi-valued list of strings indicating the names of
      resource attributes to return in the response overriding the =
set
      of attributes =
that would be returned by default.  =
Attribute names
   =
   MUST be in standard attribute notation (Sec=
tion 3.8) form.  See
      additional operation response parameters (Sec=
tion 3.7).  OPTIONAL.

excludedAttributes A multi-valued list of strings indicating =
the names
      =
of attributes to be removed from the default set of attributes to =
      be returned. =
=93excludedAttributes=94 SHALL have no affect on attributes
      whose =93returned=94=
 characteristic is =93always=94 (Section 11 =
[core-schema]). 
      Attribute names =
MUST be in standard attribute =
notation (Section 3.8) form.
      See additional operation response parameters =
(Section 3.7).  =
OPTIONAL.

Does this = work?

Phil

@independenti= d

= --Apple-Mail=_BF0010EA-8DF2-4A84-91A4-39E70CC27DCD-- From nobody Thu May 1 12:06: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 450911A6FCC for ; Thu, 1 May 2014 12:06:21 -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 ZPfVqpkG07sz for ; Thu, 1 May 2014 12:06:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7FC1A0928 for ; Thu, 1 May 2014 12:06:17 -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.929.12; Thu, 1 May 2014 19:06:14 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) with mapi id 15.00.0929.001; Thu, 1 May 2014 19:06:14 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Ticket 3: excludedAttributes parameter proposal Thread-Index: AQHPZW/Io2XqRjEH2kWudLcv+HP6fpssFdpQ Date: Thu, 1 May 2014 19:06:13 +0000 Message-ID: <518e0602eca6415f93ee85ddcaafaefa@BN1PR04MB392.namprd04.prod.outlook.com> References: <290C8267-675D-4B98-B37C-F90595428586@oracle.com> In-Reply-To: <290C8267-675D-4B98-B37C-F90595428586@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 051ACEFC007058051AD049 x-originating-ip: [2605:6000:0:8::f:9] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(77982001)(50986999)(74316001)(4396001)(92566001)(54356999)(31966008)(99286001)(76176999)(16236675002)(79102001)(46102001)(20776003)(76482001)(19300405004)(85852003)(16601075003)(99396002)(80022001)(86362001)(80976001)(83322001)(76576001)(561944002)(19580395003)(19580405001)(33646001)(83072002)(74662001)(74502001)(101416001)(15202345003)(15975445006)(2656002)(87936001)(81542001)(81342001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:EC4CC1D6.ACF6B1E0.A9F53DBB.46EC8B83.20350; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_518e0602eca6415f93ee85ddcaafaefaBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ezvG34Ey5rqH3XeY5LuAiptgxf8 Subject: Re: [scim] Ticket 3: excludedAttributes parameter proposal X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:06:21 -0000 --_000_518e0602eca6415f93ee85ddcaafaefaBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slight typo here: resourcereturned. Otherwise, +1. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 01, 2014 2:00 PM To: scim@ietf.org WG Subject: [scim] Ticket 3: excludedAttributes parameter proposal Regarding the proposal to have an excludedAttributes parameter. We had a d= iscussion on the call this week, and there was some agreement that while th= e parameter is not critical to the needs of the protocol, it is useful from= the standpoint of developer and operational utility. For example, administ= rators attempting to query a SCIM endpoint directly may find it useful to s= pecify which attributes they do not want far more easier than listing all a= ttributes that could be returned to omit the one they do not returned. There was also some value in using excludedAttributes when doing a multi-re= sourceType search. The existing text on the "attributes" parameter: Section 3.7 Additional retrieval query parameters Clients MAY request a partial resource representation on any operation that returns a resource within the response by specifying the URL query parameter 'attributes'. When specified, each resource returned MUST contain the minimal set of resource attributes and MUST contain no other attributes or Sub-Attributes than those explicitly requested. The query parameter attributes value is a comma separated list of resource attribute names in standard attribute notation (Section 3.8) form (e.g. userName, name, emails). Section 3.2.3 Query Resources Using HTTP POST attributes A multi-valued list of strings indicating the names of resource attributes to return in the response. Attribute names MUST be in standard attribute notation (Section 3.8) form. See additional retrieval query parameters (Section 3.7). OPTIONAL. Proposed text: Section 3.7 Additional Operation Response Parameters For any SCIM operation where a resource representation is returned (e.g.= GET), the attributes normally returned are defined as the minimum attribute se= t plus the default attributes. The minimum attribute set are those attribu= tes whose schema have "returned" set to "always" (e.g. "id"). The default attribute set are those attributes whose schema have "returned" set to "default". Clients MAY request a partial resource representation on any operation that returns a resource by specifying either the URL query par= ameter "attributes" OR "excludedAttributes" as follows: attributes When specified, each resource returned MUST contain the minim= al set of resource attributes and MUST contain no other attributes or sub-at= tributes other than those explicitly requested. The query parameter attribute= s value is a comma separated list of resource attribute names in standard attribut= e notation (Section 3.8) form (e.g. userName, name, emails). excludedAttributes When specified, each resourcereturned MUST contain th= e minimal set of resource attributes and any attributes normally returned by "d= efault" minus those attributes listed in "excludedAttributes". The query para= meter excludedAttributes value is a comma separated list of resource attrib= ute names in standard attribute notation (Section 3.8) form (e.g. userName, name, emails). Section 3.2.3 Query Resources Using HTTP POST attributes A multi-valued list of strings indicating the names of resource attributes to return in the response overriding the set of attributes that would be returned by default. Attribute names MUST be in standard attribute notation (Section 3.8) form. See additional operation response parameters (Section 3.7). OPTIONAL. excludedAttributes A multi-valued list of strings indicating the names of attributes to be removed from the default set of attributes to be returned. "excludedAttributes" SHALL have no affect on attributes whose "returned" characteristic is "always" (Section 11 [core-schema]= ). Attribute names MUST be in standard attribute notation (Section 3.8) form. See additional operation response parameters (Section 3.7). OPTIONAL. Does this work? Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_518e0602eca6415f93ee85ddcaafaefaBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Slight typo here: resourcereturned.

Otherwise, +1.

<= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 01, 2014 2:00 PM
To: scim@ietf.org WG
Subject: [scim] Ticket 3: excludedAttributes parameter proposal=

Regarding the proposal to have an excludedAttributes= parameter. We had a discussion on the call this week, and there was = some agreement that while the parameter is not critical to the needs of the= protocol, it is useful from the standpoint of developer and operational utility. For example, administrators attempti= ng to query a SCIM endpoint directly may find it useful to specify which at= tributes they do not want far more easier than listing all attributes that = could be returned to omit the one they do not returned.

There was also some value in using excludedAttribute= s when doing a multi-resourceType search.

The existing text on the “attributes”= parameter:

Section 3.7 Additional retrieval query parameters

&n=
bsp;  Clients MAY request a partial resource representation on any

&n=
bsp;  operation that returns a resource within the response by specify=
ing

&n=
bsp;  the URL query parameter 'attributes'.  When specified, each=
 resource

&n=
bsp;  returned MUST contain the minimal set of resource attributes and=
 MUST

&n=
bsp;  contain no other attributes or Sub-Attributes than those explici=
tly

&n=
bsp;  requested.  The query parameter attributes value is a comma=
 separated

&n=
bsp;  list of resource attribute names in standard attribute notation<=
o:p>

&n=
bsp;  (Section 3.8) form (e.g.  userName, name, emails).<=
/o:p>

Section 3.2.3 Query Resources Using HTTP POST

at=
tributes  A multi-valued list of strings indicating the names of<=
/o:p>

&n=
bsp;     resource attributes to return in the response.=
  Attribute names

&n=
bsp;     MUST be in standard attribute notation (Section=
 3.8) form.  See

&n=
bsp;     additional retrieval query parameters (Section =
3.7).  OPTIONAL.

Proposed text:

Section 3.7 Additional Operation Response Parameters=

&n=
bsp;  For any SCIM operation where a resource representation is return=
ed (e.g. GET),

&n=
bsp;  the attributes normally returned are defined as the minimum attr=
ibute set

&n=
bsp;  plus the default attributes. The minimum attribute set are =
those attributes

&n=
bsp;  whose schema have “returned” set to “alwa=
ys” (e.g. “id”). The default

&n=
bsp;  attribute set are those attributes whose schema have “=
;returned” set to

&n=
bsp;  “default”.

&n=
bsp;  Clients MAY request a partial resource representation on any

&n=
bsp;  operation that returns a resource by specifying either the URL q=
uery parameter

&n=
bsp;  “attributes” OR “excludedAttributes”=
; as follows:

&n=
bsp;  attributes When specified, each resource returned MUST contain t=
he minimal set

&n=
bsp;     of resource attributes and MUST contain no oth=
er attributes or sub-attributes

&n=
bsp;     other than those explicitly requested.  T=
he query parameter attributes value is a

&n=
bsp;     comma separated list of resource attribute nam=
es in standard attribute notation

&n=
bsp;     (Section 3.8) form (e.g.  userName, na=
me, emails).

&n=
bsp;  excludedAttributes When specified, each resourcereturned MUST co=
ntain the minimal

&n=
bsp;     set of resource attributes and any attrib=
utes normally returned by “default” 
&n=
bsp;     minus those attributes listed in “e=
xcludedAttributes”. The query parameter 
&n=
bsp;     excludedAttributes value is a comma separated =
list of resource attribute names in 
&n=
bsp;     standard attribute notation (Section 3.8) f=
orm (e.g.  userName, name, emails).



Section 3.2.3 Query =
Resources Using HTTP POST

at=
tributes  A multi-valued list of strings indicating the names of<=
/o:p>
&n=
bsp;     resource attributes to return in the response =
overriding the set
&n=
bsp;     of attributes that would be returned by defaul=
t.  Attribute names
&n=
bsp;     MUST be in standard attribute notation (Section=
 3.8) form.  See
&n=
bsp;     additional operation response parameters (Secti=
on 3.7).  OPTIONAL.



ex=
cludedAttributes A multi-valued list of strings indicating the names
&n=
bsp;     of attributes to be removed from the default s=
et of attributes to 
&n=
bsp;     be returned. “excludedAttributes=
221; SHALL have no affect on attributes
&n=
bsp;     whose “returned” characteristic is=
 “always” (Section 11 [core-schema]). 
&n=
bsp;     Attribute names MUST be in standard attribute =
notation (Section 3.8) form.
&n=
bsp;     See additional operation response parameters (=
S=
ection 3.7).  OPTIONAL.

Does this work?=

Phil

@independentid<= /span>

https://developers.google.com/admin-sdk/directory/v1/gu= ides/performance#patch

--_000_518e0602eca6415f93ee85ddcaafaefaBN1PR04MB392namprd04pro_-- From nobody Thu May 1 12:11:33 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 30E261A6FF2 for ; Thu, 1 May 2014 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, 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 GayZGtdH717r for ; Thu, 1 May 2014 12:11:29 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) by ietfa.amsl.com (Postfix) with ESMTP id ADB581A6FC7 for ; Thu, 1 May 2014 12:11:27 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 1 May 2014 21:11:23 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0775.031; Thu, 1 May 2014 21:11:05 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Ticket 65 HTTP Method Override Thread-Index: AQHPZKl3b3WfNtv44kG9pwd9aiN2+ZsqlHeAgACd8ACAAArCAIAAIEKAgABdgYCAABx3AIAAA/oAgAAUXACAAAefgA== Date: Thu, 1 May 2014 19:11:05 +0000 Message-ID: <83B945FA-5B84-4CF0-A9D6-7B4885FBCEDD@nexusgroup.com> References: <16F5FF43-C8D4-4E29-8094-66C834A32AC5@mnt.se> <5362001A.5070405@gmx.de>

<54ce1b3d515d4219a83aa1b466d039d0@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_83B945FA5B844CF0A9D67B4885FBCEDDnexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/PxhmK_3cLlTWprN8eMcOPntitgw Cc: Julian Reschke , Leif Johansson , Ian Glazer , "scim@ietf.org WG" , Kelly Grizzle Subject: Re: [scim] Ticket 65 HTTP Method Override X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:11:32 -0000 --_000_83B945FA5B844CF0A9D67B4885FBCEDDnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My worry is that it=92s kinda used all over the place when it comes to exis= ting user APIs. No time to dig up too many examples, but here are two: Googles user api. https://developers.google.com/admin-sdk/directory/v1/guides/performance#pat= ch MS OData http://msdn.microsoft.com/en-us/library/dd541471.aspx I guess there is a good reason why it=92s there. It can=92t be just Blackbe= rrys http client implementation? :) / Erik On 01 May 2014, at 20:43, Phil Hunt > wrote: I can=92t say yes quite yet. I will check with my colleagues. My reaction agrees with the point Kelly made on the call this week that if = someone really needs it, the defacto standard technique should be sufficien= t without us having to specify it. I=92d rather have SCIM focus on the int= ended proper usage of HTTP. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 1, 2014, at 10:30 AM, Kelly Grizzle > wrote: Works for me. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Thursday, May 01, 2014 12:17 PM To: Ian Glazer Cc: Julian Reschke; scim@ietf.org WG; Phil Hunt; Kell= y Grizzle Subject: Re: [scim] Ticket 65 HTTP Method Override thus I propose closinf with wontfix 1 maj 2014 kl. 17:34 skrev Ian Glazer >: We've got out own problems to worry about; we don't need to clean up other = people's backyards for them. On Thu, May 1, 2014 at 6:00 AM, Leif Johansson > wrote: > 1 maj 2014 kl. 10:04 skrev Julian Reschke >: > >> On 2014-05-01 09:26, Leif Johansson wrote: >> It sure feels like bb needs to fix their browser... Or if tjhey feel >> strongly about it, turn up and spec out a standard http header.... and >> get others to play. >> ... > > Is this about XMLHTTPRequest in the Blackberry browser? Is this a known b= ug? Has it been reported to Blackberry? > who knows. not sure scim needs to care though... > Best regards, Julian _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_83B945FA5B844CF0A9D67B4885FBCEDDnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4AB5F174DD0FA640BD827A33992F9626@nexusgroup.com> Content-Transfer-Encoding: quoted-printable

My worry is that it=92s kinda used all over the place when it comes to= existing user APIs. No time to dig up too many examples, but here ar= e two:

Googles user api.

MS OData

http= ://msdn.microsoft.com/en-us/library/dd541471.aspx

I guess there is a good reason why it=92s there. It can=92t be just Bl= ackberrys http client implementation? :)

/ Erik

On 01 May 2014, at 20:43, Phil Hunt <phil.hunt@oracle.com> wrote:

I can=92t say yes quite yet. I will check with my colleagues.

My reaction agrees with the point Kelly made on the call this week tha= t if someone really needs it, the defacto standard technique should be suff= icient without us having to specify it. I=92d rather have SCIM focus = on the intended proper usage of HTTP.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On May 1, 2014, at 10:30 AM, Kelly Grizzle <

Works for me.

From:<= /span> Leif Johansson [mailto:leifj@mnt.se]
Sent: Thursday, Ma= y 01, 2014 12:17 PM
To: Ian Glazer
Cc: Julian Reschke= ; scim@ietf.or= g WG; Phil Hunt; Kelly Grizzle
Subject: Re: [scim= ] Ticket 65 HTTP Method Override

thus I propose closinf with wontfix

1 maj 2014 kl. 17:34 skrev Ian Glazer <iglazer@sales= force.com>:

We've got out own problems to worry about; we don't need to clean up other = people's backyards for them.

On Thu, May 1, 2014 at 6:00 AM, Leif Johansson <leifj@mnt.se> wrote:

> 1 maj 2014 kl. 10:04 skrev Julian Reschke <julia= n.reschke@gmx.de>:

>
>> On 2014-05-01 09:26, Leif Johansson wrote:
>> It sure feels like bb needs to fix their browser... Or if tjhey fe= el
>> strongly about it, turn up and spec out a standard http header....= and
>> get others to play.
>> ...
>
> Is this about XMLHTTPRequest in the Blackberry browser? Is this a know= n bug? Has it been reported to Blackberry?
>

who knows. not sure scim needs to care though...

> Best regards, Julian

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

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

@iglazer

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

--_000_83B945FA5B844CF0A9D67B4885FBCEDDnexusgroupcom_-- From nobody Thu May 1 12:13:18 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 DC2671A6FF2 for ; Thu, 1 May 2014 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 6IC1Ctu4CjqM for ; Thu, 1 May 2014 12:13:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id D62C41A6FC7 for ; Thu, 1 May 2014 12:13:10 -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.929.12; Thu, 1 May 2014 19:13:07 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) with mapi id 15.00.0929.001; Thu, 1 May 2014 19:13:06 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "Phil Hunt" Thread-Topic: [scim] Ticket 65 HTTP Method Override Thread-Index: AQHPZKl0T8YeZCVnq0i9mHXAtzj1XZsqtT8AgACerwCAAArCAIAAIEKAgABdgYCAABx3AIAAA/OAgAAUYwCAAAeggIAAAG4g Date: Thu, 1 May 2014 19:13:06 +0000 Message-ID: References: <16F5FF43-C8D4-4E29-8094-66C834A32AC5@mnt.se> <5362001A.5070405@gmx.de>

<54ce1b3d515d4219a83aa1b466d039d0@BN1PR04MB392.namprd04.prod.outlook.com> <83B945FA-5B84-4CF0-A9D6-7B4885FBCEDD@nexusgroup.com> In-Reply-To: <83B945FA-5B84-4CF0-A9D6-7B4885FBCEDD@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 05211D0C00705805211E59 x-originating-ip: [2605:6000:0:8::f:9] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(51704005)(377424004)(377454003)(189002)(199002)(24454002)(77982001)(50986999)(74316001)(4396001)(92566001)(54356999)(31966008)(99286001)(76176999)(16236675002)(79102001)(46102001)(20776003)(76482001)(19300405004)(85852003)(99396002)(80022001)(86362001)(80976001)(83322001)(76576001)(19580395003)(19580405001)(33646001)(83072002)(74662001)(74502001)(101416001)(15202345003)(15975445006)(2656002)(87936001)(81542001)(81342001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:DECED134.AED61DE0.39F11DAB.4667F8D1.203E1; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_d37a924732b3433394e9c190e0711fdaBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9RiZEN8XkrhUbAbOnFEttUmwfJY Cc: Julian Reschke , Leif Johansson , Ian Glazer , "scim@ietf.org WG" Subject: Re: [scim] Ticket 65 HTTP Method Override X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:13:14 -0000 --_000_d37a924732b3433394e9c190e0711fdaBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have heard that some proxy servers may strip out certain HTTP methods, bu= t I have no first-hand experience with this. From: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexusgroup.com] Sent: Thursday, May 01, 2014 2:11 PM To: Phil Hunt Cc: Kelly Grizzle; Julian Reschke; Leif Johansson; Ian Glazer; scim@ietf.or= g WG Subject: Re: [scim] Ticket 65 HTTP Method Override My worry is that it's kinda used all over the place when it comes to existi= ng user APIs. No time to dig up too many examples, but here are two: Googles user api. https://developers.google.com/admin-sdk/directory/v1/guides/performance#pat= ch MS OData http://msdn.microsoft.com/en-us/library/dd541471.aspx I guess there is a good reason why it's there. It can't be just Blackberrys= http client implementation? :) / Erik On 01 May 2014, at 20:43, Phil Hunt > wrote: I can't say yes quite yet. I will check with my colleagues. My reaction agrees with the point Kelly made on the call this week that if = someone really needs it, the defacto standard technique should be sufficien= t without us having to specify it. I'd rather have SCIM focus on the inten= ded proper usage of HTTP. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 1, 2014, at 10:30 AM, Kelly Grizzle > wrote: Works for me. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Thursday, May 01, 2014 12:17 PM To: Ian Glazer Cc: Julian Reschke; scim@ietf.org WG; Phil Hunt; Kell= y Grizzle Subject: Re: [scim] Ticket 65 HTTP Method Override thus I propose closinf with wontfix 1 maj 2014 kl. 17:34 skrev Ian Glazer >: We've got out own problems to worry about; we don't need to clean up other = people's backyards for them. On Thu, May 1, 2014 at 6:00 AM, Leif Johansson > wrote: > 1 maj 2014 kl. 10:04 skrev Julian Reschke >: > >> On 2014-05-01 09:26, Leif Johansson wrote: >> It sure feels like bb needs to fix their browser... Or if tjhey feel >> strongly about it, turn up and spec out a standard http header.... and >> get others to play. >> ... > > Is this about XMLHTTPRequest in the Blackberry browser? Is this a known b= ug? Has it been reported to Blackberry? > who knows. not sure scim needs to care though... > Best regards, Julian _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_d37a924732b3433394e9c190e0711fdaBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have heard that some pr= oxy servers may strip out certain HTTP methods, but I have no first-hand ex= perience with this.

<= /p>

From: Erik Wah= lstr=F6m [mailto:erik.wahlstrom@nexusgroup.com]
Sent: Thursday, May 01, 2014 2:11 PM
To: Phil Hunt
Cc: Kelly Grizzle; Julian Reschke; Leif Johansson; Ian Glazer; scim@= ietf.org WG
Subject: Re: [scim] Ticket 65 HTTP Method Override=

My worry is that it’s kinda used all over the = place when it comes to existing user APIs. No time to dig up too many examp= les, but here are two:

Googles user api.

https://developers.google.com/admin-s= dk/directory/v1/guides/performance#patch

MS OData

http://msdn.microsoft.com/en-us/library/dd541471.aspx

I guess there is a good reason why it’s there.= It can’t be just Blackberrys http client implementation? :)

/ Erik

On 01 May 2014, at 20:43, Phil Hunt <phil.hunt@oracle.com> wrote:<= /p>

I can’t say yes quite yet. I wil= l check with my colleagues.

My reaction agrees with the point Kell= y made on the call this week that if someone really needs it, the defacto s= tandard technique should be sufficient without us having to specify it. I’d rather have SCIM focus on the intended prop= er usage of HTTP.

Phil

@independentid

http://trac.too= ls.ietf.org/wg/scim/trac/ticket/13

On May 1, 2014, at 10:30 AM, Kelly Gri= zzle <kelly.grizzle@sailpoint.com> wrote:

Works for me.=

<= /p>

From: Leif Johansson [ma= ilto:leifj@mnt.se]
Sent: Thursday, Ma= y 01, 2014 12:17 PM
To: Ian Glazer
Cc: Julian Reschke= ; scim@ietf.org WG; Phil Hunt; Kelly Grizzle
Subject: Re: [scim= ] Ticket 65 HTTP Method Override

thus I propose closinf with wontfix

1 maj 2014 kl. 17:34 skrev Ian Glazer <iglazer@salesforce.com>= :

We've got out own problems to worry about; we don't = need to clean up other people's backyards for them.

On Thu, May 1, 2014 at 6:00 AM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote:

> 1 maj 2014 kl. 10:04 skrev Julian Reschke <julian.reschke@gmx.de<= /a>>:

>
>> On 2014-05-01 09:26, Leif Johansson wrote:
>> It sure feels like bb needs to fix their browser... Or if tjhey fe= el
>> strongly about it, turn up and spec out a standard http header....= and
>> get others to play.
>> ...
>
> Is this about XMLHTTPRequest in the Blackberry browser? Is this a know= n bug? Has it been reported to Blackberry?
>

who knows. not sure scim needs to care though...

> Best regards, Julian

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

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

@iglazer

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

--_000_d37a924732b3433394e9c190e0711fdaBN1PR04MB392namprd04pro_-- From nobody Thu May 1 12:42: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 539B91A6FBC for ; Thu, 1 May 2014 12:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 YgvA6x745m3k for ; Thu, 1 May 2014 12:42:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D81A6F78 for ; Thu, 1 May 2014 12:42:13 -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 s41JgApv025080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 May 2014 19:42:11 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 s41Jg9Dd014220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 May 2014 19:42:10 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s41Jg9Pd017472 for ; Thu, 1 May 2014 19:42:09 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 May 2014 12:42:09 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_7AF9D294-AB8F-4931-B50D-A6FA4DA2E147" Message-Id: Date: Thu, 1 May 2014 12:42:07 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/M4emTnMcQboqH-3cPHMSWG6biMM Subject: [scim] Ticket 13, required flag for etags X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:42:15 -0000 --Apple-Mail=_7AF9D294-AB8F-4931-B50D-A6FA4DA2E147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Does anybody have any explanation of this ticket? =20 http://trac.tools.ietf.org/wg/scim/trac/ticket/13 This is one of the old tickets from SCIM 1. The explanation here = https://code.google.com/p/scim/issues/detail?id=3D92 didn=92t provide = any more detail. I=92m wondering if what is meant is whether the server configuration = should indicate whether etags are =93supported=94 rather than = =93required=94. Section 12.5 of core-schema already indicates that the service provider = config includes an attribute etags whose sub attribute =93supported=92 = indicated that the server supports etags. Was there something else? Or, is this just a ticket that should have been closed a long time ago? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_7AF9D294-AB8F-4931-B50D-A6FA4DA2E147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Does anybody have any explanation of this = ticket?

This is one of = the old tickets from SCIM 1. The explanation = here https://code.google.com/p/scim/issues/detail?id=3D92 didn=92t = provide any more detail.

I=92m wondering if = what is meant is whether the server configuration should indicate = whether etags are =93supported=94 rather than = =93required=94.

Section 12.5 of core-schema = already indicates that the service provider config includes an attribute = etags whose sub attribute =93supported=92 indicated that the server = supports etags.

Was there something = else?

Or, is this just a ticket that should = have been closed a long time ago?

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

= --Apple-Mail=_7AF9D294-AB8F-4931-B50D-A6FA4DA2E147-- From nobody Thu May 1 12:45:25 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 BD1D91A091A for ; Thu, 1 May 2014 12:45:23 -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 u_EnDBlLtciZ for ; Thu, 1 May 2014 12:45:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 183481A6FBC for ; Thu, 1 May 2014 12:45:20 -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.929.12; Thu, 1 May 2014 19:45:17 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) with mapi id 15.00.0929.001; Thu, 1 May 2014 19:45:17 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Ticket 13, required flag for etags Thread-Index: AQHPZXV4F4sxuuGcrEybZRYkGlLZF5ssIFDw Date: Thu, 1 May 2014 19:45:17 +0000 Message-ID: <206127dda63a4c76a5716e553256f15b@BN1PR04MB392.namprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 053E95B5007058053E9702 x-originating-ip: [2605:6000:0:8::f:9] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(77982001)(50986999)(74316001)(4396001)(92566001)(54356999)(31966008)(99286001)(76176999)(16236675002)(79102001)(46102001)(20776003)(19300405004)(76482001)(85852003)(16601075003)(99396002)(80022001)(86362001)(80976001)(83322001)(76576001)(19580395003)(19580405001)(33646001)(83072002)(74662001)(74502001)(101416001)(15202345003)(15975445006)(2656002)(87936001)(81342001)(81542001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:AE4CC5FC.A6F6B3C0.23DEBFFF.4696F8C3.2023A; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_206127dda63a4c76a5716e553256f15bBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/A1Hg4k6HQ_iLeMc_16_1NJP4Ds8 Subject: Re: [scim] Ticket 13, required flag for etags X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:45:23 -0000 --_000_206127dda63a4c76a5716e553256f15bBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IIRC this came up at a SCIM interop event. The SCIM Proxy server supported= ETags and failed if they were not supplied by the client. However, it see= med like the correct behavior was to accept client requests with or without= an ETag. My understanding of the "supported" attribute was that the serve= r accepted ETags but they were not mandatory for the client to send. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 01, 2014 2:42 PM To: scim@ietf.org WG Subject: [scim] Ticket 13, required flag for etags Does anybody have any explanation of this ticket? http://trac.tools.ietf.org/wg/scim/trac/ticket/13 This is one of the old tickets from SCIM 1. The explanation here https://c= ode.google.com/p/scim/issues/detail?id=3D92 didn't provide any more detail. I'm wondering if what is meant is whether the server configuration should i= ndicate whether etags are "supported" rather than "required". Section 12.5 of core-schema already indicates that the service provider con= fig includes an attribute etags whose sub attribute "supported' indicated t= hat the server supports etags. Was there something else? Or, is this just a ticket that should have been closed a long time ago? Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_206127dda63a4c76a5716e553256f15bBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IIRC this came up at a SC= IM interop event. The SCIM Proxy server supported ETags and failed if= they were not supplied by the client. However, it seemed like the correct behavior was to accept client requests with or without an ETag= . My understanding of the “supported” attribute was that = the server accepted ETags but they were not mandatory for the client to sen= d.

<= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 01, 2014 2:42 PM
To: scim@ietf.org WG
Subject: [scim] Ticket 13, required flag for etags=

Does anybody have any explanation of this ticket? &n= bsp;

http://trac.tools.ietf.org/wg/scim/trac/ticket/13<= /p>

This is one of the old tickets from SCIM 1. Th= e explanation here https://code.google.com/p/scim/issues/detail?id=3D92 didn= ’t provide any more detail.

I’m wondering if what is meant is whether the = server configuration should indicate whether etags are “supportedR= 21; rather than “required”.

Section 12.5 of core-schema already indicates that t= he service provider config includes an attribute etags whose sub attribute = “supported’ indicated that the server supports etags.

Was there something else?

Or, is this just a ticket that should have been clos= ed a long time ago?

Phil

@independentid<= /span>

--_000_206127dda63a4c76a5716e553256f15bBN1PR04MB392namprd04pro_-- From nobody Thu May 1 12:46: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 15E701A6FD4 for ; Thu, 1 May 2014 12:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 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.651, 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 7Qk4Ch3OK1nK for ; Thu, 1 May 2014 12:46:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6821A6FBC for ; Thu, 1 May 2014 12:46:51 -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 s41JkmNq016777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 May 2014 19:46:49 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 s41Jkl1h001689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 May 2014 19:46:47 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s41Jkkia001671; Thu, 1 May 2014 19:46:47 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 May 2014 12:46:46 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFC991B2-BDD3-4FEA-9833-0A914222CBAF" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <206127dda63a4c76a5716e553256f15b@BN1PR04MB392.namprd04.prod.outlook.com> Date: Thu, 1 May 2014 12:46:45 -0700 Message-Id: <3EA1BE6B-0926-418E-A8E1-A2289BD0E638@oracle.com> References: <206127dda63a4c76a5716e553256f15b@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QJEqfW7Ek-SWu7WuNkpYzuBJTo0 Cc: "scim@ietf.org WG" Subject: Re: [scim] Ticket 13, required flag for etags X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:46:53 -0000 --Apple-Mail=_BFC991B2-BDD3-4FEA-9833-0A914222CBAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My understanding of etags is that they are always optional. =46rom an = interop perspective a server can=92t require them. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 1, 2014, at 12:45 PM, Kelly Grizzle = wrote: > IIRC this came up at a SCIM interop event. The SCIM Proxy server = supported ETags and failed if they were not supplied by the client. = However, it seemed like the correct behavior was to accept client = requests with or without an ETag. My understanding of the =93supported=94= attribute was that the server accepted ETags but they were not = mandatory for the client to send. > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, May 01, 2014 2:42 PM > To: scim@ietf.org WG > Subject: [scim] Ticket 13, required flag for etags > =20 > Does anybody have any explanation of this ticket? =20 > http://trac.tools.ietf.org/wg/scim/trac/ticket/13 > =20 > This is one of the old tickets from SCIM 1. The explanation here = https://code.google.com/p/scim/issues/detail?id=3D92 didn=92t provide = any more detail. > =20 > I=92m wondering if what is meant is whether the server configuration = should indicate whether etags are =93supported=94 rather than = =93required=94. > =20 > Section 12.5 of core-schema already indicates that the service = provider config includes an attribute etags whose sub attribute = =93supported=92 indicated that the server supports etags. > =20 > Was there something else? > =20 > Or, is this just a ticket that should have been closed a long time = ago? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_BFC991B2-BDD3-4FEA-9833-0A914222CBAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 My = understanding of etags is that they are always optional. =46rom an = interop perspective a server can=92t require them.

Phil

@independentid

http://tools.ietf.org/html/d= raft-ietf-scim-api-04#section-2

On May 1, 2014, at 12:45 PM, Kelly Grizzle = <kelly.grizzle@sailpoint.com> wrote:

IIRC this came up at a SCIM interop event. = The SCIM Proxy server supported ETags and failed if they were not = supplied by the client. However, it seemed like the correct behavior was to accept client requests with or without an = ETag. My understanding of the =93supported=94 attribute was that = the server accepted ETags but they were not mandatory for the client to = send.

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 01, 2014 2:42 PM
To: scim@ietf.org WG
Subject: [scim] Ticket 13, required flag for = etags

Does anybody have any explanation of this = ticket?

http://trac.too= ls.ietf.org/wg/scim/trac/ticket/13

This is one of the old tickets from SCIM 1. = The explanation here https://code= .google.com/p/scim/issues/detail?id=3D92 didn=92t provide any more = detail.

I=92m wondering if what is meant is whether = the server configuration should indicate whether etags are =93supported=94= rather than =93required=94.

Section 12.5 of core-schema already = indicates that the service provider config includes an attribute etags = whose sub attribute =93supported=92 indicated that the server supports = etags.

Was there something else?

Or, is this just a ticket that should have = been closed a long time ago?

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

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

= --Apple-Mail=_BFC991B2-BDD3-4FEA-9833-0A914222CBAF-- From nobody Thu May 1 13:09: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 A4CE11A6F8C for ; Thu, 1 May 2014 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 WeKJjF9TyWna for ; Thu, 1 May 2014 13:09:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C5A641A0974 for ; Thu, 1 May 2014 13:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9620; q=dns/txt; s=iport; t=1398974962; x=1400184562; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DA35SbzuPv8K+NiYKiEEjl3Yr2+huuexWAuCX4+Pz/8=; b=QyYIB722Nd4ceq4Kqn0WsA/f40Mfy5dOEP2FKwYOjruWaTwK3DmBJbBO i1mFSMEUrbrlishngxErwRphmRdAR8k0SJAPR30Xl0XTnO4Y9yBK+J3IN SaHIy8An8W7kr90MMJi8tlPN81ZBQBqpK/Z67vqOn+aRYHlXS5XRolGSq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAC6pYlOtJA2N/2dsb2JhbABRBgOCQkRPV70cAYc9gRQWdIIlAQEBAwEBAQEqQQsFCwIBCBEDAQEBAScHJwsUCQgCBAENBYgtAwkHAQ3JZBMEiTGCEniBPBY0AQwEBgERhCgEmS+SboMzgis X-IronPort-AV: E=Sophos; i="4.97,966,1389744000"; d="scan'208,217"; a="40346266" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 01 May 2014 20:09:21 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s41K9LN0032309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 20:09:21 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 1 May 2014 15:09:20 -0500 From: "Morteza Ansari (moransar)" To: Kelly Grizzle , Leif Johansson , Ian Glazer Thread-Topic: [scim] Ticket 65 HTTP Method Override Thread-Index: AQHPZKl3y/P+0+f1Pkii5uQ/5EjnzpsrCdCAgACd8ACAAArCAIAAIEGAgABdgoCAABx3AIAAA/oA//+2xQA= Date: Thu, 1 May 2014 20:09:20 +0000 Message-ID: References: <16F5FF43-C8D4-4E29-8094-66C834A32AC5@mnt.se> <5362001A.5070405@gmx.de>

<54ce1b3d515d4219a83aa1b466d039d0@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <54ce1b3d515d4219a83aa1b466d039d0@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.1.140326 x-originating-ip: [171.68.20.40] Content-Type: multipart/alternative; boundary="_000_CF87F77CDB4A7moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DsyPPgRCK59MN-C0b7qDcP1H-YI Cc: Julian Reschke , "scim@ietf.org WG" , Phil Hunt Subject: Re: [scim] Ticket 65 HTTP Method Override X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:09:25 -0000 --_000_CF87F77CDB4A7moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We already had asked this question and the consensus was to remove it until= Kelly reported the BB problem. Given Kelly is OK with this after the conv= ersation, I think it is safe to move forward and close this ticket as wontf= ix. Cheers, Morteza From: Kelly Grizzle > Date: Thursday, May 1, 2014 at 10:30 AM To: Leif Johansson >, Ian Glazer > Cc: Julian Reschke >, "= scim@ietf.org" >,= Phil Hunt > Subject: Re: [scim] Ticket 65 HTTP Method Override Works for me. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Thursday, May 01, 2014 12:17 PM To: Ian Glazer Cc: Julian Reschke; scim@ietf.org WG; Phil Hunt; Kell= y Grizzle Subject: Re: [scim] Ticket 65 HTTP Method Override thus I propose closinf with wontfix 1 maj 2014 kl. 17:34 skrev Ian Glazer >: We've got out own problems to worry about; we don't need to clean up other = people's backyards for them. On Thu, May 1, 2014 at 6:00 AM, Leif Johansson > wrote: > 1 maj 2014 kl. 10:04 skrev Julian Reschke >: > >> On 2014-05-01 09:26, Leif Johansson wrote: >> It sure feels like bb needs to fix their browser... Or if tjhey feel >> strongly about it, turn up and spec out a standard http header.... and >> get others to play. >> ... > > Is this about XMLHTTPRequest in the Blackberry browser? Is this a known b= ug? Has it been reported to Blackberry? > who knows. not sure scim needs to care though... > Best regards, Julian _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_CF87F77CDB4A7moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

We already had asked this question and the consensus was to remove it = until Kelly reported the BB problem. Given Kelly is OK with this afte= r the conversation, I think it is safe to move forward and close this ticke= t as wontfix.

Cheers,

Morteza

--_000_CF87F77CDB4A7moransarciscocom_-- From nobody Thu May 1 13:11: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 878941A6FDC for

_______________________________________________<= br clear=3D"none">scim mailing list
scim@ietf.org=
https://www.ietf.org/mailman/listinfo/scim

__________________________= _____________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listi= nfo/scim

= --Apple-Mail-D152FE35-68E5-4697-962F-BA11ABDCCD3B-- From nobody Sat May 3 11:06: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 06D5E1A00F1 for ; Sat, 3 May 2014 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, 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 n9Hj802FDDnd for ; Sat, 3 May 2014 11:06:44 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with ESMTP id 779401A00E4 for ; Sat, 3 May 2014 11:06:44 -0700 (PDT) Received: from [66.196.81.172] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 03 May 2014 18:03:45 -0000 Received: from [98.139.212.250] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 03 May 2014 18:03:44 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 03 May 2014 18:03:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 767768.63115.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 45840 invoked by uid 60001); 3 May 2014 18:03:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399140224; bh=yG4p5nCEMBzCSjs0Vt4hOIuOEYvGCG0K9fC6OELhWFQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hSM5GJGNkdI0Vh0oFT/NTsJlby036bjY5zq5WQpGPYmPc1vWc6W4a093o9f3sKuX/4cE8+IcKmT1n8blyhY6FgU8VSIMnL6uL7QtSZPFwAiJ7WCSJi5k7BvMFt68zFi2BJ3VQhtb6irhVd7UepzEma+pzcAIHIzpAWzRwNm1c9A= X-YMail-OSG: 0FZyJesVM1mN6dv8zupQmzwNeVS3lPqHP0sHXVfATFZ7YvF yxThO03f1YbLp2vWagivw9EV7bVnYDUprOh6nUZR8DJQTQNE4ykf65kqbrTr .DB9JZb3Ib6TJY6uM9TUUdADgYobE1bwPy02A9N_AAzv22YC.z9zSw.1qfX4 3RYj7ilH7za.SI5_wgo8AoAC.Xj61uJZ.HzUCiUmq9jxGDyWd4SkLTwHwAn3 Zawdbhnw8NLlAD1Q92ufgNcFUPHOc1q1MpGnFsoRTicHv4kYU4Uwfz8fjoOG QtqE7Ic3ay4mfipdNIeK2Ssdgwu5rySzOSc7WCbxZaHWL9Bt1eCYtX0L.jMl M.s43B5Pocz4N5NYs72Hz7_XsdBGV7tLF56s7zbWqD64LjaXgwKvB3RTDIwS 2Vi.o.KraQ5dieX4CCindu6QqxsJuxxrWBuIQADlemyOm9Jz8d.mQf6mDP6l UTC1NIUTQgdA4Q6WcvizbPjRN72U1hMFaxWZ_HcFXF_9vs5srbjIbw5PbKge x6rB8ABkTUYFBoA8GCOtru.7bzd0jaj80d3UAgU7pfCqSyz.52ku2g1OJD3K cuwJibtw1v1_bRO5LGOLiI.1aXPT.zuxm9ZIoUhkWg9Y.uO5FoJ3rJ4vvYUl WTIvNAeaKhRIiBI.fvcSLSFG_FZNbcADzx4XAbEVTZN9EhOl0 Received: from [99.31.212.42] by web142806.mail.bf1.yahoo.com via HTTP; Sat, 03 May 2014 11:03:44 PDT X-Rocket-MIMEInfo: 002.001, WWVwIEkgd2lsbCBiZSBhdCBJSVcKT24gU2F0dXJkYXksIE1heSAzLCAyMDE0IDEyOjQ2IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPiB3cm90ZToKIApCaWxsLAoKQXJlIHlvdSBnb2luZyB0byBJSVcgbmV4dCB3ZWVrPyBMZXQncyBjaGF0IHRoZW4uwqAKClBoaWwKCk9uIE1heSAyLCAyMDE0LCBhdCAyMjoxMywgQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gd3JvdGU6CgoKUmVndWxhciBTQ0lNIGF1dGguIMKgSSBqdXN0IGhhdmUgbmV2ZXIgbGlrZWQgdGhlIE9BdXRoIDIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <1399075236.11885.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1399091981.80767.YahooMailNeo@web142803.mail.bf1.yahoo.com> <49CFF628-1B22-4EEC-BD0C-362CBAC563B3@oracle.com> <1399094029.343.YahooMailNeo@web142806.mail.bf1.yahoo.com> <82772972-2F66-4560-AB77-151FE7DBF951@oracle.com> Message-ID: <1399140224.20640.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Sat, 3 May 2014 11:03:44 -0700 (PDT) From: Bill Mills To: Phil Hunt In-Reply-To: <82772972-2F66-4560-AB77-151FE7DBF951@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-251799921-1399140224=:20640" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/G4O7DHUnY3NHZ-RN0zoOaOedmyQ Cc: "scim@ietf.org" Subject: Re: [scim] signed JSON objects instead of OAuth 2? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:06:46 -0000 --515012262-251799921-1399140224=:20640 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yep I will be at IIW=0AOn Saturday, May 3, 2014 12:46 AM, Phil Hunt wrote:=0A =0ABill,=0A=0AAre you going to IIW next week? Let= 's chat then.=C2=A0=0A=0APhil=0A=0AOn May 2, 2014, at 22:13, Bill Mills wrote:=0A=0A=0ARegular SCIM auth. =C2=A0I just have n= ever liked the OAuth 2 solution much. =C2=A0What else can we do?=0A>On Frid= ay, May 2, 2014 9:56 PM, Phil Hunt wrote:=0A> =0A>Le= ts go back to basics. :-)=0A>=0A>=0A>What's the scenario where by you feel = you need jws?=0A>=0A>Phil=0A>=0A>On May 2, 2014, at 21:39, Bill Mills wrote:=0A>=0A>=0A>OAuth just isn't my favorite choice h= ere, in the end it's just a proxy for some other shared secret. =C2=A0A JWT= potentially cuts out the OAuth middleman.=0A>>On Friday, May 2, 2014 6:18 = PM, Phil Hunt wrote:=0A>> =0A>>I think the primary u= se case for SCIM was point-to-point provisioning which is sufficiently secu= red through the use of TLS. This might be further solidified by the work be= ing done in OAuth WG on POP/MAC tokens to provide mutual-authentication as = well as payload integrity and confidentiality.=0A>>=E2=80=94> this is a goo= d item for the security considerations.=0A>>=0A>>=0A>>=0A>>I think =E2=80= =9Csigning=E2=80=9D becomes relevant when SCIM payload data is being handle= d by intermediaries (handled by multiple entities) where it becomes importa= nt to prove that the data has not been altered in a multi-hop-path in an en= d-to-end security fashion.=0A>>=0A>>=0A>>Maybe this would be a good extensi= on?=0A>>=0A>>=0A>>What use case did you have in mind?=0A>>=0A>>=0A>>Phil=0A= >>=0A>>=0A>>@independentid=0A>>www.independentid.comphil.hunt@oracle.com=0A= >>=0A>>=0A>>=0A>>=0A>>On May 2, 2014, at 5:00 PM, Bill Mills wrote:=0A>>=0A>>What does the group think of using signed JSON o= bjects for authentication rather than OAuth?=0A>>>=0A>>>=0A>>>=0A>>>=C2=A0= =0A>>>-bill=0A>>>=0A>>>=0A>>>______________________________________________= _=0A>>>scim mailing list=0A>>>scim@ietf.org=0A>>>https://www.ietf.org/mailm= an/listinfo/scim=0A>>>=0A>>=0A>>=0A>>______________________________________= _________=0A>>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.org/= mailman/listinfo/scim=0A>>=0A>>=0A>>=0A>___________________________________= ____________=0A>>scim mailing list=0A>>scim@ietf.org=0A>>https://www.ietf.o= rg/mailman/listinfo/scim=0A>>=0A>=0A>______________________________________= _________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mai= lman/listinfo/scim=0A>=0A>=0A>=0A__________________________________________= _____=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/mailman= /listinfo/scim=0A>=0A=0A_______________________________________________=0As= cim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/sc= im --515012262-251799921-1399140224=:20640 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Yep I will be at IIW

On Saturday, May 3, 2014 12:46 A= M, Phil Hunt <phil.hunt@oracle.com> wrote:

Bill,

Are you going to IIW next week? Let's chat = then.

Phil

On May 2, 2014, at 22:13, Bill Mills <wmills_92105@yahoo.com> wrote:

Regular SCIM auth. I just have never liked the OAuth 2 = solution much. What else can we do?

<= div dir=3D"ltr"> On Friday, May 2, 2014 9:= 56 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Lets go back to basic= s. :-)

What's the scenario where by= you feel you need jws?

Phil
On May 2, 2014, at 21:39, Bill Mills <wmills_92105@yahoo.com> wro= te:

OAuth just isn't my favorite choice here, in the end it'= s just a proxy for some other shared secret. A JWT potentially cuts o= ut the OAuth middleman.

On Friday, May 2, 2014 6:18 PM, Phil Hunt &l= t;phil.hunt@oracle.c= om> wrote:

I think the primary us= e case for SCIM was point-to-point provisioning which is sufficiently secur= ed through the use of TLS. This=0A might be further solidified by the work being done in OAuth W= G on POP/MAC tokens to provide mutual-authentication as well as payload int= egrity and confidentiality.
=E2=80=94> this is a good item for the s= ecurity considerations.

I think =E2=80=9Csigning=E2=80=9D becomes relevant when SCIM payload data= is being handled by intermediaries (handled by multiple entities) where it= becomes important to prove that the data has not been altered in a multi-h= op-path in an end-to-end security fashion.

Maybe this would be a good extension?

What use case did you have in mind?

=0A
Phil

@independentid
<= div>www.independentid.com
phil.hunt@oracle.com

=0A
=0A
On May 2, 2014, at 5:00 PM, B= ill Mills <wm= ills_92105@yahoo.com> wrote:

What does the group think of usi= ng signed JSON objects for authentication rather than OAuth?

-bill

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listin= fo/scim

<= /div>

_____________________________________= __________
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim

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

<= /div>

_______________________________________________<= br clear=3D"none">scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listin= fo/scim

<= /div>

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

_________________________= ______________________
scim mailing list
scim@ietf.org
<= a shape=3D"rect" href=3D"https://www.ietf.org/mailman/listinfo/scim" target= =3D"_blank">https://www.ietf.org/mailman/listinfo/scim

Sure it's out of scope, but it needs solving in br= oader the context.

On Tuesday, May 6, 2014 10:34 AM, Erik Wahlstr=F6m <erik.w= ahlstrom@nexusgroup.com> wrote:

=0A

+1 on out of scope.
=0A
=0ASent from my iPad

=0A

=0AOn 6 maj 2014, at 10:20, "Phil Hunt" <phil.hunt@oracle.com> wrote:
=0A
=0A

=0A

= =0A
=0A
Well it is out of scope.
=0A

=0A
=0A
But I don't see why scim couldn't be the api for an au= thentication system that generates the assertion (including authen date etc= ).
=0A
=0APhil
=0A

=0AOn Apr 30, 2014, at 12:05, Bill Mills <wmills@yahoo-inc.com> wrote:<= br clear=3D"none">=0A
=0A
=0A
=0A
=0A
=0AWhat does the group think of using signed JSON ob= jects for authentication rather than OAuth?
=0A

=0A
=0A

=0A
-bill
=0A
=0A
=0A
=0A
= =0A--------------------------------
=0AWilliam J. Mills=0ATechnical Yahoo!
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
_______________________________________________<= /span>
=0Ascim mailing list
=0Ascim@ietf.org
=0Ahttps://www.ietf= .org/mailman/listinfo/scim
=0A
=0A=0A
=0A

=0A

=0A
<= span>_______________________________________________
=0Ascim mailing list
=0Ascim@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinf= o/scim
=0A
=0A

=0A

_________________________= ______________________
scim mailing list
scim@ietf.org
https://www.ietf.o= rg/mailman/listinfo/scim

--1397251415-1427010199-1399398401=:52837-- From nobody Tue May 6 12:05:45 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 C79361A030C for ; Tue, 6 May 2014 12:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 c98CqtFcQij3 for ; Tue, 6 May 2014 12:05:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 82FEF1A0317 for ; Tue, 6 May 2014 12:05:42 -0700 (PDT) Received: from BLUPR04MB385.namprd04.prod.outlook.com (10.141.26.12) by BLUPR04MB040.namprd04.prod.outlook.com (10.255.210.25) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 19:05:34 +0000 Received: from BLUPR04MB386.namprd04.prod.outlook.com (10.141.26.17) by BLUPR04MB385.namprd04.prod.outlook.com (10.141.26.12) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 19:05:33 +0000 Received: from BLUPR04MB386.namprd04.prod.outlook.com ([169.254.12.35]) by BLUPR04MB386.namprd04.prod.outlook.com ([169.254.12.35]) with mapi id 15.00.0934.000; Tue, 6 May 2014 19:05:32 +0000 From: Kelly Grizzle To: Bill Mills , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , Phil Hunt Thread-Topic: [scim] signed JSON objects instead of OAuth 2? Thread-Index: AQHPaUWqEIESfJQIGk+CajmDj0VUspszzB0AgAAELoCAAANvgIAAFNbA Date: Tue, 6 May 2014 19:05:31 +0000 Message-ID: References: <1398884727.41865.YahooMailNeo@web125601.mail.ne1.yahoo.com>, <23F518D4-A13E-4970-8A56-7073CB5BCE14@oracle.com> <8E66AAF3-37B5-4AC4-9A9D-8AC0DFC3D084@nexusgroup.com> <1399398401.52837.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: <1399398401.52837.YahooMailNeo@web142802.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 1EDA0A3E0071001EDA0B8B x-originating-ip: [97.79.140.10] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(428001)(377454003)(24454002)(189002)(199002)(80022001)(92566001)(79102001)(16236675002)(19609705001)(15975445006)(86362001)(76576001)(19625215002)(64706001)(50986999)(19580405001)(101416001)(20776003)(21056001)(77982001)(76482001)(54356999)(76176999)(46102001)(2656002)(81542001)(19300405004)(19580395003)(4396001)(74502001)(83322001)(74662001)(83072002)(31966008)(85852003)(81342001)(74316001)(87936001)(99396002)(99286001)(15202345003)(33646001)(66066001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR04MB385; H:BLUPR04MB386.namprd04.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_adfad65eeeab48bead05a54e37ca6363BLUPR04MB386namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ebhT8VyqmbfwSjfqvj_B00IAj-s Cc: Scim WG , Bill Mills Subject: Re: [scim] signed JSON objects instead of OAuth 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: Tue, 06 May 2014 19:05:45 -0000 --_000_adfad65eeeab48bead05a54e37ca6363BLUPR04MB386namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A service provider has the option to implement any type of authn that they = want (see section 2 of the API draft below). Is there something specific t= hat you are wanting to add, Bill? Is there a spec for a signed JSON object= that you have in mind? http://tools.ietf.org/html/draft-ietf-scim-api-04#section-2 The SCIM protocol does not define a scheme for authentication and authorization therefore implementers are free to choose mechanisms appropriate to their use cases. The choice of authentication mechanism will impact interoperability. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication /authorization schemes. In particular, OAuth2[RFC6750] is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. The service provider specifies its supported authn in the authenticationSch= emes attribute of /ServiceProviderConfig (http://tools.ietf.org/html/draft-= ietf-scim-core-schema-04#section-9). --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Bill Mills Sent: Tuesday, May 06, 2014 12:47 PM To: Erik Wahlstr=F6m; Phil Hunt Cc: Scim WG; Bill Mills Subject: Re: [scim] signed JSON objects instead of OAuth 2? Sure it's out of scope, but it needs solving in broader the context. On Tuesday, May 6, 2014 10:34 AM, Erik Wahlstr=F6m > wrote: +1 on out of scope. Sent from my iPad On 6 maj 2014, at 10:20, "Phil Hunt" > wrote: Well it is out of scope. But I don't see why scim couldn't be the api for an authentication system t= hat generates the assertion (including authen date etc). Phil On Apr 30, 2014, at 12:05, Bill Mills > wrote: What does the group think of using signed JSON objects for authentication r= ather than OAuth? -bill -------------------------------- William J. Mills Technical Yahoo! _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_adfad65eeeab48bead05a54e37ca6363BLUPR04MB386namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A service provider has th= e option to implement any type of authn that they want (see section 2 of th= e API draft below). Is there something specific that you are wanting to add, Bill? Is there a spec for a signed JSON object t= hat you have in mind?

<= /p>

<= /p>

The SCIM protoc= ol does not define a scheme for authentication and

authorization t= herefore implementers are free to choose mechanisms

appropriate to = their use cases. The choice of authentication

   mechanism will impact interoperability.  It is =
RECOMMENDED that

   clients be implemented in such a way that new authen=
tication schemes

   can be deployed.  Implementers SHOULD support e=
xisting authentication

   /authorization schemes.  In particular, OAuth2[=
RFC6750] is

   RECOMMENDED.  Appropriate security consideratio=
ns of the selected

   authentication and authorization schemes SHOULD be t=
aken.

<= /p>

The service provider spec= ifies its supported authn in the authenticationSchemes attribute of /Servic= eProviderConfig (http://tools.ietf.org/html/draft-ietf-scim-core-schem= a-04#section-9).

<= /p>

--Kelly=

<= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Bill Mills
Sent: Tuesday, May 06, 2014 12:47 PM
To: Erik Wahlstr=F6m; Phil Hunt
Cc: Scim WG; Bill Mills
Subject: Re: [scim] signed JSON objects instead of OAuth 2?

Sure it's out o= f scope, but it needs solving in broader the context.

On= Tuesday, May 6, 2014 10:34 AM, Erik Wahlstr=F6m <erik.wahlstrom@nexusgroup.com> wrote:

+1 on out o= f scope.

Sent from my iPad

On 6 maj 2014, at 10:20, "Phil Hunt" <phil.hunt@oracle.com> wrote:<= /o:p>

Well it is out = of scope.

But I don't see= why scim couldn't be the api for an authentication system that generates t= he assertion (including authen date etc).

Phil

On Apr 30, 2014, at 12:05, Bill Mills <wmills@yahoo-inc.com> wrote:

What does the group= think of using signed JSON objects for authentication rather than OAuth?

-----------------------------= ---
William J. Mills
Technical Yahoo!

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

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

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

--_000_adfad65eeeab48bead05a54e37ca6363BLUPR04MB386namprd04pro_-- From nobody Tue May 6 12:09: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 4A8171A00E8 for ; Tue, 6 May 2014 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 N5PxuXA6Ym1Y for ; Tue, 6 May 2014 12:09:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEDC1A030C for ; Tue, 6 May 2014 12:09:45 -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 s46J9eJ3003713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 19:09:40 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s46J9dLK015437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 19:09:40 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s46J9dDb015426; Tue, 6 May 2014 19:09:39 GMT Received: from [10.255.54.14] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 May 2014 12:09:39 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FFB0A6A6-44F2-41DF-A179-893BAAF9575F" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Tue, 6 May 2014 12:09:37 -0700 Message-Id: References: <1398884727.41865.YahooMailNeo@web125601.mail.ne1.yahoo.com>, <23F518D4-A13E-4970-8A56-7073CB5BCE14@oracle.com> <8E66AAF3-37B5-4AC4-9A9D-8AC0DFC3D084@nexusgroup.com> <1399398401.52837.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4Jm3PIre5q32jXqICcn-GiKx1No Cc: Scim WG , Bill Mills , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , Bill Mills Subject: Re: [scim] signed JSON objects instead of OAuth 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: Tue, 06 May 2014 19:09:47 -0000 --Apple-Mail=_FFB0A6A6-44F2-41DF-A179-893BAAF9575F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There are two different issues. 1. How a client authenticates to scim (section 2 below) 2. How a client uses scim for authenticating users. IMHO=85 for 1, a SCIM service is just like any other web service and is = authenticate by normal HTTP techniques. For 2, a client can be an authentication service that calls into scim to = validate claims and obtain role and other information used in an = authentication process. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 6, 2014, at 12:05 PM, Kelly Grizzle = wrote: > A service provider has the option to implement any type of authn that = they want (see section 2 of the API draft below). Is there something = specific that you are wanting to add, Bill? Is there a spec for a = signed JSON object that you have in mind? > =20 > http://tools.ietf.org/html/draft-ietf-scim-api-04#section-2 > =20 > The SCIM protocol does not define a scheme for authentication and > authorization therefore implementers are free to choose mechanisms > appropriate to their use cases. The choice of authentication > mechanism will impact interoperability. It is RECOMMENDED that > clients be implemented in such a way that new authentication = schemes > can be deployed. Implementers SHOULD support existing = authentication > /authorization schemes. In particular, OAuth2[RFC6750] is > RECOMMENDED. Appropriate security considerations of the selected > authentication and authorization schemes SHOULD be taken. > =20 > The service provider specifies its supported authn in the = authenticationSchemes attribute of /ServiceProviderConfig = (http://tools.ietf.org/html/draft-ietf-scim-core-schema-04#section-9). > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Bill Mills > Sent: Tuesday, May 06, 2014 12:47 PM > To: Erik Wahlstr=F6m; Phil Hunt > Cc: Scim WG; Bill Mills > Subject: Re: [scim] signed JSON objects instead of OAuth 2? > =20 > Sure it's out of scope, but it needs solving in broader the context. > On Tuesday, May 6, 2014 10:34 AM, Erik Wahlstr=F6m = wrote: > +1 on out of scope. >=20 > Sent from my iPad >=20 > On 6 maj 2014, at 10:20, "Phil Hunt" wrote: >=20 > Well it is out of scope.=20 > =20 > But I don't see why scim couldn't be the api for an authentication = system that generates the assertion (including authen date etc).=20 >=20 > Phil >=20 > On Apr 30, 2014, at 12:05, Bill Mills wrote: >=20 > What does the group think of using signed JSON objects for = authentication rather than OAuth? > =20 > =20 > -bill >=20 >=20 > -------------------------------- > William J. Mills > Technical Yahoo! > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 >=20 --Apple-Mail=_FFB0A6A6-44F2-41DF-A179-893BAAF9575F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 There = are two different issues.

1. How a client = authenticates to scim (section 2 below)

2. How a client = uses scim for authenticating users.

IMHO=85 for = 1, a SCIM service is just like any other web service and is authenticate = by normal HTTP techniques.

For 2, a client can = be an authentication service that calls into scim to validate claims and = obtain role and other information used in an authentication = process.

Phil

@independentid

On May 6, 2014, at 12:05 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

A service provider has the option to implement any = type of authn that they want (see section 2 of the API draft = below). Is there something specific that you are wanting to add, Bill? Is there a spec for a signed JSON = object that you have in mind?

http:= //tools.ietf.org/html/draft-ietf-scim-api-04#section-2

   The SCIM protocol does not define a scheme for = authentication and
   authorization therefore implementers are free to = choose mechanisms
   appropriate to their use cases. The choice of = authentication

   mechanism will impact interoperability. It is = RECOMMENDED that

   clients be implemented in such a way that new = authentication schemes

   can be deployed. Implementers SHOULD support = existing authentication

   /authorization schemes. In particular, = OAuth2[RFC6750] is

   RECOMMENDED. Appropriate security = considerations of the selected

   authentication and authorization schemes SHOULD be = taken.

The service provider specifies its supported authn = in the authenticationSchemes attribute of /ServiceProviderConfig (http://tools.ietf.org/html/draft-ietf-scim-core-schema-04#section-9= ).

--Kelly

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Bill Mills
Sent: Tuesday, May 06, 2014 12:47 PM
To: Erik Wahlstr=F6m; Phil Hunt
Cc: Scim WG; Bill Mills
Subject: Re: [scim] signed JSON objects instead of OAuth = 2?

Sure it's out of scope, = but it needs solving in broader the context.

On Tuesday, = May 6, 2014 10:34 AM, Erik Wahlstr=F6m <erik.wahlstrom@nexusgroup.co= m> wrote:

+1 on out of scope.

Sent from my iPad

On 6 maj 2014, at 10:20, "Phil Hunt" <phil.hunt@oracle.com> = wrote:

Well it is out of = scope.

But I don't see why scim = couldn't be the api for an authentication system that generates the = assertion (including authen date etc).

Phil

On Apr 30, 2014, at 12:05, Bill Mills <wmills@yahoo-inc.com> = wrote:

What does the = group think of using signed JSON objects for authentication rather than = OAuth?

-bill

--------------------------------
William J. Mills
Technical Yahoo!

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

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

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

= --Apple-Mail=_FFB0A6A6-44F2-41DF-A179-893BAAF9575F-- From nobody Fri May 9 10:15: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 BB00B1A0092 for ; Fri, 9 May 2014 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 8TtCAXR2vsxF for ; Fri, 9 May 2014 10:15:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8886D1A008A for ; Fri, 9 May 2014 10:15:13 -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 s49HF7vG002046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 May 2014 17:15:08 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 s49HF6aM029899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 17:15:06 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s49HF6tU017749; Fri, 9 May 2014 17:15:06 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 May 2014 10:15:05 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_573A2C4A-26FF-4CFF-9C47-23EA23B810A1" Date: Fri, 9 May 2014 10:15:06 -0700 Message-Id: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/sgr_IyuNLYoGVhF2l2x3sJ-KSr8 Cc: Melvin Laguren Subject: [scim] Errors vs Error 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, 09 May 2014 17:15:34 -0000 --Apple-Mail=_573A2C4A-26FF-4CFF-9C47-23EA23B810A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response = codes) has an example detail response supporting multiple error = messages. > HTTP/1.1 404 NOT FOUND >=20 > { > "schemas": ["urn:scim:schemas:core:2.0:Error"], > "Errors":[ > { > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found", > "code":"404" > } > ] > } We looked through the spec and could not find any cases where the = =93Errors=94 object is needed to support multiple errors. Even in the = case of BULK requests, each request object gets its own response. I also can=92t find a reason to return the =93schemas=94 attribute. Any = reasoning here?=20 Does the following work? HTTP/1.1 404 NOT FOUND { "Error":[ { "description":"Resource = /Users/2819c223-7f76-453a-919d-413861904646 not found", "code":"404" } ] } Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_573A2C4A-26FF-4CFF-9C47-23EA23B810A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 At IIW = this week, Erik, Morteza and I noticed that Section 3.9 (response codes) = has an example detail response supporting multiple error = messages.

HTTP/1.1 404 NOT FOUND

{
  "schemas": ["urn:scim:schemas:core:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 not =
found",
      "code":"404"
    }
  ]
}

We looked through the spec = and could not find any cases where the =93Errors=94 object is needed to = support multiple errors. Even in the case of BULK requests, each request = object gets its own response.

I also can=92t = find a reason to return the =93schemas=94 attribute. Any reasoning = here?

Does the following = work?

HTTP/1.1 404 NOT FOUND

{
  "Error":[
    {
      "description":"Resource =
/Users/2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}

Phil

@independentid

= --Apple-Mail=_573A2C4A-26FF-4CFF-9C47-23EA23B810A1-- From nobody Fri May 9 10:18: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 3ACFC1A0066 for ; Fri, 9 May 2014 10:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k-Qxue0BeRl for ; Fri, 9 May 2014 10:18:52 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 503D11A0012 for ; Fri, 9 May 2014 10:18:52 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so1679261wiw.3 for ; Fri, 09 May 2014 10:18:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5fr2f2uDE2IGNu9QhJhs1YxIirp1mT2krVbpqEU4Plk=; b=Z/QFQVPvLX74WLebMu0YD/sGZdzzdkXEjToSPNO9wNY00FZYvocLaMm/+mKWcLNC/J nCcqmgIu45dlfIZtjHd/1yxEpuUmhJlZbSHq3O/JFq78DWvbL4/nGRTRDrhhyXGpefIV +Tu/rSNAQF1hJC1shvdjyV1ywVNbvZK9BUvQCSWLMQp96ZXQ+o1FIDcqqzicKFAhwbFW GOAnY+IX9ZsPYOdykT5gntXCVjcwxVL4dvS3rM7LhIP9E8JJJcltSQVGjc7Mu5IxZ+CI VLAdRCwFdlt+Sfs8zyDp3NyaXr9SgsGWWbZi5wZW+mu8vCSVXqrhS3fihpha29bxlegA FkGw== X-Gm-Message-State: ALoCoQkBL6FoL5cEh33H+6BiSbjsDMzqUp1ii3UGMXO1ayW/pNngJdD+UoCrbpD/dQWgmCzmK2XL MIME-Version: 1.0 X-Received: by 10.180.98.232 with SMTP id el8mr4242609wib.27.1399655926801; Fri, 09 May 2014 10:18:46 -0700 (PDT) Received: by 10.216.151.132 with HTTP; Fri, 9 May 2014 10:18:46 -0700 (PDT) In-Reply-To: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> Date: Fri, 9 May 2014 13:18:46 -0400 Message-ID: From: Ian Glazer To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d0442885e534b6604f8faca67 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/yNRe0DsLRfT6EqX1JKz50A6tNSI Cc: Scim WG , Melvin Laguren Subject: Re: [scim] Errors vs Error 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, 09 May 2014 17:18:56 -0000 --f46d0442885e534b6604f8faca67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes On Fri, May 9, 2014 at 1:15 PM, Phil Hunt wrote: > At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response > codes) has an example detail response supporting multiple error messages. > > HTTP/1.1 404 NOT FOUND > > { > "schemas": ["urn:scim:schemas:core:2.0:Error"], > "Errors":[ > { > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not fo= und", > "code":"404" > } > ] > } > > > We looked through the spec and could not find any cases where the =E2=80= =9CErrors=E2=80=9D > object is needed to support multiple errors. Even in the case of BULK > requests, each request object gets its own response. > > I also can=E2=80=99t find a reason to return the =E2=80=9Cschemas=E2=80= =9D attribute. Any > reasoning here? > > Does the following work? > > HTTP/1.1 404 NOT FOUND > > { > "Error":[ > { > "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646= not found", > "code":"404" > } > ] > } > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --f46d0442885e534b6604f8faca67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes

On Fri, May 9, 2014 at 1:15 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:

At IIW t= his week, Erik, Morteza and I noticed that Section 3.9 (response codes) has= an example detail response supporting multiple error messages.
HTTP/1.1 404 NOT FOUND

{
  "schemas": ["urn:scim:schemas:core:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861=
904646 not found",
      "code":"404"
    }
  ]
}
We looked through the spec an= d could not find any cases where the =E2=80=9CErrors=E2=80=9D object is nee= ded to support multiple errors. Even in the case of BULK requests, each req= uest object gets its own response.

I also can=E2=80=99t find a reason to return the =E2=80= =9Cschemas=E2=80=9D attribute. =C2=A0Any reasoning here?=C2=A0
Does the following work?
HTTP/1.1 404 NOT FOUND

{
  "Error":[
    {
      "description":"Resource /Users/2819c223-7f76-453a-919d=
-413861904646 not found",
      "code":"404"
    }
  ]
}
Phil

@independentid
www.independentid.com
=
phil= .hunt@oracle.com
_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

Ian Glazer

Senior Director, Identity

= +1 202 255 3166

@iglazer

--f46d0442885e534b6604f8faca67-- From nobody Fri May 9 10:49: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 7A8DC1A0309 for ; Fri, 9 May 2014 10:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Q8_ncGftd5b8 for ; Fri, 9 May 2014 10:49:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8261A0307 for ; Fri, 9 May 2014 10:49:09 -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 s49Hn2Aa010657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 May 2014 17:49:03 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 s49Hn07P021962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 17:49:02 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s49Hn0tO007990; Fri, 9 May 2014 17:49:00 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 May 2014 10:49:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9F133BE3-88C8-4F80-A2EB-7C3680FEC675" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Fri, 9 May 2014 10:49:00 -0700 Message-Id: <39E38811-1A54-4CD4-B567-0A3F175DFCC6@oracle.com> References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> To: Melvin Laguren X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9ZKh0uEQQkRodVwwDE2-RmCnJ_4 Cc: Scim WG , Ian Glazer , Melvin Laguren Subject: Re: [scim] Errors vs Error 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, 09 May 2014 17:49:11 -0000 --Apple-Mail=_9F133BE3-88C8-4F80-A2EB-7C3680FEC675 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m thinking we should be consistent with the status structure = shown in Bulk. See page 36/37 of draft 04. IOW. We return the same block whether in an =E2=80=9Coperations=E2=80=9D = array in Bulk or in response to a regular SCIM operation (which has only = one operation). For example, for a bulk error response: HTTP/1.1 200 OK Content-Type: application/json { "schemas": ["urn:scim:schemas:core:2.0:BulkResponse"], "Operations": [ { "method": "POST", "bulkId": "qwerty", "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } }, ... { "location": = "https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b", "method": "DELETE", "status": { "code": "404", "description": "Specified resource; e.g., User, does not exist." } } ] } And a single operation fail response: HTTP/1.1 400 BAD Content-Type: application/json { "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } } Phil @independentid www.independentid.com phil.hunt@oracle.com On May 9, 2014, at 10:23 AM, Melvin Laguren = wrote: > I agree. I have not been able to find a use case where multiple = errors would be returned. >=20 > As for the schemas, would we need it to identify the error object if = we change from the current object to the following: >=20 > { >=20 > "problemType": "=E2=80=8Bhttp://example.com/errors/insufficient-access",= > "title": "You do not have the required permissions to create a new = user.", > "detail": "Creating a user requires RIGHT_CREATE_USER." >=20 > } >=20 > As proposed in ticket 46? >=20 >=20 >=20 > On Fri, May 9, 2014 at 10:18 AM, Ian Glazer = wrote: > Yes >=20 >=20 > On Fri, May 9, 2014 at 1:15 PM, Phil Hunt = wrote: > At IIW this week, Erik, Morteza and I noticed that Section 3.9 = (response codes) has an example detail response supporting multiple = error messages. >> HTTP/1.1 404 NOT FOUND >>=20 >> { >> "schemas": ["urn:scim:schemas:core:2.0:Error"], >> "Errors":[ >> { >> "description":"Resource 2819c223-7f76-453a-919d-413861904646 = not found", >> "code":"404" >> } >> ] >> } >=20 > We looked through the spec and could not find any cases where the = =E2=80=9CErrors=E2=80=9D object is needed to support multiple errors. = Even in the case of BULK requests, each request object gets its own = response. >=20 > I also can=E2=80=99t find a reason to return the =E2=80=9Cschemas=E2=80=9D= attribute. Any reasoning here?=20 >=20 > Does the following work? >=20 > HTTP/1.1 404 NOT FOUND >=20 > { > "Error":[ > { > "description":"Resource = /Users/2819c223-7f76-453a-919d-413861904646 not found", > "code":"404" > } > ] > } >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > --=20 > Melvin Laguren > Twitter: @mlaguren > Blog: www.sqaessentials.com > Meetups: http://www.meetup.com/test-armory & = http://www.meetup.com/The-Mobile-Testing-Gurus --Apple-Mail=_9F133BE3-88C8-4F80-A2EB-7C3680FEC675 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99= m thinking we should be consistent with the status structure shown in = Bulk. See page 36/37 of draft 04.

IOW. We return the same block whether in an =E2=80=9Coperation= s=E2=80=9D array in Bulk or in response to a regular SCIM operation = (which has only one operation).

For = example, for a bulk error response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "schemas": ["urn:scim:schemas:core:2.0:BulkResponse"],
  "Operations": [
    {
      "method": "POST",
      "bulkId": "qwerty",
      "status": {
        "code": "400",
        "description": "Request is unparseable, syntactically incorrect, =
or violates schema."
      }
    },
...
    {
      "location": "https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "method": "DELETE",
      "status": {
        "code": "404",
        "description": "Specified resource; e.g., User, does not exist."
      }
    }
  ]
}

And a single operation fail response:

HTTP/1.1 400 BAD
Content-Type: application/json

{
  "status": {
      "code": "400",
      "description": "Request is unparseable, syntactically incorrect, =
or violates schema."
  }
}

Phil

@independentid

On May 9, 2014, at 10:23 AM, Melvin Laguren <melvin@sqaessentials.com> = wrote:

I agree. I have not been able to = find a use case where multiple errors would be = returned.

As for the schemas, would we need it to = identify the error object if we change from the current object to the = following:

{
"problemType": "=E2=80=8Bhttp://example.com/errors/insufficient-access",
"title": "You do not have the required permissions to create a new = user.",
"detail": "Creating a user requires = RIGHT_CREATE_USER."
}
As proposed in ticket 46?
On Fri, May 9, = 2014 at 10:18 AM, Ian Glazer <iglazer@salesforce.com> wrote:
Yes
On Fri, May 9, 2014 at 1:15 = PM, Phil Hunt <phil.hunt@oracle.com> wrote:
At IIW this week, Erik, = Morteza and I noticed that Section 3.9 (response codes) has an example = detail response supporting multiple error messages.
HTTP/1.1 404 =
NOT FOUND

{
  "schemas": ["urn:scim:schemas:core:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 not =
found",
      "code":"404"
    }
  ]
}
We looked through the spec = and could not find any cases where the =E2=80=9CErrors=E2=80=9D object = is needed to support multiple errors. Even in the case of BULK requests, = each request object gets its own response.

I also can=E2=80=99t find a reason to return the = =E2=80=9Cschemas=E2=80=9D attribute. Any reasoning = here?

Does the following = work?
HTTP/1.1 404 =
NOT FOUND

{
  "Error":[
    {
      "description":"Resource =
/Users/2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}
Phil

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

=

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

@iglazer
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--
Melvin Laguren
Twitter: = @mlaguren
Blog: www.sqaessentials.com

Meetups: http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus

= --Apple-Mail=_9F133BE3-88C8-4F80-A2EB-7C3680FEC675-- From nobody Fri May 9 10:53:13 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 9AF961A007B for ; Fri, 9 May 2014 10:53:12 -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 HqgfAZiUoNlT for ; Fri, 9 May 2014 10:53:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AB1A0061 for ; Fri, 9 May 2014 10:53:08 -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.939.12; Fri, 9 May 2014 17:53:02 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0939.000; Fri, 9 May 2014 17:53:02 +0000 From: Kelly Grizzle To: Phil Hunt , Scim WG Thread-Topic: [scim] Errors vs Error Thread-Index: AQHPa6pNLl4RB/QoGE+ZXbfwOpKcKZs4hz7g Date: Fri, 9 May 2014 17:53:02 +0000 Message-ID: References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> In-Reply-To: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0A1F85980071620A1F86E5 x-originating-ip: [97.79.140.10] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(377454003)(189002)(99286001)(4396001)(86362001)(87936001)(77982001)(85852003)(101416001)(83072002)(46102001)(50986999)(19580395003)(19625215002)(76176999)(54356999)(19300405004)(74662001)(2656002)(92566001)(81342001)(16236675002)(74316001)(83322001)(31966008)(76576001)(74502001)(20776003)(80022001)(16601075003)(79102001)(66066001)(64706001)(15975445006)(19580405001)(19609705001)(76482001)(15202345003)(33646001)(21056001)(81542001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_fd79075cbc6b472d88050ccc02d09949BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/YKS2XphAfebWAJ_sijnj-q-rVzo Cc: Melvin Laguren Subject: Re: [scim] Errors vs Error 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, 09 May 2014 17:53:12 -0000 --_000_fd79075cbc6b472d88050ccc02d09949BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I looked into this a bit when researching for issue 46 (http://trac.tools.i= etf.org/wg/scim/trac/ticket/46). Regarding the fact that SCIM uses an "Errors" array, I was not able to find= any documented reason for this in the old google mailing list or on the IE= TF mailing list. Based on the above links, it looks like multiple errors ar= e most often used to return error information specific to data fields that = are POSTed (eg - missing required field 'username', field value is in the i= ncorrect format 'email'). I'm not sure how valuable this would be for SCIM = request. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, May 09, 2014 12:15 PM To: Scim WG Cc: Melvin Laguren Subject: [scim] Errors vs Error At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response co= des) has an example detail response supporting multiple error messages. HTTP/1.1 404 NOT FOUND { "schemas": ["urn:scim:schemas:core:2.0:Error"], "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not foun= d", "code":"404" } ] } We looked through the spec and could not find any cases where the "Errors" = object is needed to support multiple errors. Even in the case of BULK reque= sts, each request object gets its own response. I also can't find a reason to return the "schemas" attribute. Any reasonin= g here? Does the following work? HTTP/1.1 404 NOT FOUND { "Error":[ { "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646 n= ot found", "code":"404" } ] } Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_fd79075cbc6b472d88050ccc02d09949BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I looked into this a bit = when researching for issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46).

<= /p>

Regarding the fact that SCIM uses an "Errors" array, I = was not able to find any documented reason for this in the old google maili= ng list or on the IETF mailing list. Based on the above links, it looks like multiple errors are most often used to retu= rn error information specific to data fields that are POSTed (eg - missing = required field 'username', field value is in the incorrect format 'email').= I'm not sure how valuable this would be for SCIM request.

<= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error

At IIW this week, Erik, Morteza and I noticed that S= ection 3.9 (response codes) has an example detail response supporting multi= ple error messages.

HT=
TP/1.1 404 NOT FOUND

{<=
o:p>

&n=
bsp; "schemas": ["urn:scim:schemas:core:2.0:Error"],

&n=
bsp; "Errors":[

&n=
bsp;   {

&n=
bsp;     "description":"Resource 2819c22=
3-7f76-453a-919d-413861904646 not found",

&n=
bsp;     "code":"404"

&n=
bsp;   }

&n=
bsp; ]

}<=
o:p>

We looked through the spec and could not find any ca= ses where the “Errors” object is needed to support multiple err= ors. Even in the case of BULK requests, each request object gets its own re= sponse.

I also can’t find a reason to return the ̶= 0;schemas” attribute. Any reasoning here?

Does the following work?

HT=
TP/1.1 404 NOT FOUND

{<=
o:p>

&n=
bsp; "Error":[

&n=
bsp;   {

&n=
bsp;     "description":"Resource /Users/=
2819c223-7f76-453a-919d-413861904646 not found",
&n=
bsp;     "code":"404"
&n=
bsp;   }
&n=
bsp; ]
}<=
o:p>

 











Phil


 


@independentid<=
/span>


www.independentid.com


ph=
il.hunt@oracle.com

--_000_fd79075cbc6b472d88050ccc02d09949BN1PR04MB392namprd04pro_-- From nobody Fri May 9 10:53: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 A38AC1A0099 for ; Fri, 9 May 2014 10:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Ww-fSUZQPEBg for ; Fri, 9 May 2014 10:53:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EBF4E1A0061 for ; Fri, 9 May 2014 10:53:49 -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 s49HrhSW012144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 May 2014 17:53:43 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 s49HrgEX002832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 17:53:43 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 s49HrgWn002819; Fri, 9 May 2014 17:53:42 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 May 2014 10:53:41 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F010366F-7B9B-49C8-B983-4DA48994D457" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <39E38811-1A54-4CD4-B567-0A3F175DFCC6@oracle.com> Date: Fri, 9 May 2014 10:53:42 -0700 Message-Id: <227274A2-A48A-41B9-ABC1-0BA957FE4AE8@oracle.com> References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> <39E38811-1A54-4CD4-B567-0A3F175DFCC6@oracle.com> To: Melvin Laguren X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/WfMAYiOYk6umbtdBz89zaCwN9cc Cc: Scim WG , Ian Glazer , Melvin Laguren Subject: Re: [scim] Errors vs Error 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, 09 May 2014 17:53:52 -0000 --Apple-Mail=_F010366F-7B9B-49C8-B983-4DA48994D457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would also suggest we add a detailed error type. E.g. error_type. = The PATCH operation indicates sub-errors like:=20 * malformed_operation * mutability (attempt to modify an immutable or readOnly attribute) * invalid_path * no_target (e.g when a complex filter fails to find a value) * invalid_value (value was missing or incompatible with the attribute = type) Phil @independentid www.independentid.com phil.hunt@oracle.com On May 9, 2014, at 10:49 AM, Phil Hunt wrote: > I=E2=80=99m thinking we should be consistent with the status structure = shown in Bulk. See page 36/37 of draft 04. >=20 > IOW. We return the same block whether in an =E2=80=9Coperations=E2=80=9D= array in Bulk or in response to a regular SCIM operation (which has = only one operation). >=20 > For example, for a bulk error response: > HTTP/1.1 200 OK > Content-Type: application/json >=20 > { > "schemas": ["urn:scim:schemas:core:2.0:BulkResponse"], > "Operations": [ > { > "method": "POST", > "bulkId": "qwerty", > "status": { > "code": "400", > "description": "Request is unparseable, syntactically = incorrect, or violates schema." > } > }, > ... > { > "location": = "https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b", > "method": "DELETE", > "status": { > "code": "404", > "description": "Specified resource; e.g., User, does not = exist." > } > } > ] > } >=20 > And a single operation fail response: >=20 > HTTP/1.1 400 BAD > Content-Type: application/json >=20 > { > "status": { > "code": "400", > "description": "Request is unparseable, syntactically incorrect, = or violates schema." > } > } >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On May 9, 2014, at 10:23 AM, Melvin Laguren = wrote: >=20 >> I agree. I have not been able to find a use case where multiple = errors would be returned. >>=20 >> As for the schemas, would we need it to identify the error object if = we change from the current object to the following: >>=20 >> { >>=20 >> "problemType": "=E2=80=8Bhttp://example.com/errors/insufficient-access"= , >> "title": "You do not have the required permissions to create a new = user.", >> "detail": "Creating a user requires RIGHT_CREATE_USER." >>=20 >> } >>=20 >> As proposed in ticket 46? >>=20 >>=20 >>=20 >> On Fri, May 9, 2014 at 10:18 AM, Ian Glazer = wrote: >> Yes >>=20 >>=20 >> On Fri, May 9, 2014 at 1:15 PM, Phil Hunt = wrote: >> At IIW this week, Erik, Morteza and I noticed that Section 3.9 = (response codes) has an example detail response supporting multiple = error messages. >>> HTTP/1.1 404 NOT FOUND >>>=20 >>> { >>> "schemas": ["urn:scim:schemas:core:2.0:Error"], >>> "Errors":[ >>> { >>> "description":"Resource 2819c223-7f76-453a-919d-413861904646 = not found", >>> "code":"404" >>> } >>> ] >>> } >>=20 >> We looked through the spec and could not find any cases where the = =E2=80=9CErrors=E2=80=9D object is needed to support multiple errors. = Even in the case of BULK requests, each request object gets its own = response. >>=20 >> I also can=E2=80=99t find a reason to return the =E2=80=9Cschemas=E2=80= =9D attribute. Any reasoning here?=20 >>=20 >> Does the following work? >>=20 >> HTTP/1.1 404 NOT FOUND >>=20 >> { >> "Error":[ >> { >> "description":"Resource = /Users/2819c223-7f76-453a-919d-413861904646 not found", >> "code":"404" >> } >> ] >> } >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >>=20 >> --=20 >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >>=20 >> --=20 >> Melvin Laguren >> Twitter: @mlaguren >> Blog: www.sqaessentials.com >> Meetups: http://www.meetup.com/test-armory & = http://www.meetup.com/The-Mobile-Testing-Gurus >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_F010366F-7B9B-49C8-B983-4DA48994D457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would also suggest we add a detailed error type. E.g. error_type. = The PATCH operation indicates sub-errors like:

* malformed_operation

* mutability (attempt to modify an immutable = or readOnly attribute)

* invalid_path

* no_target (e.g when a complex filter fails to find a = value)

* invalid_value = (value was missing or incompatible with the attribute = type)

Phil

@independentid

On May 9, 2014, at 10:49 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

I=E2=80=99m thinking we = should be consistent with the status structure shown in Bulk. See = page 36/37 of draft 04.
IOW. We return the same block whether in an =E2=80=9Coperation= s=E2=80=9D array in Bulk or in response to a regular SCIM operation = (which has only one operation).

For = example, for a bulk error response:
HTTP/1.1 200 OK Content-Type: application/json { "schemas": ["urn:scim:schemas:core:2.0:BulkResponse"], "Operations": [ { "method": "POST", "bulkId": "qwerty", "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } }, ... { "location": "https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b", "method": "DELETE", "status": { "code": "404", "description": "Specified resource; e.g., User, does not exist." } } ] }

And a single operation fail response:

HTTP/1.1 400 BAD Content-Type: application/json { "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, = or violates schema." } }

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com
On May 9, 2014, at 10:23 AM, Melvin Laguren <melvin@sqaessentials.com> = wrote:
I agree. I have not been able to = find a use case where multiple errors would be = returned.

As for the schemas, would we need it to = identify the error object if we change from the current object to the = following:

{
"problemType": "=E2=80=8Bhttp://example.com/errors/insufficient-access",
"title": "You do not have the required permissions to create a new = user.",
"detail": "Creating a user requires = RIGHT_CREATE_USER."
}
As proposed in ticket 46?
On Fri, May 9, = 2014 at 10:18 AM, Ian Glazer <iglazer@salesforce.com> wrote:
Yes
On Fri, May 9, 2014 at 1:15 = PM, Phil Hunt <phil.hunt@oracle.com> wrote:
At IIW this week, Erik, = Morteza and I noticed that Section 3.9 (response codes) has an example = detail response supporting multiple error messages.
HTTP/1.1 404 =
NOT FOUND

{
  "schemas": ["urn:scim:schemas:core:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 not =
found",
      "code":"404"
    }
  ]
}
We looked through the spec = and could not find any cases where the =E2=80=9CErrors=E2=80=9D object = is needed to support multiple errors. Even in the case of BULK requests, = each request object gets its own response.

I also can=E2=80=99t find a reason to return the = =E2=80=9Cschemas=E2=80=9D attribute. Any reasoning = here?

Does the following = work?
HTTP/1.1 404 =
NOT FOUND

{
  "Error":[
    {
      "description":"Resource =
/Users/2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}
Phil

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

=

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

@iglazer
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--
Melvin Laguren
Twitter: = @mlaguren
Blog: www.sqaessentials.com

Meetups: http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus
=
_______________________________________= ________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_F010366F-7B9B-49C8-B983-4DA48994D457-- From nobody Fri May 9 11:22:11 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 9A7AF1A00B4 for ; Fri, 9 May 2014 11:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 uD12uXR8UgG8 for ; Fri, 9 May 2014 11:22:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C16861A00A3 for ; Fri, 9 May 2014 11:22:06 -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 s49IM1gt013753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 May 2014 18:22:01 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 s49IM0pN004098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 May 2014 18:22:01 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 s49IM0N4004043 for ; Fri, 9 May 2014 18:22:00 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 May 2014 11:22:00 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_80A87FA5-ABF9-411F-BA7E-27701EFD1C92" Message-Id: <255B4B91-214C-4303-9678-B2983940431E@oracle.com> Date: Fri, 9 May 2014 11:21:59 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pGjzAm0S96WIObOeFbwMCy3PUKE Subject: [scim] Ticket 47 - Attribute Indexing 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, 09 May 2014 18:22:08 -0000 --Apple-Mail=_80A87FA5-ABF9-411F-BA7E-27701EFD1C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am proposing we close the attribute indexing discovery enhancement as = WONTFIX. I originally proposed this, and I agree, we do not have a = clear/consistent way for servers to interpret this that is valuable to = clients. I.e. does it indicate whether an attribute is searchable or = does it simply mean faster searching. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_80A87FA5-ABF9-411F-BA7E-27701EFD1C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am = proposing we close the attribute indexing discovery enhancement as = WONTFIX.

I originally proposed this, and I agree, we = do not have a clear/consistent way for servers to interpret this that is = valuable to clients. I.e. does it indicate whether an attribute is = searchable or does it simply mean faster searching.

Phil

@independentid

= --Apple-Mail=_80A87FA5-ABF9-411F-BA7E-27701EFD1C92-- From nobody Fri May 9 11:36:33 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 040361A02E3 for ; Fri, 9 May 2014 11:36:32 -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, 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 3Uk4McfZTYBx for ; Fri, 9 May 2014 11:36:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 877731A0053 for ; Fri, 9 May 2014 11:36:29 -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.934.12; Fri, 9 May 2014 18:36:23 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0939.000; Fri, 9 May 2014 18:36:22 +0000 From: Kelly Grizzle To: Phil Hunt , Scim WG Thread-Topic: [scim] Ticket 47 - Attribute Indexing Thread-Index: AQHPa7OYlLj8QsNWLkS1FhehamgEqJs4k7VQ Date: Fri, 9 May 2014 18:36:22 +0000 Message-ID: References: <255B4B91-214C-4303-9678-B2983940431E@oracle.com> In-Reply-To: <255B4B91-214C-4303-9678-B2983940431E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0A47346D0071640A4735BA x-originating-ip: [97.79.140.10] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(99286001)(77982001)(16236675002)(76482001)(15975445006)(15202345003)(83072002)(74316001)(54356999)(19625215002)(50986999)(21056001)(33646001)(76176999)(101416001)(66066001)(80022001)(2656002)(31966008)(81342001)(64706001)(74502001)(74662001)(81542001)(46102001)(92566001)(16601075003)(76576001)(86362001)(19609705001)(87936001)(19580405001)(4396001)(19300405004)(83322001)(20776003)(19580395003)(79102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_d4fdafe6f808474d8974c34a55305f3aBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/spfiZZKdtWNC4CeZsn7SwVEccG4 Subject: Re: [scim] Ticket 47 - Attribute Indexing 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, 09 May 2014 18:36:32 -0000 --_000_d4fdafe6f808474d8974c34a55305f3aBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for WONTFIX From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, May 09, 2014 1:22 PM To: Scim WG Subject: [scim] Ticket 47 - Attribute Indexing I am proposing we close the attribute indexing discovery enhancement as WON= TFIX. I originally proposed this, and I agree, we do not have a clear/consistent = way for servers to interpret this that is valuable to clients. I.e. does i= t indicate whether an attribute is searchable or does it simply mean faster= searching. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_d4fdafe6f808474d8974c34a55305f3aBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for WONTFIX

<= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 1:22 PM
To: Scim WG
Subject: [scim] Ticket 47 - Attribute Indexing

I am proposing we close the attribute indexing disco= very enhancement as WONTFIX.

I originally proposed this, and I agree, we do not h= ave a clear/consistent way for servers to interpret this that is valuable t= o clients. I.e. does it indicate whether an attribute is searchable o= r does it simply mean faster searching.

Phil

@independentid<= /span>

--_000_d4fdafe6f808474d8974c34a55305f3aBN1PR04MB392namprd04pro_-- From nobody Mon May 12 09:57: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 AF9771A0763 for ; Mon, 12 May 2014 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRPwb93huDjO for ; Mon, 12 May 2014 09:57:49 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3091A0761 for ; Mon, 12 May 2014 09:57:49 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id ar20so3838523iec.29 for ; Mon, 12 May 2014 09:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7KjenNRVpLC5RGF9Ab2wJKwSnCftjC/JWQIWR9gEi6g=; b=t0lkpYr57FCtAyywILWnzkeDzhetHY403heN/blRyoDUreXDW/oDW0i2m4CKYYgAjR kqU3lmazwL8fTTEP0WG799yrk71t+95PEqDIvYoZv5awskCfV2jbpv9KnsQigZfdMlZA R2kWjNBW+KjU5kv1cQrf3pKW6uw1A6mGJC4WyeL0N9w8ac18KnoLVGHrcWm83YPUE1vk JvQM9PHbFhgFY8wofN/HTbAtSE/c6gdFpJOK68XZbVYPf/aOHOM9EOf9aTbcGTKqTKZY lZ6XV2Zzp54x6AhKUtfWAHD853XEFoF8caR9fhcWMf8vyzn9gKv6T6bG8ekfuxfUTjMz PJDQ== MIME-Version: 1.0 X-Received: by 10.50.225.1 with SMTP id rg1mr24458465igc.0.1399913863516; Mon, 12 May 2014 09:57:43 -0700 (PDT) Received: by 10.64.168.37 with HTTP; Mon, 12 May 2014 09:57:43 -0700 (PDT) In-Reply-To: References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> Date: Mon, 12 May 2014 11:57:43 -0500 Message-ID: From: Shelley To: Kelly Grizzle Content-Type: multipart/alternative; boundary=001a1132f15e8d37fe04f936d860 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZlsmUp33OwBW4kffEJRnZxxkTtg Cc: Scim WG , Melvin Laguren , Phil Hunt Subject: Re: [scim] Errors vs Error 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, 12 May 2014 16:57:52 -0000 --001a1132f15e8d37fe04f936d860 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Our SCIM 1.1 SP implementation currently returns multiple error descriptions representing validation errors when creating/modifying individual resources: { "Errors": [ { "description": "Invalid attribute 'username': may not be null or empty", "code": "400" }, { "description": "Invalid attribute 'locale': must be composed of a 2-letter language code (ISO 639-1), an underscore and a 2-letter country code (ISO 3166-1)", "code": "400" }, { "description": "Invalid attribute 'emails[0].value': not a well-formed email address", "code": "400" } ] } Having multiple errors in such a scenario is quite beneficial to consumers. I'd propose continuing to allow multiple errors to be returned to accommodate such scenarios. That said, relaying the http status code within the errors response body seems redundant and unnecessary. The "code" in its current form provides no value other than perhaps for BULK, which seems to use a slight variation on the Errors representation anyway. On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle wrote: > I looked into this a bit when researching for issue 46 ( > http://trac.tools.ietf.org/wg/scim/trac/ticket/46). > > > > Regarding the fact that SCIM uses an "Errors" array, I was not able to > find any documented reason for this in the old google mailing list or on > the IETF mailing list. Based on the above links, it looks like multiple > errors are most often used to return error information specific to data > fields that are POSTed (eg - missing required field 'username', field val= ue > is in the incorrect format 'email'). I'm not sure how valuable this would > be for SCIM request. > > > > *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Friday, May 09, 2014 12:15 PM > *To:* Scim WG > *Cc:* Melvin Laguren > *Subject:* [scim] Errors vs Error > > > > At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response > codes) has an example detail response supporting multiple error messages. > > HTTP/1.1 404 NOT FOUND > > > > { > > "schemas": ["urn:scim:schemas:core:2.0:Error"], > > "Errors":[ > > { > > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not fo= und", > > "code":"404" > > } > > ] > > } > > > > We looked through the spec and could not find any cases where the =E2=80= =9CErrors=E2=80=9D > object is needed to support multiple errors. Even in the case of BULK > requests, each request object gets its own response. > > > > I also can=E2=80=99t find a reason to return the =E2=80=9Cschemas=E2=80= =9D attribute. Any > reasoning here? > > > > Does the following work? > > > > HTTP/1.1 404 NOT FOUND > > > > { > > "Error":[ > > { > > "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646= not found", > > "code":"404" > > } > > ] > > } > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1132f15e8d37fe04f936d860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Our SCIM 1.1 SP implementation currently returns mult= iple error descriptions representing validation errors when creating/modify= ing individual resources:

{
=C2=A0=C2=A0=C2=A0 "Errors": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "description": "Invalid attribute 'username':= may not be null or empty",
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "code":= "400"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "description": "Invalid attribute 'locale': m= ust be composed of a 2-letter language code (ISO 639-1), an underscore and = a 2-letter country code (ISO 3166-1)",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "code": "400"
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "description": "Invalid attribute 'emails[0].valu= e': not a well-formed email address",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "code": "400"
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 ]
}<= /span>

Having multiple errors in such a scenario is quit= e beneficial to consumers. I'd propose continuing to allow multiple err= ors to be returned to accommodate such scenarios.

That said, relayin= g the http status code within the errors response body seems redundant and = unnecessary. The "code" in its current form provides no value oth= er than perhaps for BULK, which seems to use a slight variation on the Erro= rs representation anyway.

On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I looked into this a bit = when researching for issue 46 (http://trac.tools.ietf.org/wg/scim/trac= /ticket/46).

=C2=A0

Regarding the fact that SCIM uses an "Errors" array, I = was not able to find any documented reason for this in the old google maili= ng list or on the IETF mailing list. Based on the above links, it looks like multiple errors are most often used to retu= rn error information specific to data fields that are POSTed (eg - missing = required field 'username', field value is in the incorrect format &= #39;email'). I'm not sure how valuable this would be for SCIM request.=

=C2=A0

From: scim [ma= ilto:scim-bounce= s@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error
=C2=A0

At IIW this week, Erik, Morteza and I noticed that S= ection 3.9 (response codes) has an example detail response supporting multi= ple error messages.
HTTP/1.1 404 NOT FOUND<=
/span>
=C2=A0
{
=C2=A0 "schemas": ["ur=
n:scim:schemas:core:2.0:Error"],
=C2=A0 "Errors":[=
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=
description":"Resource 2819c223-7f76-453a-919d-413861904646 not f=
ound",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=
code":"404"
=C2=A0=C2=A0=C2=A0 }
=C2=A0 ]
}
=C2=A0
We looked through the spec and could not find any ca= ses where the =E2=80=9CErrors=E2=80=9D object is needed to support multiple= errors. Even in the case of BULK requests, each request object gets its ow= n response.

=C2=A0

I also can=E2=80=99t find a reason to return the =E2= =80=9Cschemas=E2=80=9D attribute. =C2=A0Any reasoning here?=C2=A0=

=C2=A0

Does the following work?

=C2=A0
HTTP/1.1 404 NOT FOUND<=
/span>
=C2=A0
{
=C2=A0 "Error":[<=
/u>
=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= description":"Resource /Users/2819c223-7f76-453a-919d-41386190464= 6 not found",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= code":"404"

=C2=A0=C2=A0=C2=A0 }

=C2=A0 ]

}

=C2=A0

Phil<= /p>

=C2=A0

@independentid

www.independentid.com

phil.hunt@oracle.com

=C2=A0

=C2=A0

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

--001a1132f15e8d37fe04f936d860-- From melvin.laguren@gmail.com Mon May 12 10:58:31 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 502451A0757 for ; Mon, 12 May 2014 10:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVzknOKxiMRk for ; Mon, 12 May 2014 10:58:28 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEC91A0741 for ; Mon, 12 May 2014 10:58:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so4940380wib.17 for ; Mon, 12 May 2014 10:58:21 -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=w/QNfGAc2fdFh69l8P1KDcEVZKZwsWtWZ2BeQhv9o1Y=; b=kNbP2bbh4ateGWdraxiAOlHXhq/58lgR4ZQ6ijK/2CR221JKMQaCt+ZXloXZm1ohhe C+u+Pn3eFuD/ZQg0GPxDft4NK1Kqsxg+kLn++kUVgH148lLGDBkzBVBByhiiklUHciWQ Qaz4I2VAGh7+HndML0W7M//UF78eJ8GpiNHIqWOYJkR5wkztT0KHzCB+tbdtFC9QcE9z gK7afnNc6jivSx7u/g7Sl2iyXcrOaFtw2fnKWV5dFKQJtRY1eUG51P8aKOOhKcTEBAwg W8qFhJP9FLlFM7zIOZlcmnOCqaaZyNTltoeqm/prRXZD6HsYnUuT6JiN92MXf8gH++3Y Cx2Q== MIME-Version: 1.0 X-Received: by 10.194.59.43 with SMTP id w11mr2951912wjq.65.1399917501600; Mon, 12 May 2014 10:58:21 -0700 (PDT) Sender: melvin.laguren@gmail.com Received: by 10.195.11.166 with HTTP; Mon, 12 May 2014 10:58:21 -0700 (PDT) In-Reply-To: References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com> Date: Mon, 12 May 2014 10:58:21 -0700 X-Google-Sender-Auth: A2YF7UmO6WTj11WnhxZRr1t2xNM Message-ID: From: Melvin Laguren To: Shelley Content-Type: multipart/alternative; boundary=047d7bacb5b865d9a104f937b1b3 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/8ju0s0ZQG-L8IxRgUyulzuYWbT0 Cc: Scim WG , Phil Hunt , Kelly Grizzle Subject: Re: [scim] Errors vs Error 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, 12 May 2014 17:59:21 -0000 --047d7bacb5b865d9a104f937b1b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's a good example for the need for multiple errors. Most of the companies I work with at the the implementation primarily fail for one reason. Additionally, I think code should be optional and reference more to internal codes that provide additional information. Twitter and Facebook use code in this way. --=20 Melvin Laguren Twitter: @mlaguren Blog: www.sqaessentials.com Meetups: http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus On Mon, May 12, 2014 at 9:57 AM, Shelley wrote: > Our SCIM 1.1 SP implementation currently returns multiple error > descriptions representing validation errors when creating/modifying > individual resources: > > { > "Errors": [ > { > "description": "Invalid attribute 'username': may not be null > or empty", > "code": "400" > }, > { > "description": "Invalid attribute 'locale': must be composed > of a 2-letter language code (ISO 639-1), an underscore and a 2-letter > country code (ISO 3166-1)", > "code": "400" > }, > { > "description": "Invalid attribute 'emails[0].value': not a > well-formed email address", > "code": "400" > } > ] > } > > Having multiple errors in such a scenario is quite beneficial to > consumers. I'd propose continuing to allow multiple errors to be returned > to accommodate such scenarios. > > That said, relaying the http status code within the errors response body > seems redundant and unnecessary. The "code" in its current form provides = no > value other than perhaps for BULK, which seems to use a slight variation = on > the Errors representation anyway. > > > > On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > >> I looked into this a bit when researching for issue 46 ( >> http://trac.tools.ietf.org/wg/scim/trac/ticket/46). >> >> >> >> Regarding the fact that SCIM uses an "Errors" array, I was not able to >> find any documented reason for this in the old google mailing list or on >> the IETF mailing list. Based on the above links, it looks like multiple >> errors are most often used to return error information specific to data >> fields that are POSTed (eg - missing required field 'username', field va= lue >> is in the incorrect format 'email'). I'm not sure how valuable this woul= d >> be for SCIM request. >> >> >> >> *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Friday, May 09, 2014 12:15 PM >> *To:* Scim WG >> *Cc:* Melvin Laguren >> *Subject:* [scim] Errors vs Error >> >> >> >> At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response >> codes) has an example detail response supporting multiple error messages= . >> >> HTTP/1.1 404 NOT FOUND >> >> >> >> { >> >> "schemas": ["urn:scim:schemas:core:2.0:Error"], >> >> "Errors":[ >> >> { >> >> "description":"Resource 2819c223-7f76-453a-919d-413861904646 not f= ound", >> >> "code":"404" >> >> } >> >> ] >> >> } >> >> >> >> We looked through the spec and could not find any cases where the >> =E2=80=9CErrors=E2=80=9D object is needed to support multiple errors. Ev= en in the case of >> BULK requests, each request object gets its own response. >> >> >> >> I also can=E2=80=99t find a reason to return the =E2=80=9Cschemas=E2=80= =9D attribute. Any >> reasoning here? >> >> >> >> Does the following work? >> >> >> >> HTTP/1.1 404 NOT FOUND >> >> >> >> { >> >> "Error":[ >> >> { >> >> "description":"Resource /Users/2819c223-7f76-453a-919d-41386190464= 6 not found", >> >> "code":"404" >> >> } >> >> ] >> >> } >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --047d7bacb5b865d9a104f937b1b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's a good example for the need for multiple errors= . =C2=A0Most of the companies I work with at the the implementation primari= ly fail for one reason.

Additionally, I think code shoul= d be optional and reference more to internal codes that provide additional = information. =C2=A0Twitter and Facebook use code in this way.

--=C2=A0

Melvin Laguren<= div>

Twitter: =C2=A0@mlaguren

Blog: =C2=A0www.sqaessentials.com

Meetups: =C2=A0http://www.meetup.com/test= -armory=C2=A0&=C2=A0http://www.meetup.com/The-Mobile-Testing-Guru= s

On Mon, May 12, 2014 at 9:5= 7 AM, Shelley <randomshelley@gmail.com> wrote:

Our SCIM 1.1 SP implementation currently returns mult= iple error descriptions representing validation errors when creating/modify= ing individual resources:

{
=C2=A0=C2=A0=C2=A0 "Errors": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "description": "Invalid attribute 'usern= ame': may not be null or empty",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "code": "400"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "description": "Invalid attribute 'local= e': must be composed of a 2-letter language code (ISO 639-1), an unders= core and a 2-letter country code (ISO 3166-1)",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "code": "400"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "description": "Invalid attribut= e 'emails[0].value': not a well-formed email address",<= /span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "code": "400"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<= br> =C2=A0=C2=A0=C2=A0 ]
}

On Fri, May 9, 2014 at 12:53 PM= , Kelly Grizzle <kelly.grizzle@sailpoint.com> wrot= e:

I looked into this a bit when researching fo= r issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46).=

=C2=A0

Regarding the fact that SCIM uses an "Errors" arr= ay, I was not able to find any documented reason for this in the old google= mailing list or on the IETF mailing list. Based on the above links, it looks like multiple errors are most often used to retu= rn error information specific to data fields that are POSTed (eg - missing = required field 'username', field value is in the incorrect format &= #39;email'). I'm not sure how valuable this would be for SCIM request.

=C2=A0

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error
=C2=A0

At IIW this week, Erik, Morteza and I noticed that S= ection 3.9 (response codes) has an example detail response supporting multi= ple error messages.
HTTP/1.1 404 NOT FOUND
=C2=A0
{
=C2=A0 "schemas": ["urn:=
scim:schemas:core:2.0:Error"],
=C2=A0 "Errors":[
=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "de= scription":"Resource 2819c223-7f76-453a-919d-413861904646 not fou= nd",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "co= de":"404"

=C2=A0=C2=A0=C2=A0 }

=C2=A0 ]

}
=C2=A0
We looked through the spec and could not find any ca= ses where the =E2=80=9CErrors=E2=80=9D object is needed to support multiple= errors. Even in the case of BULK requests, each request object gets its ow= n response.

=C2=A0

I also can=E2=80=99t find a reason to return the =E2= =80=9Cschemas=E2=80=9D attribute. =C2=A0Any reasoning here?=C2=A0=

=C2=A0

Does the following work?

=C2=A0

HTTP/1.1 404 NOT FOUND

=C2=A0

{

=C2=A0 "Error":[

=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "de= scription":"Resource /Users/2819c223-7f76-453a-919d-413861904646 = not found",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "co= de":"404"

=C2=A0=C2=A0=C2=A0 }

=C2=A0 ]

}

=C2=A0

Phil

=C2=A0

@independentid

www.independentid.com

phil.hun= t@oracle.com

=C2=A0

=C2=A0

=C2=A0
___________________________________________= ____
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

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

--047d7bacb5b865d9a104f937b1b3-- From nobody Mon May 12 11:04: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 3EA5D1A0766 for ; Mon, 12 May 2014 11:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.85 X-Spam-Level: X-Spam-Status: No, score=-6.85 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 MLHg8AF65XSm for ; Mon, 12 May 2014 11:04:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 707851A0745 for ; Mon, 12 May 2014 11:04:10 -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 s4CI41RC016560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 May 2014 18:04:02 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4CI41Vs028027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2014 18:04:01 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4CI40IX003287; Mon, 12 May 2014 18:04:00 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 May 2014 11:04:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_DD07C98D-536A-4B1D-AE08-562441EBE9F6" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Mon, 12 May 2014 11:04:01 -0700 Message-Id: References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com>

To: Melvin Laguren X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/-TNzcGHSCQT5k98RW5qOsvcKb6s Cc: Scim WG , Shelley , Kelly Grizzle Subject: Re: [scim] Errors vs Error 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, 12 May 2014 18:04:13 -0000 --Apple-Mail=_DD07C98D-536A-4B1D-AE08-562441EBE9F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think there needs to be a code word (IANA registered?) like = =93invalid_syntax=94. Descriptive text can be provided and that would = be optional. In the detailed error JSON, the HTTP Response code appears redundant. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 12, 2014, at 10:58 AM, Melvin Laguren = wrote: > That's a good example for the need for multiple errors. Most of the = companies I work with at the the implementation primarily fail for one = reason. >=20 > Additionally, I think code should be optional and reference more to = internal codes that provide additional information. Twitter and = Facebook use code in this way. >=20 > --=20 > Melvin Laguren > Twitter: @mlaguren > Blog: www.sqaessentials.com > Meetups: http://www.meetup.com/test-armory & = http://www.meetup.com/The-Mobile-Testing-Gurus >=20 > On Mon, May 12, 2014 at 9:57 AM, Shelley = wrote: > Our SCIM 1.1 SP implementation currently returns multiple error = descriptions representing validation errors when creating/modifying = individual resources: >=20 > { > "Errors": [ > { > "description": "Invalid attribute 'username': may not be = null or empty", > "code": "400" > }, > { > "description": "Invalid attribute 'locale': must be = composed of a 2-letter language code (ISO 639-1), an underscore and a = 2-letter country code (ISO 3166-1)", > "code": "400" > }, > { > "description": "Invalid attribute 'emails[0].value': not a = well-formed email address", > "code": "400" > } > ] > } >=20 > Having multiple errors in such a scenario is quite beneficial to = consumers. I'd propose continuing to allow multiple errors to be = returned to accommodate such scenarios. >=20 > That said, relaying the http status code within the errors response = body seems redundant and unnecessary. The "code" in its current form = provides no value other than perhaps for BULK, which seems to use a = slight variation on the Errors representation anyway. >=20 >=20 >=20 > On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle = wrote: > I looked into this a bit when researching for issue 46 = (http://trac.tools.ietf.org/wg/scim/trac/ticket/46). >=20 > =20 >=20 > Regarding the fact that SCIM uses an "Errors" array, I was not able to = find any documented reason for this in the old google mailing list or on = the IETF mailing list. Based on the above links, it looks like multiple = errors are most often used to return error information specific to data = fields that are POSTed (eg - missing required field 'username', field = value is in the incorrect format 'email'). I'm not sure how valuable = this would be for SCIM request. >=20 > =20 >=20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, May 09, 2014 12:15 PM > To: Scim WG > Cc: Melvin Laguren > Subject: [scim] Errors vs Error >=20 > =20 >=20 > At IIW this week, Erik, Morteza and I noticed that Section 3.9 = (response codes) has an example detail response supporting multiple = error messages. >=20 > HTTP/1.1 404 NOT FOUND > =20 > { > "schemas": ["urn:scim:schemas:core:2.0:Error"], > "Errors":[ > { > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found", > "code":"404" > } > ] > } > =20 >=20 > We looked through the spec and could not find any cases where the = =93Errors=94 object is needed to support multiple errors. Even in the = case of BULK requests, each request object gets its own response. >=20 > =20 >=20 > I also can=92t find a reason to return the =93schemas=94 attribute. = Any reasoning here?=20 >=20 > =20 >=20 > Does the following work? >=20 > =20 >=20 > HTTP/1.1 404 NOT FOUND > =20 > { > "Error":[ > { > "description":"Resource = /Users/2819c223-7f76-453a-919d-413861904646 not found", > "code":"404" > } > ] > } > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail=_DD07C98D-536A-4B1D-AE08-562441EBE9F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think there needs to be a code word (IANA registered?) like = =93invalid_syntax=94. Descriptive text can be provided and that = would be optional.

In the detailed error JSON, the = HTTP Response code appears redundant.

Phil

@independentid

On May 12, 2014, at 10:58 AM, Melvin Laguren <melvin@sqaessentials.com> = wrote:

That's a good example for the need for = multiple errors. Most of the companies I work with at the the = implementation primarily fail for one = reason.

Additionally, I think code should be optional = and reference more to internal codes that provide additional = information. Twitter and Facebook use code in this way.

--
Melvin = Laguren
Twitter: = @mlaguren
Blog: www.sqaessentials.com

Meetups: http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus

On Mon, May 12, 2014 at = 9:57 AM, Shelley <randomshelley@gmail.com> = wrote:

Our SCIM 1.1 SP implementation currently returns = multiple error descriptions representing validation errors when = creating/modifying individual resources:

{
    "Errors": [
        = {
         &nbs= p; "description": "Invalid attribute 'username': may not be null = or empty",
         &nbs= p; "code": "400"
        = },
        = {
         &nbs= p; "description": "Invalid attribute 'locale': must be composed of = a 2-letter language code (ISO 639-1), an underscore and a 2-letter = country code (ISO 3166-1)",
         &nbs= p; "code": "400"
        = },
        = {
         &nbs= p; "description": "Invalid attribute 'emails[0].value': not a = well-formed email address",
         &nbs= p; "code": "400"
        = }
    ]
}

Having multiple errors in such a scenario is quite beneficial = to consumers. I'd propose continuing to allow multiple errors to be = returned to accommodate such scenarios.

That said, relaying the = http status code within the errors response body seems redundant and = unnecessary. The "code" in its current form provides no value other than = perhaps for BULK, which seems to use a slight variation on the Errors = representation anyway.

On Fri, May 9, 2014 at = 12:53 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I looked into this a bit when researching for issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46).<= u>

Regarding the fact = that SCIM uses an "Errors" array, I was not able to find any documented = reason for this in the old google mailing list or on the IETF mailing = list. Based on the above links, it looks like multiple errors are most often used to = return error information specific to data fields that are POSTed (eg - = missing required field 'username', field value is in the incorrect = format 'email'). I'm not sure how valuable this would be for SCIM request.

From: scim = [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error

At IIW this week, Erik, Morteza and I noticed that = Section 3.9 (response codes) has an example detail response supporting = multiple error messages.

HTTP/1.1 404 NOT = FOUND

{

"schemas": = ["urn:scim:schemas:core:2.0:Error"],

= "Errors":[

    = {

      = "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found",

      = "code":"404"

    = }

]

}

We looked through the spec and could not = find any cases where the =93Errors=94 object is needed to support = multiple errors. Even in the case of BULK requests, each request object = gets its own response.

I also can=92t find a reason to return the = =93schemas=94 attribute. Any reasoning = here?

Does the following work?

HTTP/1.1 404 NOT = FOUND

{

= "Error":[

    = {

      = "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646 not = found",

      = "code":"404"

    = }

]

}

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

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

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

= --Apple-Mail=_DD07C98D-536A-4B1D-AE08-562441EBE9F6-- From nobody Mon May 12 11:23: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 7855A1A0783 for ; Mon, 12 May 2014 11:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, GB_I_LETTER=-2, 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 aSNfLGIc7h4c for ; Mon, 12 May 2014 11:23:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E26D1A0774 for ; Mon, 12 May 2014 11:23:24 -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.939.12; Mon, 12 May 2014 18:23:15 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0939.000; Mon, 12 May 2014 18:23:15 +0000 From: Kelly Grizzle To: Phil Hunt , Melvin Laguren Thread-Topic: [scim] Errors vs Error Thread-Index: AQHPa6pNLl4RB/QoGE+ZXbfwOpKcKZs4hz7ggASoAoCAABDxgIAAAZWAgAAE3zA= Date: Mon, 12 May 2014 18:23:15 +0000 Message-ID: References: <4407AEC9-F4D7-4B2F-9169-4F205B1662DC@oracle.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 19AE524A0071CE19AE5397 x-originating-ip: [97.79.140.10] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(377454003)(189002)(199002)(19609705001)(54356999)(81542001)(76482001)(87936001)(101416001)(77982001)(19300405004)(76176999)(50986999)(76576001)(86362001)(21056001)(15975445006)(81342001)(66066001)(4396001)(15202345003)(92566001)(20776003)(2656002)(64706001)(99286001)(16236675002)(33646001)(19625215002)(99396002)(83322001)(19580405001)(79102001)(31966008)(19580395003)(74316001)(80022001)(16601075003)(85852003)(83072002)(46102001)(74662001)(74502001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_c1cee3978467491294fdb753938588daBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qmxllT6diF2HP30qJCAQr3h5Ttk Cc: Scim WG , Shelley Subject: Re: [scim] Errors vs Error 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, 12 May 2014 18:23:36 -0000 --_000_c1cee3978467491294fdb753938588daBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that the code was initially included in the error response for ca= ses where the client may not easily be able to read the status code (simila= r to the way that location and version are included in the meta attribute i= n addition to the response headers). I don't know how many clients are oth= er there that would have difficulty with this, but that was the original th= ought process. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, May 12, 2014 1:04 PM To: Melvin Laguren Cc: Shelley; Kelly Grizzle; Scim WG Subject: Re: [scim] Errors vs Error I think there needs to be a code word (IANA registered?) like "invalid_synt= ax". Descriptive text can be provided and that would be optional. In the detailed error JSON, the HTTP Response code appears redundant. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 12, 2014, at 10:58 AM, Melvin Laguren > wrote: That's a good example for the need for multiple errors. Most of the compan= ies I work with at the the implementation primarily fail for one reason. Additionally, I think code should be optional and reference more to interna= l codes that provide additional information. Twitter and Facebook use code= in this way. -- Melvin Laguren Twitter: @mlaguren Blog: www.sqaessentials.com Meetups: http://www.meetup.com/test-armory & http://www.meetup.com/The-Mob= ile-Testing-Gurus On Mon, May 12, 2014 at 9:57 AM, Shelley > wrote: Our SCIM 1.1 SP implementation currently returns multiple error description= s representing validation errors when creating/modifying individual resourc= es: { "Errors": [ { "description": "Invalid attribute 'username': may not be null o= r empty", "code": "400" }, { "description": "Invalid attribute 'locale': must be composed of= a 2-letter language code (ISO 639-1), an underscore and a 2-letter country= code (ISO 3166-1)", "code": "400" }, { "description": "Invalid attribute 'emails[0].value': not a well= -formed email address", "code": "400" } ] } Having multiple errors in such a scenario is quite beneficial to consumers.= I'd propose continuing to allow multiple errors to be returned to accommod= ate such scenarios. That said, relaying the http status code within the errors response body se= ems redundant and unnecessary. The "code" in its current form provides no v= alue other than perhaps for BULK, which seems to use a slight variation on = the Errors representation anyway. On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle > wrote: I looked into this a bit when researching for issue 46 (http://trac.tools.i= etf.org/wg/scim/trac/ticket/46). Regarding the fact that SCIM uses an "Errors" array, I was not able to find= any documented reason for this in the old google mailing list or on the IE= TF mailing list. Based on the above links, it looks like multiple errors ar= e most often used to return error information specific to data fields that = are POSTed (eg - missing required field 'username', field value is in the i= ncorrect format 'email'). I'm not sure how valuable this would be for SCIM = request. From: scim [mailto:scim-bounces@ietf.org] On = Behalf Of Phil Hunt Sent: Friday, May 09, 2014 12:15 PM To: Scim WG Cc: Melvin Laguren Subject: [scim] Errors vs Error At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response co= des) has an example detail response supporting multiple error messages. HTTP/1.1 404 NOT FOUND { "schemas": ["urn:scim:schemas:core:2.0:Error"], "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not foun= d", "code":"404" } ] } We looked through the spec and could not find any cases where the "Errors" = object is needed to support multiple errors. Even in the case of BULK reque= sts, each request object gets its own response. I also can't find a reason to return the "schemas" attribute. Any reasonin= g here? Does the following work? HTTP/1.1 404 NOT FOUND { "Error":[ { "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646 n= ot found", "code":"404" } ] } Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_c1cee3978467491294fdb753938588daBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that the code w= as initially included in the error response for cases where the client may = not easily be able to read the status code (similar to the way that location and version are included in the meta attribute in additi= on to the response headers). I don’t know how many clients are = other there that would have difficulty with this, but that was the original= thought process.

<= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Monday, May 12, 2014 1:04 PM
To: Melvin Laguren
Cc: Shelley; Kelly Grizzle; Scim WG
Subject: Re: [scim] Errors vs Error

I think there needs to be a code word (IANA register= ed?) like “invalid_syntax”. Descriptive text can be provi= ded and that would be optional.

In the detailed error JSON, the HTTP Response code a= ppears redundant.

Phil

@independentid<= /span>

Meetups: http://www.meet= up.com/test-armory & http://www.meetup.com/The-Mobile-T= esting-Gurus

On May 12, 2014, at 10:58 AM, Melvin Laguren <melvin@sqaessentials.com> w= rote:

That's a good example for the need for multiple erro= rs. Most of the companies I work with at the the implementation prima= rily fail for one reason.

Additionally, I think code should be optional and re= ference more to internal codes that provide additional information. T= witter and Facebook use code in this way.

Melvin Laguren

Twitter: @mlag= uren

Blog: www.sqaessentials.com<= /a>

On Mon, May 12, 2014 at 9:57 AM, Shelley <randomshelley@gmail.c= om> wrote:

Our SCIM 1.1 SP imple= mentation currently returns multiple error descriptions representing valida= tion errors when creating/modifying individual resources:

{
&nb= sp; "Errors": [
&nb= sp;      {
&nb= sp;          "description= ": "Invalid attribute 'username': may not be null or empty",=
&nb= sp;          "code":= "400"
&nb= sp;      },
&nb= sp;      {
&nb= sp;          "description= ": "Invalid attribute 'locale': must be composed of a 2-letter la= nguage code (ISO 639-1), an underscore and a 2-letter country code (ISO 316= 6-1)",
&nb= sp;          "code":= "400"
&nb= sp;      },
&nb= sp;      {
&nb= sp;          "description= ": "Invalid attribute 'emails[0].value': not a well-formed email = address",
&nb= sp;          "code":= "400"
&nb= sp;      }
&nb= sp; ]
}<= o:p>

Having multiple error= s in such a scenario is quite beneficial to consumers. I'd propose continui= ng to allow multiple errors to be returned to accommodate such scenarios.
That said, relaying the http status code within the errors response body se= ems redundant and unnecessary. The "code" in its current form pro= vides no value other than perhaps for BULK, which seems to use a slight var= iation on the Errors representation anyway.

On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle <<= a href=3D"mailto:kelly.grizzle@sailpoint.com" target=3D"_blank">kelly.grizz= le@sailpoint.com> wrote:

I looked into this a bit when researchi= ng for issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46= ).

Regarding the fa= ct that SCIM uses an "Errors" array, I was not able to find any d= ocumented reason for this in the old google mailing list or on the IETF mailing list. Based on the above links, it looks like = multiple errors are most often used to return error information specific to= data fields that are POSTed (eg - missing required field 'username', field= value is in the incorrect format 'email'). I'm not sure how valuable this would be for SCIM request.=

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error
At IIW this week, Erik, Morteza and I noticed that Section 3.9 (re= sponse codes) has an example detail response supporting multiple error mess= ages.

HTTP/1.1 404 NOT FOUND

{

"schemas": ["ur= n:scim:schemas:core:2.0:Error"],

"Errors":[

    {

      "= description":"Resource 2819c223-7f76-453a-919d-413861904646 not f= ound",

      "= code":"404"

    }

]

}

We looked through the spec and could not find any cases where the = “Errors” object is needed to support multiple errors. Even in t= he case of BULK requests, each request object gets its own response.

I also can’t find a reason to return the “schemas̶= 1; attribute. Any reasoning here?

Does the following work?
HTTP/1.1 404 NOT FOUND

{

"Error":[

    {

      "= description":"Resource /Users/2819c223-7f76-453a-919d-41386190464= 6 not found",

      "= code":"404"

    }

]

}

Phil

@independentid

www.independentid.com

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

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

--_000_c1cee3978467491294fdb753938588daBN1PR04MB392namprd04pro_-- From nobody Mon May 12 20:54: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 B7BFA1A0829; Mon, 12 May 2014 20:54:11 -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 NmRHhWXwrKrT; Mon, 12 May 2014 20:54:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3CE1A0825; Mon, 12 May 2014 20:54:09 -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.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513035409.14138.73296.idtracker@ietfa.amsl.com> Date: Mon, 12 May 2014 20:54:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/MdQ95kFSFVMRqE8xSMQQaojbAv4 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-05.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, 13 May 2014 03:54:11 -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 Chuck Mortimore Filename : draft-ietf-scim-api-05.txt Pages : 65 Date : 2014-05-12 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-05 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 May 12 20:56:29 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 B16A61A0834; Mon, 12 May 2014 20:56:26 -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 InZTeI6IVusX; Mon, 12 May 2014 20:56:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8941A0829; Mon, 12 May 2014 20:56:24 -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.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513035624.22675.60330.idtracker@ietfa.amsl.com> Date: Mon, 12 May 2014 20:56:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6hEERXGKCGPQ1I0N5dqbvy4L1m4 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-05.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, 13 May 2014 03:56:27 -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-05.txt Pages : 60 Date : 2014-05-12 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. Additional binding documents provide a standard REST API, SAML binding, and use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-05 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 May 13 20:59: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 7FC0C1A0218 for ; Tue, 13 May 2014 20:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.151 X-Spam-Level: X-Spam-Status: No, score=-17.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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_eDr3QcU-AF for ; Tue, 13 May 2014 20:58:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id ADEC01A0145 for ; Tue, 13 May 2014 20:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16133; q=dns/txt; s=iport; t=1400039930; x=1401249530; h=from:to:subject:date:message-id:mime-version; bh=VoBEjiuHVWHPb36ypNtrm5MSgYvhKNV4bwzfIBAPkwc=; b=KLTjroVJ0zqlyFgoxsIzeELoz3thAmrtv0TpMdn6Cpx04mwT1FBisJpq xW1sedwRVuxJTRpaiGqHsggtFBmnKgOqk9CennvJi09m8nnriYCSE9g8V akpk1LxXu/aPBGzjZxdNlExx3FKZKOGa89b+fft7KV2tmBvW9LmDAvcsN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUJAOXoclOtJV2R/2dsb2JhbAA/FwOCQkQcM1irSwEBAQEBBQGSYgGHOoElFnSCKgJVEyMBDw0YBAw8JAMBA4hUDTabe5NKoFgXhVSHAYE1MwEMHAeCHFOBOQSEWnGUBZMQgmNTbYFD X-IronPort-AV: E=Sophos;i="4.97,1049,1389744000"; d="scan'208,217";a="324708948" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 14 May 2014 03:58:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4E3wnIb012547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 May 2014 03:58:49 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 13 May 2014 22:58:49 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Reminder - SCIM WG call tomorrow @11AM Pacific Thread-Index: AQHPbyjPyG/53TPzCkSwkokBda2G+g== Date: Wed, 14 May 2014 03:58:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.125.57] Content-Type: multipart/alternative; boundary="_000_CF983806DD07Emoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/TkyUiuy7SSAP0rch56kdL9ZGTfI Subject: [scim] Reminder - SCIM WG call tomorrow @11AM Pacific X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 03:58:59 -0000 --_000_CF983806DD07Emoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just a reminder that we have the WG biweekly call tomorrow, Wed. May 14th a= t 11AM pacific time. Great work by the WG in the past few weeks and we are = now down to 8 open issues. We will be reviewing the remaining open tracker= issues on the call tomorrow. Cheers, Morteza =97 You are the host for this online meeting. To invite others to join, copy and paste everything below into your invitat= ion. ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: SCIM WG bi-weekly call Date: Every 2 weeks on Wednesday, from Wednesday, March 19, 2014 to no end = date Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 385 408 774 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://go.webex.com/go/j.php?ED=3D3985158&UID=3D483472947&RT=3DMiM0 ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. US Toll Free: +1-855-749-4751 US Toll: +1-415-655-0000 Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceTyp= e=3DMC&ED=3D3985158&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:385 408 774 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://go.webex.com/go/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://go.webex.com/go/j.php?MTID=3Dm92f0520f46fac9644ab9358042b273d0 To check whether you have the appropriate players installed for UCF (Univer= sal Communications Format) rich media files, go to https://go.webex.com/go/= systemdiagnosis.php. http://www.webex.com CCM:+14156550000x385408774# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. You should inform all meeting attendees prior to recording= if you intend to record the meeting. Please note that any such recordings = may be subject to discovery in the event of litigation. --_000_CF983806DD07Emoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Just a reminder th= at we have the WG biweekly call tomorrow, Wed. May 14th at 11AM pacific tim= e. Great work by the WG in the past few weeks and we are now down to 8 open= issues. We will be reviewing the remaining open tracker issues on the call tomorrow.

Cheers,

Morteza

=97

You are the host for this online meeting.
To invite others to join, copy and paste everything below= into your invitation.
-------------------------------------------------------&n= bsp;
Meeting information
-------------------------------------------------------&n= bsp;
Topic: SCIM WG bi-weekly call
Date: Every 2 weeks on Wednesday, from Wednesday, March 1= 9, 2014 to no end date
Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT= -07:00)
Meeting Number: 385 408 774
Meeting Password: (This meeting does not require a passwo= rd.)

-------------------------------------------------------&n= bsp;
To start or join the online meeting
-------------------------------------------------------&n= bsp;
Go to https://go.webex.com/go/j.php?ED=3D3985158&UID=3D483472947&R= T=3DMiM0

-------------------------------------------------------&n= bsp;
Audio conference information
-------------------------------------------------------&n= bsp;
To receive a call back, provide your phone number when yo= u join the meeting, or call the number below and enter the access code.&nbs= p;
US Toll Free: +1-855-749-4751
US Toll: +1-415-655-0000
Global call-in numbers: https://go.webex.com/go/globalcallin.= php?serviceType=3DMC&ED=3D3985158&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:385 408 774

-------------------------------------------------------&n= bsp;
For assistance
-------------------------------------------------------&n= bsp;
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".=
To add this meeting to your calendar program (for example= Microsoft Outlook), click this link:
https://go.webex.com/go/j.php?MTID=3D= m92f0520f46fac9644ab9358042b273d0

To check whether you have the appropriate players install= ed for UCF (Universal Communications Format) rich media files, go to <= /span>h= ttps://go.webex.com/go/systemdiagnosis.php.

http://www.= webex.com

CCM:+14156550000x385408774#

IMPORTANT NOTICE: This WebEx service includes a feature t= hat allows audio and any documents and other materials exchanged or viewed = during the session to be recorded. You should inform all meeting attendees prior to recording if you intend t= o record the meeting. Please note that any such recordings may be subject t= o discovery in the event of litigation.

--_000_CF983806DD07Emoransarciscocom_-- From nobody Fri May 16 12:16:54 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 D6C1A1A0171 for ; Fri, 16 May 2014 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 I6__r9tmBKb9 for ; Fri, 16 May 2014 12:16:50 -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 29FC51A00EA for ; Fri, 16 May 2014 12:16:50 -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 s4GJGfu2001719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 May 2014 19:16:42 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4GJGfhJ022549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 May 2014 19:16:41 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4GJGeAc005274 for ; Fri, 16 May 2014 19:16:40 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 May 2014 12:16:40 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_398E35C8-E744-4CAC-8E3C-5328F6F1D539" Message-Id: Date: Fri, 16 May 2014 12:16:37 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/BOWvMLH_EZOzFh5gvbPWrqPYc70 Subject: [scim] PUT and meaning of omitting values 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, 16 May 2014 19:16:52 -0000 --Apple-Mail=_398E35C8-E744-4CAC-8E3C-5328F6F1D539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text. Old text: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed; I would like to propose this text instead: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the attribute=20= or specific values means the attribute or specific value SHALL=20 be removed; I am not sure if we need to put in text for =93writeOnly=94 attributes. = For passwords you would expect the client to omit password and you would = not expect the existing password value to be removed (unlike readWrite). = However because writeOnly could be attributes other than passwords = (user security questions), I=92m reluctant to specify what should be = done. Thoughts? If your head is exploding now, don=92t worry, mine is. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_398E35C8-E744-4CAC-8E3C-5328F6F1D539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I was = just thinking about our PUT rules and was considering what it means to = omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text.

Old = text:

readWrite, writeOnly  Any values provided SHALL replace the =
existing
      attribute values.  Omitting the attribute or specific values means
      the attribute or specific value SHALL be =
removed;

I would like to propose = this text instead:

readWrite, writeOnly  Any values provided =
SHALL replace the existing
      attribute values. For readWrite attributes, omitting the =
attribute

      or specific values means the attribute or =
specific value SHALL

      be =
removed;

I am not sure if we need to put = in text for =93writeOnly=94 attributes. For passwords you would expect = the client to omit password and you would not expect the existing = password value to be removed (unlike readWrite). However because = writeOnly could be attributes other than passwords (user security = questions), I=92m reluctant to specify what should be = done.

Thoughts?

If = your head is exploding now, don=92t worry, mine = is.

Phil

@independentid<= /div>

= --Apple-Mail=_398E35C8-E744-4CAC-8E3C-5328F6F1D539-- From nobody Fri May 16 14:22:10 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 18B8A1A0248 for ; Fri, 16 May 2014 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 jFy8NejV2kTO for ; Fri, 16 May 2014 14:22:06 -0700 (PDT) Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E5B1A0191 for ; Fri, 16 May 2014 14:22:06 -0700 (PDT) Received: from [98.139.212.153] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:21:58 -0000 Received: from [98.139.212.211] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:21:58 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 16 May 2014 21:21:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 131774.34871.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 8994 invoked by uid 60001); 16 May 2014 21:21:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400275318; bh=dQq10nhVCC3vluDbGJ6jTZKmB6wG/0zhfzDdYPwJfxI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nbvEic24jwcRy49Mrjmig0STyLr4Iix2pwTm/R5pU4yB6pAkK3qfCig6dFmhmeu0yk6POLNoUaIVGrOHCo+k1Yy20sDnexGBRWt3JaenwThf4yU0az7B01uO3NvMhvAjmDOQyudemXAEz2QFq2cQqKov0pmcmI0hwDzLfOdX4kg= X-YMail-OSG: TyFm1O4VM1mRhRox3XgeXeBlObEsFhgsjSdvEOh6VEYA8oN FXFBvvYDacH1sb_B4f5xmmL.ULiAkppRckL.r_qoJZ79YzcmxatxUEq2vAx4 QVZLvXMD8PI50hAwnRk1d2giWGiIl0eCL7IsmaHVpsgBx4Tl.y3XDzDVDgHe 86TBj3ar4Q24tl85UPMf3Vii3QHtz8hhHKO7lYpxv4JobbRv1MOMkejf0tg2 PrVJVmFCXsYc5KsFdk7IlqoVoU2hSpvRelQ_32oQYjBm10A3fLK3Wcm2J0Sr bCp31hgBvGVBj35Toc8AbunDkBRAxL7Cn7AwT7Q8WhGGxCvYTZ3V5SuUSePK Ndqnyo7J3.ARNIdmK.iBmk8fbX0yGN2N9rQL8NzcKUWgyUtckvBl5jA0DPyB 8BPgDgE6zpJxvQ9e5kKA6MSNbP426kHekNWQPDsEC8NI.dijvdtp1oTBwX4X b.v22H52cgTmzzcQoioRNu8uquoVpRsbxmP6QtmCmUKN_HQXV2chSG_GU3NO WN1Pz6oQtQWsIyWRXHHkLv07Otm3TE3Snidw0fcGtrhVzwnaQKMerhyIao1c kRX_yJT_HbA_d1YmjkKStTeyjfrzsrDNEDbcY8A3Fn7nt6Ye5ph3_hiLDTrB LgJSXD5Td8b2613uAOU4.blLmhyGt1QuxoZM.2poIXB48BY5Fq9Q- Received: from [209.131.62.113] by web142801.mail.bf1.yahoo.com via HTTP; Fri, 16 May 2014 14:21:57 PDT X-Rocket-MIMEInfo: 002.001, UFVUIGlzIGEgcmVwbGFjZW1lbnQgb2YgdGhlIGVudGlyZSBvYmplY3QsIHVzZSBpdCBjYXJlZnVsbHkuLi4uCgpUaGUgc3R1ZmYgeW91IGRvIG5vdCBnZXQgdG8gY2hhbmdlIGxpa2UgdGhlIG1ldGFkYXRhIGlzIGludGVyZXN0aW5nLiDCoFBVVCBzaG91bGRuJ3Qgb3ZlcndyaXRlIHRoZSBjcmVhdGlvbiB0aW1lIG9mIHRoZSBvYmplY3QgZm9yIGV4YW1wbGUuIMKgTWV0YXRkYXRhIGlzIHdoZXJlIGl0IGdldHMgaGFyZCwgdGhlIGFjdHVhbCBjb250ZW50cyBhcmUgZWFzeS4KCgpPbiBGcmlkYXksIE1heSAxNiwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: Message-ID: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Fri, 16 May 2014 14:21:57 -0700 (PDT) From: Bill Mills To: Phil Hunt , Scim WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-1630139635-1400275317=:35055" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VRLMT7_PBU0kpJNk2ZnUsYqGLbg Subject: Re: [scim] PUT and meaning of omitting values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 21:22:08 -0000 --469468616-1630139635-1400275317=:35055 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable PUT is a replacement of the entire object, use it carefully....=0A=0AThe st= uff you do not get to change like the metadata is interesting. =C2=A0PUT sh= ouldn't overwrite the creation time of the object for example. =C2=A0Metatd= ata is where it gets hard, the actual contents are easy.=0A=0A=0AOn Friday,= May 16, 2014 12:36 PM, Phil Hunt wrote:=0A =0AI was= just thinking about our PUT rules and was considering what it means to omi= t values. =C2=A0Passwords (writeOnly attributes) came to mind as problemati= c in the current text.=0A=0AOld text:=0AreadWrite, writeOnly Any values pr= ovided SHALL replace the existing attribute values. Omitting the attribute= or specific values means the attribute or specific value SHALL be removed;= =0A=0AI would like to propose this text instead:=0AreadWrite, writeOnly An= y values provided SHALL replace the existing attribute values. For readWrit= e attributes, omitting the attribute=C2=A0=0Aor specific values means the a= ttribute or specific value SHALL=C2=A0=0Abe removed;=0A=0AI am not sure if = we need to put in text for =E2=80=9CwriteOnly=E2=80=9D attributes. For pass= words you would expect the client to omit password and you would not expect= the existing password value to be removed (unlike readWrite). =C2=A0Howeve= r because writeOnly could be attributes other than passwords (user security= questions), I=E2=80=99m reluctant to specify what should be done.=0A=0ATho= ughts?=0A=0AIf your head is exploding now, don=E2=80=99t worry, mine is.=0A= =0APhil=0A=0A@independentid=0Awww.independentid.comphil.hunt@oracle.com=0A= =0A=0A=0A_______________________________________________=0Ascim mailing lis= t=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/scim --469468616-1630139635-1400275317=:35055 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

PUT is a replacement of the entire object, use it = carefully....

T= he stuff you do not get to change like the metadata is interesting. P= UT shouldn't overwrite the creation time of the object for example. M= etatdata is where it gets hard, the actual contents are easy.

O= n Friday, May 16, 2014 12:36 PM, Phil Hunt <phil.hunt@oracle.com> wro= te:

I was just thinking about our PUT rules and was considering what= it means to omit values. Passwords (writeOnly attributes) came to mi= nd as problematic in the current text.

Old text:

readWrite, writeOnly  Any values provided SHALL repla=
ce the existing=0A      attribute values.  Omitting the attribute or specif=
ic values means=0A      the attribute or specific value SHALL be removed;
=0A<=
span class=3D"yiv2051513252Apple-style-span" style=3D"border-collapse: sepa=
rate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
 normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: 2; word-spacing: 0px; border-spacing: 0px;">I would like to propose this text instead:
r=
eadWrite, writeOnly  Any values provided SHALL replace the existing=0A     =
 attribute values. For readWrite attributes, omitting the attribute       or specific values means the attribute or spec=
ific value SHALL 
      be removed;
=

I am not sure if we need to put in text for =E2=80=9Cw=
riteOnly=E2=80=9D attributes. For passwords you would expect the client to =
omit password and you would not expect the existing password value to be re=
moved (unlike readWrite).  However because writeOnly could be attribut=
es other than passwords (user security questions), I=E2=80=99m reluctant to=
 specify what should be done.

Thoughts?
=

If your head is exploding now, don=E2=80=99t worry, mine is.=

Phil

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


=0A
=0A

<= /div>
_______________________________________________
scim mailing li= st
sci= m@ietf.org
https://www.ietf.org/mailman/listinfo/scim

<= /div>

--469468616-1630139635-1400275317=:35055-- From nobody Fri May 16 17:09:52 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 16EF61A01DC for ; Fri, 16 May 2014 17:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 QgN19hGyy_rC for ; Fri, 16 May 2014 17:09:47 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C28A1A01CB for ; Fri, 16 May 2014 17:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11488; q=dns/txt; s=iport; t=1400285380; x=1401494980; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8GHDcXn5DHSHDnnzftZa7GOfpNC8BEwSujoTOFeHix8=; b=ljm9JXssqRTHncsvg3As0U3taEEkv9lxdxP6Zoxm5eNZjSAEl8XtwoAs tCIJrDPyVY88Oy7gZY5UflftP24mzbubPMBEpsoryHiAhWwc+hXNH4cfC 4bsTnBtCYH39qi67zRAefvXAND9GlIl/oMs6w6ACQKOmENgDH+1B+nTGn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMGAKqndlOtJV2d/2dsb2JhbABZgkJET1ipTwUBgjOQOgGHPAGBDRZ0giUBAQEEAQEBRiUbAgEIBwcDAwECGQ8HJwsTAQkIAgQBEogtAxEN0WMXhVWGZYIEDQsYhCgEhFwEgzCPWoFuh3qFNIVrgzeCMA X-IronPort-AV: E=Sophos;i="4.97,1070,1389744000"; d="scan'208,217";a="44627280" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 17 May 2014 00:09:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4H09cl4013680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 00:09:38 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 16 May 2014 19:09:37 -0500 From: "Morteza Ansari (moransar)" To: Bill Mills , Phil Hunt , Scim WG Thread-Topic: [scim] PUT and meaning of omitting values Thread-Index: AQHPcTtkox5f8Du2NkOq81M7cXY0K5tECxaA//+5fwA= Date: Sat, 17 May 2014 00:09:37 +0000 Message-ID: References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> In-Reply-To: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.95.149] Content-Type: multipart/alternative; boundary="_000_CF9BF62EDE346moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pDuAza8ISBaViHJz_s86SmYAbGo Subject: Re: [scim] PUT and meaning of omitting values 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, 17 May 2014 00:09:50 -0000 --_000_CF9BF62EDE346moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are other cases to consider here. If the reader does not have read ac= cess to some attributes, those attributes should not be removed either. Es= sentially in our implementation PUT is a special case of PATCH to handle au= thorization case and metadata (much like operational attributes were handle= d in LDAP). Cheers, Morteza From: Bill Mills > Reply-To: Bill Mills = > Date: Friday, May 16, 2014 at 2:21 PM To: Phil Hunt >, "scim@ie= tf.org" > Subject: Re: [scim] PUT and meaning of omitting values PUT is a replacement of the entire object, use it carefully.... The stuff you do not get to change like the metadata is interesting. PUT s= houldn't overwrite the creation time of the object for example. Metatdata = is where it gets hard, the actual contents are easy. On Friday, May 16, 2014 12:36 PM, Phil Hunt > wrote: I was just thinking about our PUT rules and was considering what it means t= o omit values. Passwords (writeOnly attributes) came to mind as problemati= c in the current text. Old text: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed; I would like to propose this text instead: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the attribute or specific values means the attribute or specific value SHALL be removed; I am not sure if we need to put in text for =93writeOnly=94 attributes. For= passwords you would expect the client to omit password and you would not e= xpect the existing password value to be removed (unlike readWrite). Howeve= r because writeOnly could be attributes other than passwords (user security= questions), I=92m reluctant to specify what should be done. Thoughts? If your head is exploding now, don=92t worry, mine is. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_CF9BF62EDE346moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6C1B9143533B0D4D90801C14C1B8996B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

There are other cases to consider here. If the reader does not have re= ad access to some attributes, those attributes should not be removed either= . Essentially in our implementation PUT is a special case of PATCH to= handle authorization case and metadata (much like operational attributes were handled in LDAP).

Cheers,

Morteza

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at 2:21 = PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and meaning= of omitting values

The stuff you do not get to change like the metadata is interesting. = PUT shouldn't overwrite the creation time of the object for example. = Metatdata is where it gets hard, the actual contents are easy.

On Friday, May 16, 2014 12= :36 PM, Phil Hunt <phil.hunt@ora= cle.com> wrote:

I was just thinking about our PUT rules and was considering what it me= ans to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text.

Old text:

readWrite, writeOnly  Any values provided SHALL replace =
the existing
      attribute values.  Omitting the attribute or specific values means
      the attribute or specific value SHALL be removed;

I would like to propose this text instead:

readWrite, writeOnly  Any values provided SHALL replace =
the existing
      attribute values. For readWrite attributes, omitting the attribute&nb=
sp;

      or specific values means the attribute or specific=
 value SHALL

      be removed;

I am not sure if we need to put in text for =93writeOnly=94 attributes= . For passwords you would expect the client to omit password and you would = not expect the existing password value to be removed (unlike readWrite). &n= bsp;However because writeOnly could be attributes other than passwords (user security questions), I=92m reluctant to specify= what should be done.

Thoughts?

If your head is exploding now, don=92t worry, mine is.

Phil

@independentid

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

--_000_CF9BF62EDE346moransarciscocom_-- From nobody Fri May 16 17:14: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 372741A01DC for ; Fri, 16 May 2014 17:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, 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 kAyku79J02Mr for ; Fri, 16 May 2014 17:14:20 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590971A01CB for ; Fri, 16 May 2014 17:14:20 -0700 (PDT) Received: from [66.196.81.173] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 00:14:12 -0000 Received: from [98.139.212.204] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 00:14:12 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 17 May 2014 00:14:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 143513.83587.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 44259 invoked by uid 60001); 17 May 2014 00:14:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400285652; bh=CLmw9/jB6IGHCg0KRgz9lvRVjstj9+iU5AihiXPY2sk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yeeGi3+JcS5+p7Tz92Z73QRecWKH7nm2AF0RVyDtvwBOeUNQKcxOZ1vfUanGtz2eg2PO+Je94QnESWzDPZVmUzZAedE6v3z0DhYFKb/HC7Nbshb9ilfJaxy37PRVQuZ2GAPP42UhXaKVsQzht8Xhtcp2ceYz3yFMvnImyICBxFA= X-YMail-OSG: YiwD7S4VM1kqE10PqQU3Y2iVfEUEVuG.f9LAoRsQ_t1cZam QxNX.7hgxVZqjMsDVjPNXtu.jMUdkdsveJU9_WRRCcw8A8Va4lFJRQG7gBXo 7u6YWD0G72VocnOHmLL7Me9OFm3jf3I9MMhFutPfhr2gFAcQVJbiRgMDQQf0 sZv_HSadyCWnTrtHv33lC3QujV3Ovsp58DCFid1rWLray8SJa12.E2Koap6t tdtc3QnlpVm2SHDKRnQx_aywpa_ufKO6I9y27YV6eG9C4lCka_XAr0Q5oqG9 OPT8aKksDeAkwVSlGhu5SY4M66VLCRHHTSQ__V78LSUruEm1MRxc_QM53CYD Im87cO_JSV3vWwSWB3lxLrNuc9zxfo1mN8BygrLLz1qyDIESUBztzQLCG4_p tWDPNljTpwcLP.WrQ63bsJ5kvTD0eP7IhTLE8A.z5xDOTHpjv0Qg0fJxSG.7 uu0N39Sm.cVYx69VcCWYsAxOjW_wI5zZglVIBW1VAWBoNm_J5xt4vhlALD3n VxTcXQr0cPSDsUdVFOIkxzXoLDtn865ewO0SmJ6iUMEh0StFfFMAAS3.6FH9 9LjT_GoUmEo2ktHiHYdGIk6K7xiKSA_Yz7pfcfxsaygPzglfIQ6EBK05Q8Sx rls8Wnmd6bFBG0ckNIb6UGhnn97yssO59WEJxefgUghokSnZ.xg-- Received: from [66.228.162.48] by web142802.mail.bf1.yahoo.com via HTTP; Fri, 16 May 2014 17:14:11 PDT X-Rocket-MIMEInfo: 002.001, SSB3b3VsZCBhcmd1ZSB0aGF0IGlmIHlvdSBkb24ndCBoYXZlIGFsbCBvZiB0aGUgZGF0YSBmb3IgYSB1c2VyIHRoZW4gdXNpbmcgUFVUIGlzIHdyb25nIGFuZCB5b3UgbXVzdCB1c2UgUEFUQ0guCgoKT24gRnJpZGF5LCBNYXkgMTYsIDIwMTQgNTowOSBQTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSA8bW9yYW5zYXJAY2lzY28uY29tPiB3cm90ZToKIApUaGVyZSBhcmUgb3RoZXIgY2FzZXMgdG8gY29uc2lkZXIgaGVyZS4gSWYgdGhlIHJlYWRlciBkb2VzIG5vdCBoYXZlIHJlYWQgYWNjZXNzIHRvIHNvbWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> Message-ID: <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Fri, 16 May 2014 17:14:11 -0700 (PDT) From: Bill Mills To: "Morteza Ansari \(moransar\)" , Phil Hunt , Scim WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-451211028-1400285651=:45571" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/rv6tmgv1SSK8tokSb-EMAl8MkNI Subject: Re: [scim] PUT and meaning of omitting values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 00:14:22 -0000 --1397251415-451211028-1400285651=:45571 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would argue that if you don't have all of the data for a user then using = PUT is wrong and you must use PATCH.=0A=0A=0AOn Friday, May 16, 2014 5:09 P= M, Morteza Ansari (moransar) wrote:=0A =0AThere are ot= her cases to consider here. If the reader does not have read access to some= attributes, those attributes should not be removed either. =C2=A0Essential= ly in our implementation PUT is a special case of PATCH to handle authoriza= tion case and metadata (much like operational attributes were handled in LD= AP).=C2=A0=0A=0A=0ACheers,=0AMorteza=C2=A0=0A=0AFrom: Bill Mills =0AReply-To: Bill Mills =0ADate: Frid= ay, May 16, 2014 at 2:21 PM=0ATo: Phil Hunt , "scim@i= etf.org" =0ASubject: Re: [scim] PUT and meaning of omitting = values=0A=0A=0APUT is a replacement of the entire object, use it carefully.= ...=0A=0AThe stuff you do not get to change like the metadata is interestin= g. =C2=A0PUT shouldn't overwrite the creation time of the object for exampl= e. =C2=A0Metatdata is where it gets hard, the actual contents are easy.=0A= =0A=0AOn Friday, May 16, 2014 12:36 PM, Phil Hunt wr= ote:=0A=0AI was just thinking about our PUT rules and was considering what = it means to omit values. =C2=A0Passwords (writeOnly attributes) came to min= d as problematic in the current text. =0A=0AOld text:=0AreadWrite, writeOnl= y Any values provided SHALL replace the existing attribute values. Omitti= ng the attribute or specific values means the attribute or specific value S= HALL be removed;=0A=0AI would like to propose this text instead:=0AreadWrit= e, writeOnly Any values provided SHALL replace the existing attribute valu= es. For readWrite attributes, omitting the attribute=C2=A0=0Aor specific va= lues means the attribute or specific value SHALL=C2=A0=0Abe removed;=0A=0AI= am not sure if we need to put in text for =E2=80=9CwriteOnly=E2=80=9D attr= ibutes. For passwords you would expect the client to omit password and you = would not expect the existing password value to be removed (unlike readWrit= e). =C2=A0However because writeOnly could be attributes other than password= s (user security questions), I=E2=80=99m reluctant to specify what should b= e done.=0A=0AThoughts?=0A=0AIf your head is exploding now, don=E2=80=99t wo= rry, mine is.=0A=0APhil=0A=0A@independentid=0Awww.independentid.comphil.hun= t@oracle.com=0A=0A=0A=0A_______________________________________________=0As= cim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/sc= im --1397251415-451211028-1400285651=:45571 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I would argue that if you don't have all of the da= ta for a user then using PUT is wrong and you must use PATCH.

On Friday,= May 16, 2014 5:09 PM, Morteza Ansari (moransar) <moransar@cisco.com>= wrote:

=0A

There are other cases to consider here. If the reade= r does not have read access to some attributes, those attributes should not= be removed either. Essentially in our implementation PUT is a specia= l case of PATCH to handle authorization case and metadata=0A (much like ope= rational attributes were handled in LDAP).

=0A

Cheers,

=0A=

Morteza

=0A

=0A=0A

=0AFrom: Bill Mills <= wmills_92105@yahoo.com>
=0AReply-To: Bill Mills <wmills_92105@yahoo.com>
=0ADate: Friday, May 16, 2014 at = 2:21 PM
=0ATo: P= hil Hunt <phil.hu= nt@oracle.com>, "scim@ietf.= org" <scim@ietf.org>=
=0ASubject: Re:= [scim] PUT and meaning of omitting values
=0A

=0A
=0A

=0A

PUT is a replacement of the entire object, use it ca= refully....

=0A

= =0A
=0A

=0A

=0AThe stuff you do not get to change like the met= adata is interesting. PUT shouldn't overwrite the creation time of th= e object for example. Metatdata is where it gets hard, the actual con= tents are easy.
=0A
=0A

=0A=

=0A

= On Friday, May 16, 2014 12:36 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
=0A

=0A

= =0A

=0A

I was just thinking about our PUT rule= s and was considering what it means to omit values. Passwords (writeO= nly attributes) came to mind as problematic in the current text.=0A

=0A

Old text:

=0A

readWrite, writeOnly  Any values provided SHALL replace the existing=0A =
     attribute values.  Omitting the attribute or specific values means=0A =
     the attribute or specific value SHALL be removed;

=0A

=0A=0A

=0A

I wou= ld like to propose this text instead:

=0A

re=
adWrite, writeOnly  Any values provided SHALL replace the existing=0A      =
attribute values. For readWrite attributes, omitting the attribute =0A      or specific values means the attribute or sp=
ecific value SHALL 
=0A      be removed;=0A
=0A
=0A

=0A

I am not sure if we n= eed to put in text for =E2=80=9CwriteOnly=E2=80=9D attributes. For password= s you would expect the client to omit password and you would not expect the= existing password value to be removed (unlike readWrite). However be= cause writeOnly could be attributes=0A other than passwords (user security = questions), I=E2=80=99m reluctant to specify what should be done.

=0A<= div>
=0A

=0A

Thoughts?

=0A

If your head is exploding now, don=E2=80=99t worry,= mine is.

=0A

Phil

=0A
=0A

=0A

@independentid

=0A

=0A

=0Aphil.hunt@oracle.com

=0A

= =0A

=0A

=0A
=0A

=0A=

=0A

=0A
=0A___________________________________= ____________
=0Ascim mailing list
=0Ascim@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/scim=
=0A
=0A
=0A=0A

=0A

=0A=0A

--1397251415-451211028-1400285651=:45571-- From nobody Fri May 16 17:29: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 B7A1F1A01E0 for ; Fri, 16 May 2014 17:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 m4iLhaXhDF3D for ; Fri, 16 May 2014 17:29:48 -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 36E041A01CB for ; Fri, 16 May 2014 17:29:48 -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 s4H0TbkQ025572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 May 2014 00:29:38 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 s4H0TaJM002005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 May 2014 00:29:36 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4H0TaoR018841; Sat, 17 May 2014 00:29:36 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 May 2014 17:29:36 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5DD005D-FB4B-4A70-BD69-931BD43834B1" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Fri, 16 May 2014 17:29:34 -0700 Message-Id: <894F4513-1130-425B-85D2-4C9D4B1C8E3D@oracle.com> References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> To: Morteza Ansari X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/7By9mbYNoGAAWhZvvx6BbnpgySU Cc: Scim WG , Bill Mills Subject: Re: [scim] PUT and meaning of omitting values 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, 17 May 2014 00:29:51 -0000 --Apple-Mail=_F5DD005D-FB4B-4A70-BD69-931BD43834B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We had that discussion just today in our internal standards group. = Access control impacts what a client can see. At the very least omission = processing should only count for attributes a client can see.=20 I know that=92s complex, but I can=92t see it working otherwise. I think the power of PUT over PATCH is that for doc centric SPs, PUT is = easier (maybe). The other advantage (or disadvantage) is that the = client code is simplified leaving the SP to figure out what the implied = patch is. =20 But I think the big use case for PUT will be bean based clients. = Consider java beans where you have a bean holding state in memory (e.g. = for a UI). Depending on your architecture you may not know how the bean = has been modified compared to the original. For default bean approaches, = you just want to save the bean which probably translates into a PUT. I = should probably ask our Jersey experts about this. As for Bills comment, that was the same sentiment we had internally. Try = not to use it. Ugh. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 16, 2014, at 5:09 PM, Morteza Ansari (moransar) = wrote: > There are other cases to consider here. If the reader does not have = read access to some attributes, those attributes should not be removed = either. Essentially in our implementation PUT is a special case of = PATCH to handle authorization case and metadata (much like operational = attributes were handled in LDAP).=20 >=20 >=20 > Cheers, > Morteza=20 >=20 > From: Bill Mills > Reply-To: Bill Mills > Date: Friday, May 16, 2014 at 2:21 PM > To: Phil Hunt , "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values >=20 > PUT is a replacement of the entire object, use it carefully.... >=20 > The stuff you do not get to change like the metadata is interesting. = PUT shouldn't overwrite the creation time of the object for example. = Metatdata is where it gets hard, the actual contents are easy. >=20 > On Friday, May 16, 2014 12:36 PM, Phil Hunt = wrote: > I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text. >=20 > Old text: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. Omitting the attribute or specific values = means > the attribute or specific value SHALL be removed; >=20 > I would like to propose this text instead: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. For readWrite attributes, omitting the = attribute=20 > or specific values means the attribute or specific value SHALL=20= > be removed; >=20 > I am not sure if we need to put in text for =93writeOnly=94 = attributes. For passwords you would expect the client to omit password = and you would not expect the existing password value to be removed = (unlike readWrite). However because writeOnly could be attributes other = than passwords (user security questions), I=92m reluctant to specify = what should be done. >=20 > Thoughts? >=20 > If your head is exploding now, don=92t worry, mine is. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail=_F5DD005D-FB4B-4A70-BD69-931BD43834B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We had = that discussion just today in our internal standards group. Access = control impacts what a client can see. At the very least omission = processing should only count for attributes a client can = see.

I know that=92s complex, but I can=92t see = it working otherwise.

I think the power of PUT = over PATCH is that for doc centric SPs, PUT is easier (maybe). The = other advantage (or disadvantage) is that the client code is simplified = leaving the SP to figure out what the implied patch is. =

But I think the big use case for PUT = will be bean based clients. Consider java beans where you have a bean = holding state in memory (e.g. for a UI). Depending on your architecture = you may not know how the bean has been modified compared to the = original. For default bean approaches, you just want to save the bean = which probably translates into a PUT. I should probably ask our = Jersey experts about this.

As for Bills = comment, that was the same sentiment we had internally. Try not to use = it. Ugh.

Phil

@independentid

On May 16, 2014, at 5:09 PM, Morteza Ansari (moransar) = <moransar@cisco.com> = wrote:

There are other cases to consider here. If the reader does not have = read access to some attributes, those attributes should not be removed = either. Essentially in our implementation PUT is a special case of = PATCH to handle authorization case and metadata (much like operational attributes were handled in LDAP).

Cheers,

Morteza

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at = 2:21 PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and = meaning of omitting values

PUT is a replacement of the entire object, use it = carefully....

The stuff you do not get to change like the metadata is = interesting. PUT shouldn't overwrite the creation time of the = object for example. Metatdata is where it gets hard, the actual = contents are easy.

On Friday, May 16, 2014 = 12:36 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to = mind as problematic in the current text.

Old text:

readWrite, = writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed;

I would like to propose this text instead:

readWrite, = writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the = attribute

or = specific values means the attribute or specific value SHALL

be = removed;

I am not sure if we need to put in text for =93writeOnly=94 = attributes. For passwords you would expect the client to omit password = and you would not expect the existing password value to be removed = (unlike readWrite). However because writeOnly could be attributes other than passwords (user security questions), I=92m reluctant to = specify what should be done.

Thoughts?

If your head is exploding now, don=92t worry, mine is.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

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

= --Apple-Mail=_F5DD005D-FB4B-4A70-BD69-931BD43834B1-- From nobody Fri May 16 17:53: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 311391A01ED for ; Fri, 16 May 2014 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 gmEtzkv2mdJh for ; Fri, 16 May 2014 17:53:10 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831CB1A01F1 for ; Fri, 16 May 2014 17:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20098; q=dns/txt; s=iport; t=1400287983; x=1401497583; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e48CiExTDOIz/mG39ecVRy+VMfnuChO1Ch8ITCmbRiQ=; b=JgBKWhHDWs7wPFoDNuqQ8WZuMJ2tupWHzD6u17zDXTbVMLyoMBSm5Xqp AOrRUE68Ppk9iQJj/keLlVMi68YZFDLcI8ay+TKJ9FQq5z+fm3R8NSrTt XLyWHxnXyeCfxPKe/v9FAPR1BxwRjK4ILGpcKzZbu5SLwcAsBMNeAPHpl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMGAEaydlOtJV2P/2dsb2JhbABZgkJET1ipUAUBgjOQOgGHPAGBDRZ0giUBAQEEAQEBRiIDCxACAQgHCgECAQIZDwcnCxMBAwYIAgQOBYgtAxEN0VoXhVWGZYFHPQ0EBwkPhCgEhFwEkwqBbod6hTSFa4M3gjA X-IronPort-AV: E=Sophos;i="4.97,1070,1389744000"; d="scan'208,217";a="44631886" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 17 May 2014 00:53:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4H0r2M1029497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 00:53:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 16 May 2014 19:53:02 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt Thread-Topic: [scim] PUT and meaning of omitting values Thread-Index: AQHPcTtkox5f8Du2NkOq81M7cXY0K5tECxaA//+5fwCAAHrsAP//kTOA Date: Sat, 17 May 2014 00:53:01 +0000 Message-ID: References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> <894F4513-1130-425B-85D2-4C9D4B1C8E3D@oracle.com> In-Reply-To: <894F4513-1130-425B-85D2-4C9D4B1C8E3D@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.95.149] Content-Type: multipart/alternative; boundary="_000_CF9BFFACDE3BEmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/OcfltrG0L2eV2Hx7YbhDKEDZr0k Cc: Scim WG , Bill Mills Subject: Re: [scim] PUT and meaning of omitting values 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, 17 May 2014 00:53:14 -0000 --_000_CF9BFFACDE3BEmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree, I don=92t think there is a choice here if the implementation has f= ine grained access control. The question is how to describe this in the sp= ec! From: Phil Hunt > Date: Friday, May 16, 2014 at 5:29 PM To: Morteza Ansari > Cc: Bill Mills >, "sc= im@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values We had that discussion just today in our internal standards group. Access c= ontrol impacts what a client can see. At the very least omission processing= should only count for attributes a client can see. I know that=92s complex, but I can=92t see it working otherwise. I think the power of PUT over PATCH is that for doc centric SPs, PUT is eas= ier (maybe). The other advantage (or disadvantage) is that the client code= is simplified leaving the SP to figure out what the implied patch is. But I think the big use case for PUT will be bean based clients. Consider j= ava beans where you have a bean holding state in memory (e.g. for a UI). De= pending on your architecture you may not know how the bean has been modifie= d compared to the original. For default bean approaches, you just want to s= ave the bean which probably translates into a PUT. I should probably ask o= ur Jersey experts about this. As for Bills comment, that was the same sentiment we had internally. Try no= t to use it. Ugh. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 16, 2014, at 5:09 PM, Morteza Ansari (moransar) > wrote: There are other cases to consider here. If the reader does not have read ac= cess to some attributes, those attributes should not be removed either. Es= sentially in our implementation PUT is a special case of PATCH to handle au= thorization case and metadata (much like operational attributes were handle= d in LDAP). Cheers, Morteza From: Bill Mills > Reply-To: Bill Mills = > Date: Friday, May 16, 2014 at 2:21 PM To: Phil Hunt >, "scim@ie= tf.org" > Subject: Re: [scim] PUT and meaning of omitting values PUT is a replacement of the entire object, use it carefully.... The stuff you do not get to change like the metadata is interesting. PUT s= houldn't overwrite the creation time of the object for example. Metatdata = is where it gets hard, the actual contents are easy. On Friday, May 16, 2014 12:36 PM, Phil Hunt > wrote: I was just thinking about our PUT rules and was considering what it means t= o omit values. Passwords (writeOnly attributes) came to mind as problemati= c in the current text. Old text: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed; I would like to propose this text instead: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the attribute or specific values means the attribute or specific value SHALL be removed; I am not sure if we need to put in text for =93writeOnly=94 attributes. For= passwords you would expect the client to omit password and you would not e= xpect the existing password value to be removed (unlike readWrite). Howeve= r because writeOnly could be attributes other than passwords (user security= questions), I=92m reluctant to specify what should be done. Thoughts? If your head is exploding now, don=92t worry, mine is. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_CF9BFFACDE3BEmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <97E80584AC0D2A41ABAFBC991934E64D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

I agree, I don=92t think there is a choice here if the implementation = has fine grained access control. The question is how to describe this= in the spec!

From: Phil Hunt <phil.hunt@oracle.com>
Date: Friday, May 16, 2014 at 5:29 = PM
To: Morteza Ansari <moransar@cisco.com>
Cc: Bill Mills <wmills_92105@yahoo.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and meaning= of omitting values

We had that discussion just today in our internal standards group. Access c= ontrol impacts what a client can see. At the very least omission processing= should only count for attributes a client can see.

I know that=92s complex, but I can=92t see it working otherwise.

I think the power of PUT over PATCH is that for doc centric SPs, PUT i= s easier (maybe). The other advantage (or disadvantage) is that the c= lient code is simplified leaving the SP to figure out what the implied patc= h is.

But I think the big use case for PUT will be bean based clients. Consi= der java beans where you have a bean holding state in memory (e.g. for a UI= ). Depending on your architecture you may not know how the bean has been mo= dified compared to the original. For default bean approaches, you just want to save the bean which probably= translates into a PUT. I should probably ask our Jersey experts abou= t this.

As for Bills comment, that was the same sentiment we had internally. T= ry not to use it. Ugh.

Phil

@independentid

On May 16, 2014, at 5:09 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

There are other cases to consider here. If the reader does not have re= ad access to some attributes, those attributes should not be removed either= . Essentially in our implementation PUT is a special case of PATCH to= handle authorization case and metadata (much like operational attributes were handled in LDAP).

Cheers,

Morteza

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at 2:21 = PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and meaning= of omitting values

PUT is a replacement of the entire object, use it carefully....<= /span>

The stuff you do not get to change like the metadata is interesting. = PUT shouldn't overwrite the creation time of the object for example. = Metatdata is where it gets hard, the actual contents are easy.

On Friday, May 16, 2014 12= :36 PM, Phil Hunt <phil.hunt@ora= cle.com> wrote:

I was just thinking about our PUT rules and was considering what it me= ans to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text.

Old text:

readWrite, writeOnly Any values provided SHALL replace = the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed;

I would like to propose this text instead:

readWrite, writeOnly Any values provided SHALL replace = the existing attribute values. For readWrite attributes, omitting the attribute&nb= sp;

or specific values means the attribute or specific= value SHALL

be removed;

I am not sure if we need to put in text for =93writeOnly=94 attributes= . For passwords you would expect the client to omit password and you would = not expect the existing password value to be removed (unlike readWrite). &n= bsp;However because writeOnly could be attributes other than passwords (user security questions), I=92m reluctant to specify= what should be done.

Thoughts?

If your head is exploding now, don=92t worry, mine is.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

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

--_000_CF9BFFACDE3BEmoransarciscocom_-- From nobody Fri May 16 17:54: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 A92D31A01ED for ; Fri, 16 May 2014 17:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 rx5WmEcd-7dK for ; Fri, 16 May 2014 17:54:13 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7B01A01F1 for ; Fri, 16 May 2014 17:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15874; q=dns/txt; s=iport; t=1400288045; x=1401497645; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fHQxdo60xTEneIRImnkbODLUZas7d5+RwH9tG2VczzU=; b=Kxa8rmpsiHsAu/JecICtr/gyuweB3lzzQ6QI4euE8YnXAPbTIvaqCfxJ EDzKdjPT5W+9GTatviLjK4S7vATs6/GDpkimVtopDc2yFtKZf3IItwfa/ VWe/T/0ZZfvlM6bNQ346VHYi0P2SM7RK0bfEB4ytNjVnqKqpnKiW7yGwK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMGAEaydlOtJA2H/2dsb2JhbABZgkJET1ipUAUBgjOQOgGHPAGBDRZ0giUBAQEEAQEBRiUbAgEIBwcDAwECGQ8HJwsTAQkIAgQBEogtAxEN0VoXhVWGZYIEGBiEKASEXASDMI9agW6HeoU0hWuDN4Iw X-IronPort-AV: E=Sophos;i="4.97,1070,1389744000"; d="scan'208,217";a="44631991" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP; 17 May 2014 00:54:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4H0s5c8002655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 00:54:05 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 16 May 2014 19:54:04 -0500 From: "Morteza Ansari (moransar)" To: Bill Mills , Phil Hunt , Scim WG Thread-Topic: [scim] PUT and meaning of omitting values Thread-Index: AQHPcTtkox5f8Du2NkOq81M7cXY0K5tECxaA//+5fwCAAHaggP//lccA Date: Sat, 17 May 2014 00:54:04 +0000 Message-ID: References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.95.149] Content-Type: multipart/alternative; boundary="_000_CF9C0103DE3E2moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6oLJ4QxCLPdISmfxn9M2gN4wdzs Subject: Re: [scim] PUT and meaning of omitting values 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, 17 May 2014 00:54:15 -0000 --_000_CF9C0103DE3E2moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable But the client doesn=92t know it doesn=92t have all the data. From the cli= ent perspective it has the whole object. From: Bill Mills > Reply-To: Bill Mills = > Date: Friday, May 16, 2014 at 5:14 PM To: Morteza Ansari >, Phil Hu= nt >, "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values I would argue that if you don't have all of the data for a user then using = PUT is wrong and you must use PATCH. On Friday, May 16, 2014 5:09 PM, Morteza Ansari (moransar) > wrote: There are other cases to consider here. If the reader does not have read ac= cess to some attributes, those attributes should not be removed either. Es= sentially in our implementation PUT is a special case of PATCH to handle au= thorization case and metadata (much like operational attributes were handle= d in LDAP). Cheers, Morteza From: Bill Mills > Reply-To: Bill Mills = > Date: Friday, May 16, 2014 at 2:21 PM To: Phil Hunt >, "scim@ie= tf.org" > Subject: Re: [scim] PUT and meaning of omitting values PUT is a replacement of the entire object, use it carefully.... The stuff you do not get to change like the metadata is interesting. PUT s= houldn't overwrite the creation time of the object for example. Metatdata = is where it gets hard, the actual contents are easy. On Friday, May 16, 2014 12:36 PM, Phil Hunt > wrote: I was just thinking about our PUT rules and was considering what it means t= o omit values. Passwords (writeOnly attributes) came to mind as problemati= c in the current text. Old text: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed; I would like to propose this text instead: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the attribute or specific values means the attribute or specific value SHALL be removed; I am not sure if we need to put in text for =93writeOnly=94 attributes. For= passwords you would expect the client to omit password and you would not e= xpect the existing password value to be removed (unlike readWrite). Howeve= r because writeOnly could be attributes other than passwords (user security= questions), I=92m reluctant to specify what should be done. Thoughts? If your head is exploding now, don=92t worry, mine is. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_CF9C0103DE3E2moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4FCA1DE6D1FFCE41B6824506F5DA5EB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

But the client doesn=92t know it doesn=92t have all the data. Fr= om the client perspective it has the whole object.

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at 5:14 = PM
To: Morteza Ansari <moransar@cisco.com>, Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and meaning= of omitting values

On Friday, May 16, 2014 5:= 09 PM, Morteza Ansari (moransar) <= moransar@cisco.com> wrote:

Cheers,

Morteza

From: Bill Mills <wmills_92105@yahoo.com>= ;
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at 2:21= PM
To: Phil Hunt <phil.hunt@oracle.com>, "= scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and meanin= g of omitting values

PUT is a replacement of the entire object, use it carefully....<= /span>

On Friday, May 16, 2014 12= :36 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was just thinking about our PUT rules and was considering what it me= ans to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text.

Old text:

readWrite, writeOnly  Any values provided SHALL replace =
the existing
      attribute values.  Omitting the attribute or specific values means
      the attribute or specific value SHALL be removed;

I would like to propose this text instead:

readWrite, writeOnly  Any values provided SHALL replace =
the existing
      attribute values. For readWrite attributes, omitting the attribute&nb=
sp;

      or specific values means the attribute or specific=
 value SHALL

      be removed;

Thoughts?

If your head is exploding now, don=92t worry, mine is.

Phil

@independentid

--_000_CF9C0103DE3E2moransarciscocom_-- From nobody Fri May 16 18:08:06 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 5847F1A01ED for ; Fri, 16 May 2014 18:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 tdNXNLWWUx4U for ; Fri, 16 May 2014 18:08:02 -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 C4F6C1A01C2 for ; Fri, 16 May 2014 18:08:01 -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 s4H17qUM032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 May 2014 01:07:53 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 s4H17pH0016924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 17 May 2014 01:07:52 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4H17pgE003105; Sat, 17 May 2014 01:07:51 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 May 2014 18:07:50 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D1E9355-118C-4C1D-B4C1-B2ACB27A7360" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Fri, 16 May 2014 18:07:48 -0700 Message-Id: <0E71774A-48A8-4B52-A148-39521F961E41@oracle.com> References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: Morteza Ansari X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/z_HSI0eqITgYrT1UbGVuukHg6y4 Cc: Scim WG , Bill Mills Subject: Re: [scim] PUT and meaning of omitting values 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, 17 May 2014 01:08:04 -0000 --Apple-Mail=_8D1E9355-118C-4C1D-B4C1-B2ACB27A7360 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think implicit delete (absence of a value) is problematic because it = means the SCIM API has to know about the access control system. This is = probably not a good idea.=20 What about an explicit methodology like this: Consider example JSON record:=20 { =93attr_A=94:=94First=94, =93attr_B=94:=94Second=94, =93attr_C=94:=94Third=94, =93attr_D=94:=94Four" } Apply a PUT of: { =93attr_B=94:null, =93attr_C=94:=94=94, =93attr_D=94:{} } Results in: { =93attr_A=94:=94First=94, =93attr_B=94:null, =93attr_C=94:=94=94, } In the above you can see that only attr_D is removed. attr_A is = untouched. attr_B and C are set to empty string and null respectively = (which means null and empty string are valid values). According to RFC7158, an empty object is valid per the ABNF: object =3D begin-object [ member *( value-separator member ) ] end-object The empty object notation also makes sense for complex attributes since = it signals the entire complex attribute is removed. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 16, 2014, at 5:54 PM, Morteza Ansari (moransar) = wrote: > But the client doesn=92t know it doesn=92t have all the data. =46rom = the client perspective it has the whole object. >=20 > From: Bill Mills > Reply-To: Bill Mills > Date: Friday, May 16, 2014 at 5:14 PM > To: Morteza Ansari , Phil Hunt = , "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values >=20 > I would argue that if you don't have all of the data for a user then = using PUT is wrong and you must use PATCH. >=20 > On Friday, May 16, 2014 5:09 PM, Morteza Ansari (moransar) = wrote: > There are other cases to consider here. If the reader does not have = read access to some attributes, those attributes should not be removed = either. Essentially in our implementation PUT is a special case of = PATCH to handle authorization case and metadata (much like operational = attributes were handled in LDAP).=20 >=20 >=20 > Cheers, > Morteza=20 >=20 > From: Bill Mills > Reply-To: Bill Mills > Date: Friday, May 16, 2014 at 2:21 PM > To: Phil Hunt , "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values >=20 > PUT is a replacement of the entire object, use it carefully.... >=20 > The stuff you do not get to change like the metadata is interesting. = PUT shouldn't overwrite the creation time of the object for example. = Metatdata is where it gets hard, the actual contents are easy. >=20 > On Friday, May 16, 2014 12:36 PM, Phil Hunt = wrote: > I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text. >=20 > Old text: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. Omitting the attribute or specific values = means > the attribute or specific value SHALL be removed; >=20 > I would like to propose this text instead: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. For readWrite attributes, omitting the = attribute=20 > or specific values means the attribute or specific value SHALL=20= > be removed; >=20 > I am not sure if we need to put in text for =93writeOnly=94 = attributes. For passwords you would expect the client to omit password = and you would not expect the existing password value to be removed = (unlike readWrite). However because writeOnly could be attributes other = than passwords (user security questions), I=92m reluctant to specify = what should be done. >=20 > Thoughts? >=20 > If your head is exploding now, don=92t worry, mine is. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_8D1E9355-118C-4C1D-B4C1-B2ACB27A7360 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think implicit delete (absence of a value) is problematic because it = means the SCIM API has to know about the access control system. = This is probably not a good idea.

phil.hunt@oracle.com=

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

What = about an explicit methodology like = this:

Consider example JSON = record:

{

= =93attr_A=94:=94First=94,

= =93attr_B=94:=94Second=94,

= =93attr_C=94:=94Third=94,

= =93attr_D=94:=94Four"

= =93attr_C=94:=94=94,

=93attr_A=94:=94First=94,

= =93attr_B=94:null,

= =93attr_C=94:=94=94,

}

In the = above you can see that only attr_D is removed. attr_A is = untouched. attr_B and C are set to empty string and null = respectively (which means null and empty string are valid = values).

According to RFC7158, an empty object = is valid per the ABNF:

object =3D begin-object [ member *( =
value-separator member ) ]
               end-object

The empty = object notation also makes sense for complex attributes since it signals = the entire complex attribute is removed.

Phil

@independentid

On May 16, 2014, at 5:54 PM, Morteza Ansari (moransar) = <moransar@cisco.com> = wrote:

But the client doesn=92t know it doesn=92t have all the data. = =46rom the client perspective it has the whole object.

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at = 5:14 PM
To: Morteza Ansari <moransar@cisco.com>, Phil Hunt = <phil.hunt@oracle.com>, = "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and = meaning of omitting values

I would argue that if you don't have all of the data for a = user then using PUT is wrong and you must use PATCH.

On Friday, May 16, 2014 = 5:09 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

There are other cases to consider here. If the reader does not have = read access to some attributes, those attributes should not be removed = either. Essentially in our implementation PUT is a special case of = PATCH to handle authorization case and metadata (much like operational attributes were handled in LDAP).

Cheers,

Morteza

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Friday, May 16, 2014 at = 2:21 PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] PUT and = meaning of omitting values

PUT is a replacement of the entire object, use it = carefully....

The stuff you do not get to change like the metadata is = interesting. PUT shouldn't overwrite the creation time of the = object for example. Metatdata is where it gets hard, the actual = contents are easy.

On Friday, May 16, 2014 = 12:36 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to = mind as problematic in the current text.

Old text:

readWrite, = writeOnly Any values provided SHALL replace the existing attribute values. Omitting the attribute or specific values means the attribute or specific value SHALL be removed;

I would like to propose this text instead:

readWrite, = writeOnly Any values provided SHALL replace the existing attribute values. For readWrite attributes, omitting the = attribute

or = specific values means the attribute or specific value SHALL

be = removed;

I am not sure if we need to put in text for =93writeOnly=94 = attributes. For passwords you would expect the client to omit password = and you would not expect the existing password value to be removed = (unlike readWrite). However because writeOnly could be attributes other than passwords (user security questions), I=92m reluctant to = specify what should be done.

Thoughts?

If your head is exploding now, don=92t worry, mine is.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

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

= --Apple-Mail=_8D1E9355-118C-4C1D-B4C1-B2ACB27A7360-- From nobody Fri May 16 21:30: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 52FDB1A005E for ; Fri, 16 May 2014 21:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 O4UILdL-Q2fV for ; Fri, 16 May 2014 21:30:09 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8241A0056 for ; Fri, 16 May 2014 21:30:08 -0700 (PDT) Received: from [98.139.215.142] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 04:30:00 -0000 Received: from [98.139.212.251] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 04:30:00 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 17 May 2014 04:30:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 632762.55330.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 6152 invoked by uid 60001); 17 May 2014 04:30:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400301000; bh=+vlbU2LTlnkXoQqmHoJwUgVHaoU1tWWr2bClUy/JKlQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JbC6+UGJWBlofLxRvDvNeb1bmO3zCwKk57dk1Wsv1zOhGcTz+1b8msGKBkxvg/G8y9WBZxLjWba20NRNt2u7gonwcDR0PMAxUoL2FZ4px6L11dl78unqYdwm9brFjkTJXOrWGOEBulsYFElcDjCyDpYBpCh31P1McaMuPoc+oFg= X-YMail-OSG: DcfhEksVM1nz.RjqUGUF1WD0gobWagG2Jwlw0F1sqcVCCgB usOCe.mwjTKTYqWI5Vd9Q8RxyYE_7oeVi0cLl8sVPsXaH4P64Im54Gv6DcDz tqGnBTK.uCuFBs1icEbQfWtVc6fbPdsHT_Kcd3FoPUVgdlvdD8MLtdxr2r_2 CfDCsjyvCJZjZMtBD9Y8.7IzSomWv3lZN4A.54OiYoA.CWw4ZvnV87b3q.qq rpDP_nzjE5OUqiKKsv_uPCdPyW8VOexNIglE5z0brZfSL0s21Pn2WWxcLNAE HFzLJtq_WbO92N7vKFdCswelOlYZEIwO_3LGiXIDwWLwNc.pa5KE52ZsoQ24 qS2eMN9i7fYH1kW3KLCFtiUN_5GkTYEA8KFEvQ9680XoFgGBcmhRl5jZzbKF bLzV0ZpAjOqizblyzGei5mVuYp13BlLIgeiT4WLRakjUI7n7Ot2V8RpnSEd8 U8zAMHOL8sY272O3Wv25B7BeNDIj7cU6BfFJkROCN8E7mumOr6KMtfNGmwUY wOJPRurXqcKw6zxTFQDOma6ic_JyN4ldS0zRkeLe2..OCxVe9IsMAf13QtHY BsdFpDNEpkRJvY1n9Qq2P373l3.IVj_6.pwsfGJkKVISMmujw_V5ApnRMpjA YZFJOvzeqUh9f9IjzUSANExZuozxoNnnNUWHZETKuQis4zn1WCF02DEmi Received: from [209.131.62.115] by web142806.mail.bf1.yahoo.com via HTTP; Fri, 16 May 2014 21:30:00 PDT X-Rocket-MIMEInfo: 002.001, VGhlIGNsaWVudCAqc2hvdWxkKiBrbm93IHRoZSBzY2hlbWEsIHNvIGl0IGNhbiBrbm93IHdoZXRoZXIgaXQgY2FuIHVzZSBQVVQgb3Igbm90LiDCoElmIHRoZSBzZXJ2ZXIgaGFzIHNjaGVtYSBlbGVtZW50cyBoaWRkZW4gZnJvbSB0aGUgY2xpZW50LCB0aGVuIGl0J3MgdGhlIHNlcnZlcidzIHByb2JsZW0gdG8gc29sdmUuCgpXaGF0IHlvdSd2ZSBnb3QgaGVyZSBpcyBQVVQgZXhjZXB0IHdoZW4gaXQncyBub3QgUFVUIGl0JyBQQVRDSCwgYW5kIFBBVENILiDCoFRoYXQncyBub3QgT0suCgoKT24gRnJpZGF5LCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> Message-ID: <1400301000.2830.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Fri, 16 May 2014 21:30:00 -0700 (PDT) From: Bill Mills To: "Morteza Ansari \(moransar\)" , Phil Hunt , Scim WG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-1478479510-1400301000=:2830" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/d8PEnkM4mrx02-b1iIsfur9udEg Subject: Re: [scim] PUT and meaning of omitting values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 04:30:11 -0000 --515012262-1478479510-1400301000=:2830 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The client *should* know the schema, so it can know whether it can use PUT = or not. =C2=A0If the server has schema elements hidden from the client, the= n it's the server's problem to solve.=0A=0AWhat you've got here is PUT exce= pt when it's not PUT it' PATCH, and PATCH. =C2=A0That's not OK.=0A=0A=0AOn = Friday, May 16, 2014 5:54 PM, Morteza Ansari (moransar) wrote:=0A =0ABut the client doesn=E2=80=99t know it doesn=E2=80=99t have = all the data. =C2=A0From the client perspective it has the whole object.=0A= =0AFrom: Bill Mills =0AReply-To: Bill Mills =0ADate: Friday, May 16, 2014 at 5:14 PM=0ATo: Morteza Ans= ari , Phil Hunt , "scim@ietf.org"= =0ASubject: Re: [scim] PUT and meaning of omitting values= =0A=0A=0AI would argue that if you don't have all of the data for a user th= en using PUT is wrong and you must use PATCH.=0A=0A=0AOn Friday, May 16, 20= 14 5:09 PM, Morteza Ansari (moransar) wrote:=0A=0ATher= e are other cases to consider here. If the reader does not have read access= to some attributes, those attributes should not be removed either. =C2=A0E= ssentially in our implementation PUT is a special case of PATCH to handle a= uthorization case and metadata (much like operational attributes were handl= ed in LDAP).=C2=A0=0A=0A=0ACheers,=0AMorteza=C2=A0=0A =0AFrom: Bill Mills <= wmills_92105@yahoo.com>=0AReply-To: Bill Mills =0AD= ate: Friday, May 16, 2014 at 2:21 PM=0ATo: Phil Hunt = , "scim@ietf.org" =0ASubject: Re: [scim] PUT and meaning of = omitting values=0A=0A=0APUT is a replacement of the entire object, use it c= arefully....=0A=0AThe stuff you do not get to change like the metadata is i= nteresting. =C2=A0PUT shouldn't overwrite the creation time of the object f= or example. =C2=A0Metatdata is where it gets hard, the actual contents are = easy.=0A=0A=0AOn Friday, May 16, 2014 12:36 PM, Phil Hunt wrote:=0A=0AI was just thinking about our PUT rules and was consideri= ng what it means to omit values. =C2=A0Passwords (writeOnly attributes) cam= e to mind as problematic in the current text. =0A=0AOld text:=0AreadWrite, = writeOnly Any values provided SHALL replace the existing attribute values.= Omitting the attribute or specific values means the attribute or specific= value SHALL be removed;=0A=0A =0A =0A =0A =0AI would like to propose this = text instead:=0AreadWrite, writeOnly Any values provided SHALL replace the= existing attribute values. For readWrite attributes, omitting the attribut= e=C2=A0=0Aor specific values means the attribute or specific value SHALL=C2= =A0=0Abe removed;=0A=0AI am not sure if we need to put in text for =E2=80= =9CwriteOnly=E2=80=9D attributes. For passwords you would expect the client= to omit password and you would not expect the existing password value to b= e removed (unlike readWrite). =C2=A0However because writeOnly could be attr= ibutes other than passwords (user security questions), I=E2=80=99m reluctan= t to specify what should be done.=0A=0AThoughts?=0A=0AIf your head is explo= ding now, don=E2=80=99t worry, mine is.=0A=0APhil=0A=0A@independentid=0Awww= .independentid.comphil.hunt@oracle.com=0A=0A=0A=0A_________________________= ______________________=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.ie= tf.org/mailman/listinfo/scim --515012262-1478479510-1400301000=:2830 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The client *should* know the schema, so it can kno= w whether it can use PUT or not. If the server has schema elements hi= dden from the client, then it's the server's problem to solve.

What you've got here is PUT= except when it's not PUT it' PATCH, and PATCH. That's not OK.

O= n Friday, May 16, 2014 5:54 PM, Morteza Ansari (moransar) <moransar@cisc= o.com> wrote:

=0A

But the client doesn=E2=80=99t know it does= n=E2=80=99t have all the data. From the client perspective it has the= whole object.

=0A

=0A=0A

=0AFrom: Bil= l Mills <wmil= ls_92105@yahoo.com>
=0AReply-To: Bill Mills <wmills_92105@yahoo.com>
=0A= Date: Friday, May 16, 2014 at 5:14= PM
=0ATo: Morte= za Ansari <moransar@c= isco.com>, Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <s= cim@ietf.org>
=0ASubject: Re: [scim] PUT and meaning of omitting values
=0A

=0A

I would argue that if you don't = have all of the data for a user then using PUT is wrong and you must use PA= TCH.
=0A
=0A

=0A

On Friday,= May 16, 2014 5:09 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
=0A

=0A

= =0A

=0A

There are other cases to consi= der here. If the reader does not have read access to some attributes, those= attributes should not be removed either. Essentially in our implemen= tation PUT is a special case of PATCH to handle authorization case and meta= data=0A (much like operational attributes were handled in LDAP). =0A

=0A

= =0A

Cheers,

=0A

Morteza

=0A

= =0A

=0A=0A

=0A

=0AFrom: Bill Mills <wmills_92105@yahoo.com>
=0AReply-To: Bill Mills <wmills_92105@yahoo.co= m>
=0ADate: Friday, May 16, 2014 at 2:21 PM
=0ATo: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org"=0A <scim@ietf.org>
=0ASubject: Re: [scim] PUT and meaning of omitting values=0A

=0A

=0A=0A

=0A

PUT is a replacement o= f the entire object, use it carefully....

=0A

=0A
=0A

= =0A

=0AThe stuff you do= not get to change like the metadata is interesting. PUT shouldn't ov= erwrite the creation time of the object for example. Metatdata is whe= re it gets hard, the actual contents are easy.
=0A
=0A

=0A

= =0A

=0A

On Friday, May 16, 2014 12:36 PM, Phil Hunt &= lt;phil.hunt@oracle.= com> wrote:
=0A

=0A

I was just th= inking about our PUT rules and was considering what it means to omit values= . Passwords (writeOnly attributes) came to mind as problematic in the= current text.=0A

=0A

Old text:

= =0A

=0A

readWrite, writeOnly  Any values provided SHA=
LL replace the existing=0A      attribute values.  Omitting the attribute o=
r specific values means=0A      the attribute or specific value SHALL be re=
moved;

=0A

=0A=0A

=0A

= =0A

=0A

I would like to propose this text instead:

=0A=0A

readWrite, writeOnly  Any values provided SHALL re=
place the existing=0A      attribute values. For readWrite attributes, omit=
ting the attribute

=0A

      or specific valu=
es means the attribute or specific value SHALL

=0A

      be removed;

=0A

= =0A

I am not sure if we need to put in text for =E2=80=9CwriteOnly=E2= =80=9D attributes. For passwords you would expect the client to omit passwo= rd and you would not expect the existing password value to be removed (unli= ke readWrite). However because writeOnly could be attributes=0A other= than passwords (user security questions), I=E2=80=99m reluctant to specify= what should be done.

=0A

Thou= ghts?

=0A

If your head is expl= oding now, don=E2=80=99t worry, mine is.

=0A

= =0A

=0A

Phil

=0A

@ind= ependentid

=0A

https://github.com/osiam/server/wiki/detailed_reference_installation=

=0A=

=0Aphil.hunt@o= racle.com

=0A

=0A
=0A

=0A<= br clear=3D"none">=0A

=0A

=0A
=0A_____= __________________________________________
=0Ascim mailin= g list
=0Ascim@i= etf.org
=0Ahttps://www= .ietf.org/mailman/listinfo/scim
=0A
=0A
=0A

=0A

=0A=0A

=0A

=0A
=0A
=0A

=0A

=0A=0A

--515012262-1478479510-1400301000=:2830-- From nobody Mon May 19 09:20: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 427A61A038B for ; Mon, 19 May 2014 09:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usz7nMlSrB3L for ; Mon, 19 May 2014 09:20:15 -0700 (PDT) Received: from mail-pb0-f69.google.com (mail-pb0-f69.google.com [209.85.160.69]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B6D1A038C for ; Mon, 19 May 2014 09:20:13 -0700 (PDT) Received: by mail-pb0-f69.google.com with SMTP id uo5so32262698pbc.0 for ; Mon, 19 May 2014 09:20:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6bRxVuHBS4Wh039CkhssmskDxX/IUPdtxKXbsPCVJFo=; b=inbtYNs0+sqcoctzTsBp9fs8vD+z7wlwvmXViXLv7DhgQxEL57Aqf5SUebnya8kdQj uVahv048CvX7pC86x01L1UoS/+T07B6IVqkKL+375X4b+BOXu9vUivsbQRiveBNO34hD Jrau9vgnYfI9rPIxetmKP4aS5jG/h08OcWBYMY2A7LoagEOBLYD2wfmJEUnuXox2poIc ASYDf/er+dJCg69ELari1lJjCtWFo6eMyKNFD8mic7e/oOfaviZ5NLWG51c4a63pgx2v fmM3AxSr8iY7dAaHAxvSSOGgwurhC9VFLCGznHDx8Kb4bzJxb0ccECrmZ4SF1gYgWGKW Fqdw== X-Gm-Message-State: ALoCoQkqZ8GcKeQxSarsl8t3DRug/l2p4sEnMjrcJgkvRSyhmPlU8rcsd5h1dYH49h91iFVcU0qm MIME-Version: 1.0 X-Received: by 10.68.220.103 with SMTP id pv7mr44623669pbc.17.1400516412860; Mon, 19 May 2014 09:20:12 -0700 (PDT) Received: by 10.66.67.41 with HTTP; Mon, 19 May 2014 09:20:12 -0700 (PDT) Date: Mon, 19 May 2014 18:20:12 +0200 Message-ID: From: David Moebius To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff253784a833f04f9c32344 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Mo8Nq7Hf6mEK_Bu9WMd7CB6vN2c Subject: [scim] Release 1.0 of the SCIM 2.0 implementation OSIAM 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, 19 May 2014 16:20:20 -0000 --e89a8ff253784a833f04f9c32344 Content-Type: text/plain; charset=UTF-8 Hello, thanks also to your help, we finally released the version 1.0 of the SCIM 2.0 based user identity management OSIAM. We would like to invite all of you to checkout the release and play around with OSIAM. Some facts of OSIAM: - Published under the open source MIT license - OSIAM is oauth2 secured and REST based user management and user authentication project - OSIAM is based on SCIM 2.0 with the basic concept (Users and Groups) - The scim-schema (https://github.com/osiam/scim-schema) is a fully Java implementation of SCIM 2.0 and can be used standalone (without OSIAM) -- Release: http://search.maven.org/#artifactdetails|org.osiam|scim-schema|1.0|jar - The core of OSIAM is the REST based auth and resource server - We created a connector to abstract the OSIAM REST interfaces as a Java API - We also implemented the addon self-administration, for user registration, reset password and email address management, written in Java -- It's also an abstraction with it's web interfaces, which can be highly customized You can find OSIAM at www.osiam.org and at https://github.com/osiam. If you like to install OSIAM, please have a look at https://github.com/osiam/server/wiki/detailed_reference_installation If you have any question don't hesitate to contact us. Regards, The OSIAM Team -- David Moebius Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-144 Telefax +49 (0) 30 56829495 d.moebius@tarent.de --e89a8ff253784a833f04f9c32344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

thanks also to your help, we finally released the version 1.0 of

the S= CIM 2.0 based user identity management OSIAM. We would like to

invite all of you to checkout the release and play around with OSIAM.

Some facts of OSIAM:

- Published under the open source MIT l= icense

= - OSIAM is oauth2 secured and REST based user management and user authentic= ation project

- OSIAM is based on SCIM 2.0 with the basic concept (Users and Groups)

- The scim-schema (https://github.com/osiam/scim-schema) is a fully Java imple= mentation of SCIM 2.0 and can be used standalone (without OSIAM)

= -- Release:=C2=A0http://search.maven.org/= #artifactdetails|org.osiam|scim-schema|1.0|jar

= - The core of OSIAM is the REST based auth and resource server

- We cr= eated a connector to abstract the OSIAM REST interfaces as a Java API

= - We also implemented the addon self-administration, for user registration,= reset password and email address management, written in Java

-- It's also an abstraction with it's web interfaces, which can be = highly customized

You can find OSIAM at=C2=A0www.osiam.org=C2=A0and at=C2=A0https://github.com/osiam. If

you like to install OSIAM, please have a look at

If you have any question don't hesitate to contact us.

<= div style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">

Regards,

The OSIAM Team

--=C2=A0

David Moebius

Softwar= eentwicklung

tarent solutions GmbH

Telef= on +49 (0) 30 138803-144

Telefax +49 (0) 30 56829495

d.moebius@tarent.de

--e89a8ff253784a833f04f9c32344-- From nobody Tue May 20 12:01:13 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 2C9381A06F1 for ; Tue, 20 May 2014 12:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 SVkz03KELZEh for ; Tue, 20 May 2014 12:01:09 -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 AF8CE1A074D for ; Tue, 20 May 2014 12:00:55 -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 s4KJ0rUv010700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 May 2014 19:00:54 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4KJ0qYx006138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 19:00:53 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4KJ0q4p012307; Tue, 20 May 2014 19:00:52 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 May 2014 12:00:52 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_099FDC7A-340F-47D3-AEAB-7D02E351CDE8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <1400301000.2830.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Tue, 20 May 2014 12:00:50 -0700 Message-Id: <77301A00-E928-401E-AA36-17E0F0674FE6@oracle.com> References: <1400275317.35055.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1400285651.45571.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1400301000.2830.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1gixBJjYXpCdQ3s73W7EI0M2RgQ Cc: Scim WG , Morteza Ansari Subject: Re: [scim] PUT and meaning of omitting values 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, 20 May 2014 19:01:12 -0000 --Apple-Mail=_099FDC7A-340F-47D3-AEAB-7D02E351CDE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thinking about this some more, there are many reasons why an attribute = may be missing: A. There is no current value - server should ignore -OR- B. There is no value - an implied delete as the client intended the new = record to replace the old.=20 C. The client can't get or set the attribute due to access control D. The client was built on an older version of the schema and doesn=92t = know about it E. The client never requested the value on GET. There is a problem here that there is a dramatic difference between a = true document-centric API where replacing an HTML file or a JPG is what = is intended. In SCIM, we have an attribute-centric API where individual attributes = have different metadata (mutability, required) associated. To assume = that a PUT is a simple swap and that missing attribute implies delete is = dangerous due to the above (A thru E). So where normally a client might only send: { =93attr_A=94:=94First=94, =93attr_B=94:=94Second=94, } Which leaves the server to wonder: What about =93attr_C=94 and = =93attr_D=94? In the new model. The above transaction would leave =93attr_C=94 and = attr_D=94 untouched. If the client=92s intent is to actually remove or wipe out those = attributes, they could simply specify all attributes they want to set = (for example, use null):=20 { =93attr_A=94:=94First=94, =93attr_B=94:=94Second=94, =93attr_C=94:null, =93attr_D=94:null } =46rom a Java platform perspective, this seems more bean friendly since = you are telling the beans to just serialize all values regardless of = whether a value has been set. No complex logic required for remembering = what was modified, etc. I can=92t comment on the .Net stuff. But I can = only guess there are parallel issues. Here is some proposed new text (revised text in bold/blue): PUT performs a full update. Clients MAY retrieve the entire resource in advance, add the desired modifications and use HTTP PUT which will overwrite all previously stored data. Since the PUT request performs a full update, clients MAY send attributes of the retrieved resource and the service provider MUST process according to attribute mutability as follows: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. For multi-valued attributes, all values SHALL be replaced. immutable If values are provided for elements already set in the attribute they MUST match existing data or an error is returned. If the service provider has no existing values, a new value(s) MAY be specified; and, readOnly Any values provided (e.g. meta.resourceType) SHALL be ignored. If an attribute is "required", the client MUST specify the attribute in the PUT request. If a client would like to remove all values of an attribute, the = client MAY set the attribute to the value =93null=94. In setting values to = =93null=94 the client MUST conform to the above mutability rules. If an attribute is unspecified by the client, the server SHOULD leave any existing values for the attribute unchanged. If a value provided for an immutable attribute with an existing value is NOT matched, the server SHALL respond with an HTTP response code of 400 and an appropriate human readable message indicating an attempt to change an immutable attribute. ... IMPORTANT: The text above does significantly change the meaning of = attribute omission and thus is *breaking*. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 16, 2014, at 9:30 PM, Bill Mills wrote: > The client *should* know the schema, so it can know whether it can use = PUT or not. If the server has schema elements hidden from the client, = then it's the server's problem to solve. >=20 > What you've got here is PUT except when it's not PUT it' PATCH, and = PATCH. That's not OK. >=20 > On Friday, May 16, 2014 5:54 PM, Morteza Ansari (moransar) = wrote: > But the client doesn=92t know it doesn=92t have all the data. =46rom = the client perspective it has the whole object. >=20 > From: Bill Mills > Reply-To: Bill Mills > Date: Friday, May 16, 2014 at 5:14 PM > To: Morteza Ansari , Phil Hunt = , "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values >=20 > I would argue that if you don't have all of the data for a user then = using PUT is wrong and you must use PATCH. >=20 > On Friday, May 16, 2014 5:09 PM, Morteza Ansari (moransar) = wrote: > There are other cases to consider here. If the reader does not have = read access to some attributes, those attributes should not be removed = either. Essentially in our implementation PUT is a special case of = PATCH to handle authorization case and metadata (much like operational = attributes were handled in LDAP).=20 >=20 >=20 > Cheers, > Morteza=20 >=20 > From: Bill Mills > Reply-To: Bill Mills > Date: Friday, May 16, 2014 at 2:21 PM > To: Phil Hunt , "scim@ietf.org" > Subject: Re: [scim] PUT and meaning of omitting values >=20 > PUT is a replacement of the entire object, use it carefully.... >=20 > The stuff you do not get to change like the metadata is interesting. = PUT shouldn't overwrite the creation time of the object for example. = Metatdata is where it gets hard, the actual contents are easy. >=20 > On Friday, May 16, 2014 12:36 PM, Phil Hunt = wrote: > I was just thinking about our PUT rules and was considering what it = means to omit values. Passwords (writeOnly attributes) came to mind as = problematic in the current text. >=20 > Old text: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. Omitting the attribute or specific values = means > the attribute or specific value SHALL be removed; >=20 > I would like to propose this text instead: > readWrite, writeOnly Any values provided SHALL replace the existing > attribute values. For readWrite attributes, omitting the = attribute=20 > or specific values means the attribute or specific value SHALL=20= > be removed; >=20 > I am not sure if we need to put in text for =93writeOnly=94 = attributes. For passwords you would expect the client to omit password = and you would not expect the existing password value to be removed = (unlike readWrite). However because writeOnly could be attributes other = than passwords (user security questions), I=92m reluctant to specify = what should be done. >=20 > Thoughts? >=20 > If your head is exploding now, don=92t worry, mine is. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_099FDC7A-340F-47D3-AEAB-7D02E351CDE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thinking about this some more, there are many = reasons why an attribute may be missing:

A. There is no current = value - server should ignore

-OR-

B. There is no = value - an implied delete as the client intended the new record to = replace the old.

C. The client can't get or set the = attribute due to access control

D. The client was built on an = older version of the schema and doesn=92t know about it

E. The = client never requested the value on GET.

There = is a problem here that there is a dramatic difference between a true = document-centric API where replacing an HTML file or a JPG is what is = intended.

In SCIM, we have an attribute-centric = API where individual attributes have different metadata (mutability, = required) associated. To assume that a PUT is a simple swap and that = missing attribute implies delete is dangerous due to the above (A thru = E).

So where normally a client might only = send:

{
=93attr_A=94:=94First=94,
= =93attr_B=94:=94Second=94,
}

Which leaves the server to = wonder: What about =93attr_C=94 and = =93attr_D=94?

In the new model. The above = transaction would leave =93attr_C=94 and attr_D=94 = untouched.

If the client=92s intent is to = actually remove or wipe out those attributes, they could simply specify = all attributes they want to set (for example, use = null):

{
=93attr_A=94:=94First=94,
= =93attr_B=94:=94Second=94,
=93attr_C=94:null,
= =93attr_D=94:null
}

=46rom a Java platform = perspective, this seems more bean friendly since you are telling the = beans to just serialize all values regardless of whether a value has = been set. No complex logic required for remembering what was modified, = etc. I can=92t comment on the .Net stuff. But I can only guess there are = parallel issues.

Here is some proposed new text = (revised text in bold/blue):

   PUT performs a full update.  Clients MAY =
retrieve the entire resource
   in advance, add the desired modifications and use HTTP PUT which will
   overwrite all previously stored data.  Since the PUT request performs
   a full update, clients MAY send attributes of the retrieved resource
   and the service provider MUST process according to attribute
   mutability as follows:

   readWrite, writeOnly  =
Any values provided SHALL replace the existing
      attribute values. For multi-valued =
attributes, all values SHALL

      be =
replaced.

   immutable  If values are provided for elements already set in the
      attribute they MUST match existing data or an error is returned.
      If the service provider has no existing values, a new value(s) MAY
      be specified; and,

   readOnly  Any values provided (e.g.  meta.resourceType) SHALL be
      ignored.

   If an attribute is "required", the client MUST specify the attribute
   in the PUT request.

   If a client would like to remove all =
values of an attribute, the client

   MAY set the =
attribute to the value =93null=94. In setting values to =
=93null=94

   the client MUST conform to the =
above mutability rules.

   If an =
attribute is unspecified by the client, the server SHOULD =
leave

   any existing values for the =
attribute unchanged.

   If a value provided for an immutable =
attribute with an existing value
   is NOT matched, the server SHALL respond with an HTTP response code
   of 400 and an appropriate human readable message indicating an
   attempt to change an immutable attribute.

  =
...

IMPORTANT: The text above does = significantly change the meaning of attribute omission and thus is = *breaking*.

Phil

@independentid