From nobody Thu Sep 1 10:28:15 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F167F12D1EA; Thu, 1 Sep 2016 10:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 q8wMo7E5-WEd; Thu, 1 Sep 2016 10:28:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A1912D1E7; Thu, 1 Sep 2016 10:28:08 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u81HS70j010155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Sep 2016 17:28:07 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u81HS61V017256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Sep 2016 17:28:06 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u81HS55n020300; Thu, 1 Sep 2016 17:28:06 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Sep 2016 10:28:05 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_3778A97A-3139-44A8-8D60-4274D23D807B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt Date: Thu, 1 Sep 2016 10:28:03 -0700 Message-Id: <2782FF7C-DE82-478D-97A0-F8CB29B51B60@oracle.com> References: <147275055023.32079.13898052231663585667.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org WG" , "openid-specs-ab@lists.openid.net Ab" , openid-specs-risc@lists.openid.net Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-04.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 17:28:11 -0000 --Apple-Mail=_3778A97A-3139-44A8-8D60-4274D23D807B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Based on input this week, I have posted draft 04. Highlights include: o Re-added the "sub" claim with clarifications that any SET type may use it. o Added additional clarification on the use of envelope vs. paylaod attributes o Added security consideration for event timing. o Switched use of "attribute" to "claim" for consistency. o Revised examples to put "sub" claim back in the top level. o Added clarification that SETs typically do not use "exp". o Added security consideration for distinguishing Access Tokens and SETs. Thanks for the great reviews. I think we are getting close to consensus = on this. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-04.txt > Date: September 1, 2016 at 10:22:30 AM PDT > To: "William Denniss" , "Phil Hunt" = , , "Michael B. Jones" = , "Morteza Ansari" , = "Michael Jones" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-04.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 04 > Title: Security Event Token (SET) > Document date: 2016-09-01 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-04.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-04 >=20 > Abstract: > This specification defines the Security Event token, which may be > distributed via a protocol such as HTTP. The Security Event Token > (SET) specification profiles the JSON Web Token (JWT) and may be > optionally signed and/or encrypted. A SET describes a statement of > fact that may be shared by an event publisher with event = subscribers. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_3778A97A-3139-44A8-8D60-4274D23D807B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Based on input this week, I have posted draft 04.

Highlights = include:
  =  o  Re-added the "sub" claim with clarifications that any SET = type may
      use = it.
   o  Added = additional clarification on the use of envelope vs. paylaod
      attributes
   o  Added security consideration = for event timing.
   = o  Switched use of "attribute" to "claim" for = consistency.
   = o  Revised examples to put "sub" claim back in the top = level.
   o  Added = clarification that SETs typically do not use "exp".
   o  Added security consideration = for distinguishing Access Tokens and
      SETs.

Thanks for the great reviews. I think = we are getting close to consensus on this.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-04.txt
Date: = September 1, 2016 at 10:22:30 = AM PDT
To: = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, <none-chairs@ietf.org>, "Michael B. Jones" <mbj@microsoft.com>, = "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-04.txt
has been successfully submitted by Phil Hunt and posted to = the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: 04
Title:= = Security Event Token (SET)
Document date: = 2016-09-01
Group: Individual Submission
Pages:= = 17
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 4.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-04
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-04=

Abstract:
=   This specification defines the Security Event token, which = may be
  distributed via a protocol such as = HTTP.  The Security Event Token
  (SET) = specification profiles the JSON Web Token (JWT) and may be
=   optionally signed and/or encrypted.  A SET describes a = statement of
  fact that may be shared by an = event publisher with event subscribers.




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.

The IETF Secretariat


= --Apple-Mail=_3778A97A-3139-44A8-8D60-4274D23D807B-- From nobody Fri Sep 2 14:59:40 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C103F12D13F; Fri, 2 Sep 2016 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lSUw1P0Rkqz4; Fri, 2 Sep 2016 14:59:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C3612D0F8; Fri, 2 Sep 2016 14:59:36 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u82LxZqc029101 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2016 21:59:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u82LxZlI023989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2016 21:59:35 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u82LxY0p026872; Fri, 2 Sep 2016 21:59:34 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Sep 2016 14:59:33 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_128B70C0-73C0-4167-B3A1-09BFD11C3A16" Message-Id: <5BFD60C3-92FE-46BA-AE90-A4546A98E786@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Fri, 2 Sep 2016 14:59:32 -0700 References: <147285344389.24829.9566046591438611371.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" , "scim@ietf.org WG" Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-05.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:59:39 -0000 --Apple-Mail=_128B70C0-73C0-4167-B3A1-09BFD11C3A16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is just a quick update. Apparently when getting rid of the term = =E2=80=9Cattribute=E2=80=9D for =E2=80=9Cclaim=E2=80=9D, my search and = replace had a =E2=80=9Cc=E2=80=9D tacked on the end resulting in a = number of erroneous =E2=80=9Cclaimc=E2=80=9Ds instead of =E2=80=9Cclaim=E2= =80=9D or =E2=80=9Cclaims=E2=80=9D throughout the document. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-05.txt > Date: September 2, 2016 at 2:57:23 PM PDT > To: "William Denniss" , "Phil Hunt" = , , "Michael B. Jones" = , "Morteza Ansari" , = "Michael Jones" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-05.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 05 > Title: Security Event Token (SET) > Document date: 2016-09-02 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-05.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-05 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-05 >=20 > Abstract: > This specification defines the Security Event token, which may be > distributed via a protocol such as HTTP. The Security Event Token > (SET) specification profiles the JSON Web Token (JWT) and may be > optionally signed and/or encrypted. A SET describes a statement of > fact that may be shared by an event publisher with event = subscribers. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_128B70C0-73C0-4167-B3A1-09BFD11C3A16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is just a quick update. Apparently when getting rid of = the term =E2=80=9Cattribute=E2=80=9D for =E2=80=9Cclaim=E2=80=9D, my = search and replace had a =E2=80=9Cc=E2=80=9D tacked on the end resulting = in a number of erroneous =E2=80=9Cclaimc=E2=80=9Ds instead of = =E2=80=9Cclaim=E2=80=9D or =E2=80=9Cclaims=E2=80=9D throughout the = document.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-05.txt
Date: = September 2, 2016 at 2:57:23 PM = PDT
To: = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, <none-chairs@ietf.org>, "Michael B. Jones" <mbj@microsoft.com>, = "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-05.txt
has been successfully submitted by Phil Hunt and posted to = the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: 05
Title:= = Security Event Token (SET)
Document date: = 2016-09-02
Group: Individual Submission
Pages:= = 17
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 5.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-05
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-05=

Abstract:
=   This specification defines the Security Event token, which = may be
  distributed via a protocol such as = HTTP.  The Security Event Token
  (SET) = specification profiles the JSON Web Token (JWT) and may be
=   optionally signed and/or encrypted.  A SET describes a = statement of
  fact that may be shared by an = event publisher with event subscribers.




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.

The IETF Secretariat


= --Apple-Mail=_128B70C0-73C0-4167-B3A1-09BFD11C3A16-- From nobody Thu Sep 8 12:17:50 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E512B053 for ; Thu, 8 Sep 2016 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=okta.com header.b=C65gG4wq; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=oktainc.onmicrosoft.com header.b=ZFz7XV6Y 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 KwBG6LwZrdYl for ; Thu, 8 Sep 2016 12:17:47 -0700 (PDT) Received: from us-smtp-delivery-163.mimecast.com (us-smtp-delivery-163.mimecast.com [63.128.21.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D4E120727 for ; Thu, 8 Sep 2016 12:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=mimecast20140813; t=1473362265; bh=8f75StZDwzxPJiAObpCiL39gLN8C4td15KFiLTtYwyU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=C65gG4wqoduumbBZO7xiF8iUhqyG2+WrNnXO8jtfwHEITtP0i8EX6BLQIpjSDXE2IlBe+3j8hwVNJirzX3AXYdiH7M35DtNudjgKN17DV7Lv8q7AXkpGrG2xd0iYFxmxehaDVAjkdPWzYU97cV1+iLdc661aWS7L6Jxa6zC12lo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oktainc.onmicrosoft.com; s=selector1-okta-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K4wVpxEnMQ3B1oCWSsSd33WEGL64ggrKpsxYM99Bp48=; b=ZFz7XV6YVRWCLM9nDaA1wPHQyJyK9zR7SEFN9UhTXgKSRa9H7VHUpHWVyrQIG8cNp0V1uaKTx2ByIMGxmkAQMzkpZvVsRmKtgJGzr4DNrjx2qwTMVX2bg3dZa4LshK3Ekx1ga2D1OW2os0eyYczwvFME3hS1D23QskaFXDgcmU4= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0182.outbound.protection.outlook.com [216.32.181.182]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-122-2D1MzDCDMP-tYA4ePQQw2g-1; Thu, 08 Sep 2016 15:17:40 -0400 Received: from CY1PR0501MB1804.namprd05.prod.outlook.com (10.163.141.142) by CY1PR0501MB1803.namprd05.prod.outlook.com (10.163.141.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Thu, 8 Sep 2016 19:17:38 +0000 Received: from CY1PR0501MB1804.namprd05.prod.outlook.com ([10.163.141.142]) by CY1PR0501MB1804.namprd05.prod.outlook.com ([10.163.141.142]) with mapi id 15.01.0609.016; Thu, 8 Sep 2016 19:17:38 +0000 From: Kevin Gough To: "scim@ietf.org" Thread-Topic: =?Windows-1252?Q?Update_on_Okta=92s_SCIM_promotional_activities_&_invitat?= =?Windows-1252?Q?ion_for_collaboration?= Thread-Index: AQHSCgVdaWXn1ecynU230C/DdIUidw== Date: Thu, 8 Sep 2016 19:17:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.245.59.117] x-ms-office365-filtering-correlation-id: e41ad66d-d070-4c6e-973d-08d3d81ccc0b x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1803; 20:Vzn0pcACl++MsXt8MuGWvZPGhzps9qE5F6mxw/j3RiUdw7CLRdzX4COlOpObL4wmS7TiTWw5VHhBd6ZOnYKXsjQTcrkaVCqiE+pxxgJCEwYj7Sx73yyda/6cTzcD0bEsNUE/TCEhs6M/3NlmajeEmOaWElNxHB19CoFEl4fIGnQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1803; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100576887044181)(179546880041079)(28103392795679)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1803; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1803; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(8936002)(81156014)(81166006)(229853001)(10400500002)(68736007)(76576001)(450100001)(7066003)(3280700002)(1730700003)(66066001)(2501003)(122556002)(189998001)(19580395003)(19627405001)(2351001)(9686002)(11100500001)(19617315012)(7846002)(5002640100001)(5640700001)(7736002)(2906002)(3846002)(19625215002)(101416001)(102836003)(87936001)(33656002)(16236675004)(586003)(6116002)(54356999)(99286002)(50986999)(3660700001)(7696003)(105586002)(7906003)(106116001)(15975445007)(97736004)(77096005)(92566002)(5660300001)(106356001)(107886002)(110136002)(74316002)(86362001)(2900100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1803; H:CY1PR0501MB1804.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: okta.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2016 19:17:38.1095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f1f9fcc4-c616-4261-8a82-855dc9cb8486 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1803 X-MC-Unique: 2D1MzDCDMP-tYA4ePQQw2g-1 Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB18041D3EF141A03BA64EFD9A87FB0CY1PR0501MB1804_" Archived-At: Subject: [scim] =?windows-1252?q?Update_on_Okta=92s_SCIM_promotional_activ?= =?windows-1252?q?ities_=26_invitation_for_collaboration?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 19:17:49 -0000 --_000_CY1PR0501MB18041D3EF141A03BA64EFD9A87FB0CY1PR0501MB1804_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Over the last 6 months, Okta=92s significantly increased it=92s investment = in promoting the SCIM standard to ISVs looking to enable provisioning via a= n IdP for their apps. We=92ve consolidated our efforts into a SCIM provisioning developer program= , which in= cludes a free hands-on implementation workshop run by our training team, an automated tes= t suite that runs on Runscope, dedicated developer support, and Okta & beta= customer validation testing. So far, we=92ve had 50 ISVs join the program. At our Oktane user conference= last week, we announced that = Envoy, PingBoard, VividCortex, and Lucid Software= had graduated from the program with successful SCIM implementations.= As part of Oktane, we also briefed analysts, including Gartner, Forrester,= and Ovum, on our support for SCIM and progress to date. While we=92re generating some initial momentum, it seems we need to press h= arder to ensure this standard sticks and adoption grows. Gregg Kreizman from Gartner seemed almost surprised to hear that we had 50 = ISVs in our program. And one of our recent program applicants stated that t= he http://www.simplecloud.info/ site seemed bare bones, and wondered if the= standard was really still alive. My questions: 1) How are others currently promoting the standard? 2) Who in this consortium is interested in investing in a more collaborativ= e promotion of the standard, be it joint workshops, articles on devsites, m= ore documentation / code samples, case studies, etc.? Feel free to reply to all or reach out to me directly with ideas or to sign= al interest. Thanks. - Kevin Director, Product Marketing Okta --_000_CY1PR0501MB18041D3EF141A03BA64EFD9A87FB0CY1PR0501MB1804_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Over the last 6= months, Okta=92s significantly increased it=92s investment in promoting th= e SCIM standard to ISVs looking to enable provisioning via an IdP for their= apps.

We=92ve consoli= dated our efforts into a SCIM provisioning developer program, which includes a free hands-on imp= lementation workshop run by our training team, an automated test suite = that runs on Runscope, dedicated developer support, and Okta & beta&nbs= p;customer validation testing. 

So far, we=92ve= had 50 ISVs join the program. At our Oktane user conference last week= , we announced that Envoy, PingBoard, VividCortex, and Lucid Software had graduated from the program with successful SCIM impl= ementations. As part of Oktane, we also briefed analysts, including Gartner= , Forrester, and Ovum, on our support for SCIM and progress to date.&n= bsp;

While we=92re g= enerating some initial momentum, it seems we need to press harder to ensure= this standard sticks and adoption grows.

Gregg Kreizman = from Gartner seemed almost surprised to hear that we had 50 ISVs in our pro= gram. And one of our recent program applicants stated that the http://www.simplecloud.info/ site seemed bare bones, and won= dered if the standard was really still alive.


My questions:&n= bsp;
1) How are othe= rs currently promoting the standard? 

2) Who in this = consortium is interested in investing in a more collaborative promotion of = the standard, be it joint workshops, articles on devsites, more documentati= on / code samples, case studies, etc.?

Feel free to re= ply to all or reach out to me directly with ideas or to signal interest.
Thanks.

- Kevin 

Director, Product Marketing

Okta

--_000_CY1PR0501MB18041D3EF141A03BA64EFD9A87FB0CY1PR0501MB1804_-- From nobody Thu Sep 8 13:10:04 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260D12B240 for ; Thu, 8 Sep 2016 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3GJFsy38m9_b for ; Thu, 8 Sep 2016 13:09:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1954212B04B for ; Thu, 8 Sep 2016 13:09:52 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u88K9oG3021630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Sep 2016 20:09:51 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u88K9okg003644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Sep 2016 20:09:50 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u88K9na1004309; Thu, 8 Sep 2016 20:09:50 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2016 13:09:49 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_388B35B9-D85D-4427-B693-F337AEF28E7E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 8 Sep 2016 13:09:48 -0700 Message-Id: <399A0ECA-684A-4D89-9A9B-ECFD194F2249@oracle.com> References: To: Kevin Gough X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] =?utf-8?q?Update_on_Okta=E2=80=99s_SCIM_promotional_activi?= =?utf-8?q?ties_=26_invitation_for_collaboration?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 20:10:01 -0000 --Apple-Mail=_388B35B9-D85D-4427-B693-F337AEF28E7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 SCIM and simplecloud.info is very much alive. On my side, Oracle just = announced IDCS which is SCIM based in its entirety. Agree the SimpleCloud.info site could use some updating. Do we have a = contact email for simplecloud? Might be a better place update info to a = single contact rather than on this list which should be about new = extension discussions and/or errata regarding RFC7643/7644. One of the issues with IETF is they don=92t do much in the way of = promotion or certification. There has been some discussion about = possibly getting a certification program started at OIDF (though it = hasn=92t gone far yet) where we recently posted a draft for enabling = SCIM as a CRUD capable UserInfo endpoint for Connect. Might I also suggest a meeting up at the next IIW? We can discuss next = steps and futures there. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 8, 2016, at 12:17 PM, Kevin Gough wrote: >=20 > Over the last 6 months, Okta=92s significantly increased it=92s = investment in promoting the SCIM standard to ISVs looking to enable = provisioning via an IdP for their apps. >=20 > We=92ve consolidated our efforts into a SCIM provisioning developer = program = , which = includes a free hands-onimplementation workshop = run by our = training team, an automated test suite that runs on Runscope, dedicated = developer support, and Okta & beta customer validation testing.=20 >=20 > So far, we=92ve had 50 ISVs join the program. At our Oktane user = conference last week, we announced = that Envoy = , PingBoard, VividCortex, and Lucid Software = had graduated from the program with successful SCIM = implementations. As part of Oktane, we also briefed analysts, including = Gartner, Forrester, and Ovum, on our support for SCIM and progress to = date.=20 >=20 > While we=92re generating some initial momentum, it seems we need to = press harder to ensure this standard sticks and adoption grows. >=20 > Gregg Kreizman from Gartner seemed almost surprised to hear that we = had 50 ISVs in our program. And one of our recent program applicants = stated that the http://www.simplecloud.info/ = site seemed bare bones, and wondered if = the standard was really still alive. >=20 >=20 > My questions: =20 > 1) How are others currently promoting the standard?=20 >=20 > 2) Who in this consortium is interested in investing in a more = collaborative promotion of the standard, be it joint workshops, articles = on devsites, more documentation / code samples, case studies, etc.? >=20 > Feel free to reply to all or reach out to me directly with ideas or to = signal interest. > Thanks. >=20 > - Kevin=20 >=20 > Director, Product Marketing > Okta > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = --Apple-Mail=_388B35B9-D85D-4427-B693-F337AEF28E7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 SCIM and simplecloud.info is very much alive.  On my side, = Oracle just announced IDCS which is SCIM based in its entirety.

Agree the SimpleCloud.info site = could use some updating.  Do we have a contact email for = simplecloud?  Might be a better place update info to a single = contact rather than on this list which should be about new extension = discussions and/or errata regarding RFC7643/7644.
One of the issues with IETF is they = don=92t do much in the way of promotion or certification. There has been = some discussion about possibly getting a certification program started = at OIDF (though it hasn=92t gone far yet) where we recently posted a = draft for enabling SCIM as a CRUD capable UserInfo endpoint for = Connect.

Might = I also suggest a meeting up at the next IIW?  We can discuss next = steps and futures there.




On Sep 8, 2016, at 12:17 PM, Kevin Gough <kevin.gough@okta.com> wrote:

Over the last 6 months, Okta=92s significantly = increased it=92s investment in promoting the SCIM standard to ISVs = looking to enable provisioning via an IdP for their apps.

We=92ve consolidated our efforts into a SCIM provisioning developer program, which includes a = free hands-onimplementation workshop run by our training team, = an automated test suite that runs on Runscope, dedicated developer = support, and Okta & beta customer validation = testing. 

So = far, we=92ve had 50 ISVs join the program. At our Oktane user = conference last week, we = announced that Envoy, PingBoard, = VividCortex, and Lucid Software had graduated from the = program with successful SCIM implementations. As part of Oktane, we also = briefed analysts, including Gartner, Forrester, and Ovum, on our = support for SCIM and progress to date. 

While we=92re generating some initial momentum, it = seems we need to press harder to ensure this standard sticks and = adoption grows.

Gregg= Kreizman from Gartner seemed almost surprised to hear that we had 50 = ISVs in our program. And one of our recent program applicants stated = that the http://www.simplecloud.info/ site = seemed bare bones, and wondered if the standard was really = still alive.


My = questions:  
1) = How are others currently promoting the standard? 

2) Who in this consortium is interested in investing = in a more collaborative promotion of the standard, be it joint = workshops, articles on devsites, more documentation / code samples, case = studies, etc.?

Feel = free to reply to all or reach out to me directly with ideas or to signal = interest.
Thanks.

- = Kevin 

Director, Product Marketing
Okta
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_388B35B9-D85D-4427-B693-F337AEF28E7E-- From nobody Fri Sep 9 19:36:44 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0312B2D7 for ; Fri, 9 Sep 2016 19:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EHPafK71Ns9P for ; Fri, 9 Sep 2016 19:36:41 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCE112B0F1 for ; Fri, 9 Sep 2016 19:36:41 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id c192so20310880oih.2 for ; Fri, 09 Sep 2016 19:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=U//c/z364IHpmldBBMFaSo0044Za/My13fAIzLV4KHY=; b=xRQwITQ0wFVbgPGN4gHpg69ATjfDQqPVONv8wVBXTtZEaHIjw5XibMVvlasRws8ZAf D1VPyz9xHs0F+Fa6DvMje3yHlaxhJccrR+hiJF9ZMTIMNISfddqdfENGMk1LfLcDNNOM 9E4Z7zu9vcGnZjjdL7YYSScfK8YcfPe5mvCIg3TQOkWYYThDw+MBghToy7/xxT5tFbRN L0fbzerz0rdfCg0c+2fU2bgfqMMj9JhewOkenSYpEWTJ6JwyX/988vshokxAQSNYKFm1 yRo+nQIA5X4uqJcqQVTsJH2obcZlhUg2QWSXLlrThlbjIBNKpCSXOG0Zlw98H97qwPo0 ZeQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U//c/z364IHpmldBBMFaSo0044Za/My13fAIzLV4KHY=; b=UTxJ+LOhVnZJnaZrK43aXH6DIAeM81r0Fr8ouF9Uoq/c12DuVzE25UX2acLx7WfsLD 5jZgrlJ7sAmFsT3u2KeBVHDHazKR5C0YpkIerfjAdas177H4+sG5QfFms2uIq6sOaGOc I47+5kEusK8Cmgj6lenLUqGG4U0YgDpPjqKBPngwUNLoKbHGzF9Z9ySXjZ7RUeMUvHom EGi0wOmN3zL88vT26GoW3MBtTtuXWIc8PB6DaCORyB8jk9aNXvt7U1ae08Il1ABrBIWQ 5XS5BP7Dartxer/GdiI9tBYHGznWdFCcYTWDc3M+7aaFywdh8F/ZOt9omTC7WdJNaKyh InfQ== X-Gm-Message-State: AE9vXwNx9E/qHgObO71TeDlCz1FIg4LaXvaIbQ5js6MZooVgNoHPsLUX1zJ5NFqh5+XldbaBZsXZqTeUYc8TvA== X-Received: by 10.202.237.208 with SMTP id l199mr9953779oih.42.1473475000913; Fri, 09 Sep 2016 19:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.175.3 with HTTP; Fri, 9 Sep 2016 19:36:40 -0700 (PDT) From: Matt Randall Date: Fri, 9 Sep 2016 21:36:40 -0500 Message-ID: To: "scim@ietf.org" , "dclippard@cerner.com" , shelley.baker@cerner.com Content-Type: multipart/alternative; boundary=001a113d375803d6d4053c1e22cf Archived-At: Subject: [scim] www-form-url-encoding for query parameters? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 02:36:43 -0000 --001a113d375803d6d4053c1e22cf Content-Type: text/plain; charset=UTF-8 The SCIM specification mentions RFC7230 (which defines the https:// scheme) and also mentions that URLs (URIs) must be percent-encoded per RFC3986. Notably, SCIM queries make use of "query parameters", but does not include any normative references that provide a first-class definition. Some implementations have made the implicit assumption that the presence of "query parameters" means that the entire query component is structured per x-www-form-urlencoded, as no definition is provided in any of the normative specifications for how query parameters are to be lexed. It's difficult to know whether that was the intent for SCIM, however; for example, OData (in which SCIM queries seem to share much in common with) define their own processing rules for URIs query components [1], which notably does not use x-www-form-urlencoded conventions. This has ramifications specifically with regard to handling the "+" character in queries, and whether the "+" character is considered lexically equivalent to %20 when parsing the query component. Should query parameters be treated as x-www-form-urlencoded, or should they be treated as a more generic interpretation of a "query parameter" (similar to OData) where only the "=" and "&" are treated as reserved separators, and the URI is percent-encoded purely based on RFC3986? [1]: http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-url-conventions/odata-v4.0-errata03-os-part2-url-conventions-complete.html#_Toc453752335 Thank you for any feedback, Matt Randall --001a113d375803d6d4053c1e22cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The SCIM specification mentions RFC7230 (which define= s the https:// scheme) and also mentions that URLs (URIs) must be percent-e= ncoded per RFC3986.=C2=A0 Notably, SCIM queries make use of "query par= ameters", but does not include any normative references that provide a= first-class definition.=C2=A0 Some implementations have made the implicit = assumption that the presence of "query parameters" means that the= entire query component is structured per x-www-form-urlencoded, as no defi= nition is provided in any of the normative specifications for how query par= ameters are to be lexed.=C2=A0 It's difficult to know whether that was = the intent for SCIM, however; for example, OData (in which SCIM queries see= m to share much in common with) define their own processing rules for URIs = query components [1], which notably does not use x-www-form-urlencoded conv= entions.

This has ramifications specifically with regard to ha= ndling the "+" character in queries, and whether the "+"= ; character is considered lexically equivalent to %20 when parsing the quer= y component.=C2=A0

Should query parameters be treated as x-www-form= -urlencoded, or should they be treated as a more generic interpretation of = a "query parameter" (similar to OData) where only the "=3D&q= uot; and "&" are treated as reserved separators, and the URI = is percent-encoded purely based on RFC3986?
--001a113d375803d6d4053c1e22cf-- From nobody Fri Sep 9 21:01:18 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6378212B31B for ; Fri, 9 Sep 2016 21:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Efu5jAcMp0Ln for ; Fri, 9 Sep 2016 21:01:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5BD12B313 for ; Fri, 9 Sep 2016 21:01:13 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8A419Cb026914 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 10 Sep 2016 04:01:09 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u8A418Sw001740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 10 Sep 2016 04:01:09 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8A417kP030047; Sat, 10 Sep 2016 04:01:08 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Sep 2016 21:01:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_231241D8-9550-494C-9895-FEC80C3187FB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Fri, 9 Sep 2016 21:01:06 -0700 Message-Id: <1B202095-FC84-470F-9BA9-A439F97FD2CD@oracle.com> References: To: Matt Randall X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" , "dclippard@cerner.com" , shelley.baker@cerner.com Subject: Re: [scim] www-form-url-encoding for query parameters? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 04:01:16 -0000 --Apple-Mail=_231241D8-9550-494C-9895-FEC80C3187FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Matt, Are you reading RFC7644? See section 1.2 regarding URL encoding. The examples are not URL = encoded for readability reasons as stated in the Notational Conventions. URL parameters are mostly used in the GET requests (Section 3.4) for = things like filters, paging, sorting. For parameters that can be used = in all operations, see section 3.9 and 3.10 on attribute notation. SCIM=E2=80=99s similarity with ODATA probably arises because it is about = RESTful identity data. There was no intended similarity. Though SCIM is = being used for Identity Services (a directory) its primary intent in the = specification is provisioning. This changes some of the design emphasis. One other major difference in that the SCIM does not permit nested = objects or references (e.g. /Users//manager). So where ODATA can = have many many ways to reference the same object, SCIM has a relatively = flat hierarchy consisting of containers for ResourceTypes and has only = one way to reference a resource. The chief reason is to avoid = referential integrity issues when resources reference each other (e.g. = such as with groups).=20 Hope this helps. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 9, 2016, at 7:36 PM, Matt Randall = wrote: >=20 > The SCIM specification mentions RFC7230 (which defines the https:// = scheme) and also mentions that URLs (URIs) must be percent-encoded per = RFC3986. Notably, SCIM queries make use of "query parameters", but does = not include any normative references that provide a first-class = definition. Some implementations have made the implicit assumption that = the presence of "query parameters" means that the entire query component = is structured per x-www-form-urlencoded, as no definition is provided in = any of the normative specifications for how query parameters are to be = lexed. It's difficult to know whether that was the intent for SCIM, = however; for example, OData (in which SCIM queries seem to share much in = common with) define their own processing rules for URIs query components = [1], which notably does not use x-www-form-urlencoded conventions. >=20 > This has ramifications specifically with regard to handling the "+" = character in queries, and whether the "+" character is considered = lexically equivalent to %20 when parsing the query component. =20 >=20 > Should query parameters be treated as x-www-form-urlencoded, or should = they be treated as a more generic interpretation of a "query parameter" = (similar to OData) where only the "=3D" and "&" are treated as reserved = separators, and the URI is percent-encoded purely based on RFC3986? >=20 > [1]: = http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-url= -conventions/odata-v4.0-errata03-os-part2-url-conventions-complete.html#_T= oc453752335 = >=20 > Thank you for any feedback, >=20 > Matt Randall > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_231241D8-9550-494C-9895-FEC80C3187FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Matt,

Are you reading RFC7644?

See section 1.2 = regarding URL encoding.  The examples are not URL encoded for = readability reasons as stated in the Notational Conventions.

URL parameters are = mostly used in the GET requests (Section 3.4) for things like filters, = paging, sorting.  For parameters that can be used in all = operations, see section 3.9 and 3.10 on attribute notation.

SCIM=E2=80=99s = similarity with ODATA probably arises because it is about RESTful = identity data. There was no intended similarity. Though SCIM is being = used for Identity Services (a directory) its primary intent in the = specification is provisioning. This changes some of the design = emphasis.

One = other major difference in that the SCIM does not permit nested objects = or references (e.g. /Users/<id>/manager).  So where ODATA can = have many many ways to reference the same object, SCIM has a relatively = flat hierarchy consisting of containers for ResourceTypes and has only = one way to reference a resource.  The chief reason is to avoid = referential integrity issues when resources reference each other (e.g. = such as with groups). 

Hope this helps.




On Sep 9, 2016, at 7:36 PM, Matt Randall <matthew.a.randall@gmail.com> wrote:

The SCIM specification mentions RFC7230 = (which defines the https:// scheme) and also mentions that URLs (URIs) = must be percent-encoded per RFC3986.  Notably, SCIM queries make = use of "query parameters", but does not include any normative references = that provide a first-class definition.  Some implementations have = made the implicit assumption that the presence of "query parameters" = means that the entire query component is structured per = x-www-form-urlencoded, as no definition is provided in any of the = normative specifications for how query parameters are to be lexed.  = It's difficult to know whether that was the intent for SCIM, however; = for example, OData (in which SCIM queries seem to share much in common = with) define their own processing rules for URIs query components [1], = which notably does not use x-www-form-urlencoded conventions.

This has ramifications specifically with = regard to handling the "+" character in queries, and whether the "+" = character is considered lexically equivalent to %20 when parsing the = query component. 

Should query = parameters be treated as x-www-form-urlencoded, or should they be = treated as a more generic interpretation of a "query parameter" (similar = to OData) where only the "=3D" and "&" are treated as reserved = separators, and the URI is percent-encoded purely based on RFC3986?

[1]: http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complet= e/part2-url-conventions/odata-v4.0-errata03-os-part2-url-conventions-compl= ete.html#_Toc453752335

Thank you for any feedback,

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

= --Apple-Mail=_231241D8-9550-494C-9895-FEC80C3187FB-- From nobody Sun Sep 11 23:12:33 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D730B12B053 for ; Sun, 11 Sep 2016 23:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 LeXlgq0e4ZZI for ; Sun, 11 Sep 2016 23:12:30 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC9012B02F for ; Sun, 11 Sep 2016 23:12:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id c131so39328473wmh.0 for ; Sun, 11 Sep 2016 23:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J550Il30tCUQ/qKofjU/BZJ9m50pTFhngKzT+6PuqaA=; b=Tfl2MXEXVT887OSrCR9gvw8oL//U3lY8wuQWiKs1W16O9aJeOL3Xwpe+R0sXPwN1Ti q9cUXdlOuAAZS3+4uDBRGQ1FIFK4bnfE63XmXEHlLxKtjqoVHluGOffQWeVpXTXJKG4u UnjmkO+EytAOlWptT79i/2dAf2XXIAR6vzZn1orBRh6i7cXB7R4r28fWuruBxb6PZ46S THVfueZVj6KU+VBhTUpcGUM6IIYDhBx8OY6HDDQeZkIxxbL3Io9IOskvy3isX7abDMSh ll1yGGBF95AbjwCgKNxqhCxemV8Y8euHGl+EfhrtZFmNZ853hhADFQVcaxOn5umOyf4E l/SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J550Il30tCUQ/qKofjU/BZJ9m50pTFhngKzT+6PuqaA=; b=c9adzqU5S1krPNxweBcIRt9Vw5Rg7CxHSl908c67br1uATP2ONpacROq1y2BxVGVja A/KHA5p1Y4t5RJLSfx9m0w47hrH4XDdFm8jojWVknio3E4j1HbvMTuoXNfOTpukR13DG QAXp4shzUSxpmraeuuvDc8j49OUs3UJ0CZk1y2ICB0WKKdQyYYRCloU9lEQy3DLV93qR HlCBKKAkILptFwUCFEAyV6WEiiWvgv4wVN3RG49RdLguTRjgd+E0iNMP2dzncJh8xAqN f0DPKqrzXCrWa+4PztE/qy5YU52OVgAhin/7EFPwgM/JoVz2IPpeAk4k5RXVjRpkKQ+0 sgDg== X-Gm-Message-State: AE9vXwN9zpj6e4JinGg5/H4+PylaSJM8D72Fcq12W9B8uUfVX6iVe5IFNMwE9Z0xZAvP2vKgr3WHsuivnY7yCw== X-Received: by 10.194.201.230 with SMTP id kd6mr12699469wjc.167.1473660748042; Sun, 11 Sep 2016 23:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.94.103 with HTTP; Sun, 11 Sep 2016 23:12:27 -0700 (PDT) In-Reply-To: <399A0ECA-684A-4D89-9A9B-ECFD194F2249@oracle.com> References: <399A0ECA-684A-4D89-9A9B-ECFD194F2249@oracle.com> From: Samuel Erdtman Date: Mon, 12 Sep 2016 08:12:27 +0200 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7b87371c68326d053c496111 Archived-At: Cc: "scim@ietf.org" , Kevin Gough Subject: Re: [scim] =?utf-8?q?Update_on_Okta=E2=80=99s_SCIM_promotional_activi?= =?utf-8?q?ties_=26_invitation_for_collaboration?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 06:12:33 -0000 --047d7b87371c68326d053c496111 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil & Kevin, I agree the simplecloud.info site could be improved. I have recently moved the site to its own github project ( https://github.com/erdtman/simplecloud.info) and connected it to automatically deploy on heroku when pushing new versions. So if you are interested in updating and improving the site I would be happy to accept pull requests or add you as collaborators. //Samuel On Thu, Sep 8, 2016 at 10:09 PM, Phil Hunt wrote: > SCIM and simplecloud.info is very much alive. On my side, Oracle just > announced IDCS which is SCIM based in its entirety. > > Agree the SimpleCloud.info site could use some > updating. Do we have a contact email for simplecloud? Might be a better > place update info to a single contact rather than on this list which shou= ld > be about new extension discussions and/or errata regarding RFC7643/7644. > > One of the issues with IETF is they don=E2=80=99t do much in the way of p= romotion > or certification. There has been some discussion about possibly getting a > certification program started at OIDF (though it hasn=E2=80=99t gone far = yet) where > we recently posted a draft for enabling SCIM as a CRUD capable UserInfo > endpoint for Connect. > > Might I also suggest a meeting up at the next IIW? We can discuss next > steps and futures there. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Sep 8, 2016, at 12:17 PM, Kevin Gough wrote: > > Over the last 6 months, Okta=E2=80=99s significantly increased it=E2=80= =99s investment in > promoting the SCIM standard to ISVs looking to enable provisioning via an > IdP for their apps. > > We=E2=80=99ve consolidated our efforts into a SCIM provisioning developer= program > , which > includes a free hands-onimplementation workshop > run by our > training team, an automated test suite that runs on Runscope, dedicated > developer support, and Okta & beta customer validation testing. > > So far, we=E2=80=99ve had 50 ISVs join the program. At our Oktane user co= nference > last week, we announced > > that Envoy > , > PingBoard, VividCortex, and Lucid Software > > had graduated from the program with successful SCIM implementations. As > part of Oktane, we also briefed analysts, including Gartner, Forrester, a= nd > Ovum, on our support for SCIM and progress to date. > > While we=E2=80=99re generating some initial momentum, it seems we need to= press > harder to ensure this standard sticks and adoption grows. > > Gregg Kreizman from Gartner seemed almost surprised to hear that we had 5= 0 > ISVs in our program. And one of our recent program applicants stated that > the http://www.simplecloud.info/ site seemed bare bones, and wondered if > the standard was really still alive. > > > My questions: > 1) How are others currently promoting the standard? > > 2) Who in this consortium is interested in investing in a more > collaborative promotion of the standard, be it joint workshops, articles = on > devsites, more documentation / code samples, case studies, etc.? > > Feel free to reply to all or reach out to me directly with ideas or to > signal interest. > Thanks. > > - Kevin > > Director, Product Marketing > Okta > _______________________________________________ > 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 > > --047d7b87371c68326d053c496111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil & Kevin,

I agree t= he simplecloud.info site could be i= mproved.

I have recently moved the site to its own github project (= https://github.com/= erdtman/simplecloud.info) and connected it to automatically deploy on h= eroku when pushing new versions.

So if you are interested in u= pdating and improving the site I would be happy to accept pull requests or = add you as collaborators.

//Samuel




O= n Thu, Sep 8, 2016 at 10:09 PM, Phil Hunt <phil.hunt@oracle.com>= wrote:
SCIM and si= mplecloud.info is very much alive.=C2=A0 On my side, Oracle just announ= ced IDCS which is SCIM based in its entirety.

Agree the = SimpleCloud.info = site could use some updating.=C2=A0 Do we have a contact email for simplecl= oud?=C2=A0 Might be a better place update info to a single contact rather t= han on this list which should be about new extension discussions and/or err= ata regarding RFC7643/7644.

One of the issues with= IETF is they don=E2=80=99t do much in the way of promotion or certificatio= n. There has been some discussion about possibly getting a certification pr= ogram started at OIDF (though it hasn=E2=80=99t gone far yet) where we rece= ntly posted a draft for enabling SCIM as a CRUD capable UserInfo endpoint f= or Connect.

Might I also suggest a meeting up at t= he next IIW?=C2=A0 We can discuss next steps and futures there.
<= br>

On Sep 8, 2016, at 12:17 PM, Kevin = Gough <kevin.g= ough@okta.com> wrote:

Over the last 6 months, Okta=E2= =80=99s significantly increased it=E2=80=99s investment in promoting the SC= IM standard to ISVs looking to enable provisioning via an IdP for their app= s.
=
SCIM provisioning developer program, which includes a free = hands-onimplementation workshop=C2=A0run b= y our training team, an automated test suite that runs on Runscope, dedicat= ed developer support, and Okta & beta=C2=A0customer validation testing.= =C2=A0

So far, we=E2=80=99ve had 50 ISVs join the program. At our Oktane=C2= =A0user conference last week,=C2=A0we announced=C2=A0= that=C2=A0Envoy, PingBoard, VividCortex, and=C2=A0Lucid Software=C2=A0had gradu= ated from the program with successful SCIM implementations. As part of Okta= ne, we also briefed analysts, including Gartner,=C2=A0Forrester, and Ovum, = on our support for SCIM and progress to date.=C2=A0

While we=E2=80=99re gene= rating some initial momentum, it seems we need to press harder to ensure th= is standard sticks and adoption grows.

Gregg Kreizman from Gartner seemed al= most surprised to hear that we had 50 ISVs in our program. And one of our r= ecent program applicants stated that the=C2=A0http://www= .simplecloud.info/=C2=A0site seemed bare bones, and wondered if th= e standard was really still=C2=A0alive.


My questions:=C2=A0=C2=A0<= /span>
1) How are others currently promoting the standard?=C2=A0

2) Who in this= consortium is interested in investing in a more collaborative promotion of= the standard, be it joint workshops, articles on devsites, more documentat= ion / code samples, case studies, etc.?

Feel free to reply to all or reach o= ut to me directly with ideas or to signal interest.
Thanks.

- Kevin=C2=A0
<= br>

Director, Product Marketing
Okta
_______________= ________________________________
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


--047d7b87371c68326d053c496111-- From nobody Mon Sep 12 10:04:33 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56ED128E18 for ; Mon, 12 Sep 2016 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 e36yY8zDfIg4 for ; Mon, 12 Sep 2016 10:04:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BE6128874 for ; Mon, 12 Sep 2016 10:04:27 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8CH4P7f026378 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2016 17:04:25 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8CH4Olp004883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2016 17:04:25 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u8CH4OnQ009224; Mon, 12 Sep 2016 17:04:24 GMT Received: from [10.151.103.133] (/148.87.13.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2016 10:04:23 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_02BAE721-2B7F-4067-9D5D-2351000C20A2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Mon, 12 Sep 2016 10:04:23 -0700 Message-Id: <4024755C-8125-4118-A5AA-1B13CF360AD7@oracle.com> References: <1B202095-FC84-470F-9BA9-A439F97FD2CD@oracle.com> To: Matt Randall X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org WG" Subject: Re: [scim] www-form-url-encoding for query parameters? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 17:04:31 -0000 --Apple-Mail=_02BAE721-2B7F-4067-9D5D-2351000C20A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No, x-www-form-urlencoded is not actually required to be supported (as = currently specified). They aren=E2=80=99t quite the same. The main = difference is encoding of the space character as =E2=80=9C%20=E2=80=9D = or =E2=80=9C+=E2=80=9D. SCIM only references Sec 2.1 of RFC3986 which indicates non-permitted = characters are to be percent encoded (e.g. space as %20).=20 AFAIK supporting =E2=80=9C+=E2=80=9D is common practice and most = implementations probably support *both* %20 and =E2=80=9C+=E2=80=9D. = However officially support for the =E2=80=9C+=E2=80=9D characters is not = actually required. IMV, this is ok as the spec is silent on = x-www-form-urlencoded. I=E2=80=99ll let others on the list comment as to their support or lack = of support for =E2=80=9C+=E2=80=9D in URL encoding. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 12, 2016, at 7:20 AM, Matt Randall = wrote: >=20 > Thank you for the reply, Phil. >=20 > In response to your question - yes, RFC7644 is the RFC in question. = Can you confirm "URL encoding" with respect to the query component of = SCIM URLs specifically means "x-www-form-urlencoded query strings? The = specification mentions "query parameters", but there's not any RFC that = I am aware of that defines what a query parameter is (the w3 defines it = in HTML forms [1], but that's about it.) >=20 > [1]: https://www.w3.org/TR/html401/interact/forms.html = >=20 > On Fri, Sep 9, 2016 at 11:01 PM, Phil Hunt > wrote: > Matt, >=20 > Are you reading RFC7644? >=20 > See section 1.2 regarding URL encoding. The examples are not URL = encoded for readability reasons as stated in the Notational Conventions. >=20 > URL parameters are mostly used in the GET requests (Section 3.4) for = things like filters, paging, sorting. For parameters that can be used = in all operations, see section 3.9 and 3.10 on attribute notation. >=20 > SCIM=E2=80=99s similarity with ODATA probably arises because it is = about RESTful identity data. There was no intended similarity. Though = SCIM is being used for Identity Services (a directory) its primary = intent in the specification is provisioning. This changes some of the = design emphasis. >=20 > One other major difference in that the SCIM does not permit nested = objects or references (e.g. /Users//manager). So where ODATA can = have many many ways to reference the same object, SCIM has a relatively = flat hierarchy consisting of containers for ResourceTypes and has only = one way to reference a resource. The chief reason is to avoid = referential integrity issues when resources reference each other (e.g. = such as with groups).=20 >=20 > Hope this helps. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Sep 9, 2016, at 7:36 PM, Matt Randall > wrote: >>=20 >> The SCIM specification mentions RFC7230 (which defines the https:// = scheme) and also mentions that URLs (URIs) must be percent-encoded per = RFC3986. Notably, SCIM queries make use of "query parameters", but does = not include any normative references that provide a first-class = definition. Some implementations have made the implicit assumption that = the presence of "query parameters" means that the entire query component = is structured per x-www-form-urlencoded, as no definition is provided in = any of the normative specifications for how query parameters are to be = lexed. It's difficult to know whether that was the intent for SCIM, = however; for example, OData (in which SCIM queries seem to share much in = common with) define their own processing rules for URIs query components = [1], which notably does not use x-www-form-urlencoded conventions. >>=20 >> This has ramifications specifically with regard to handling the "+" = character in queries, and whether the "+" character is considered = lexically equivalent to %20 when parsing the query component. =20 >>=20 >> Should query parameters be treated as x-www-form-urlencoded, or = should they be treated as a more generic interpretation of a "query = parameter" (similar to OData) where only the "=3D" and "&" are treated = as reserved separators, and the URI is percent-encoded purely based on = RFC3986? >>=20 >> [1]: = http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-url= -conventions/odata-v4.0-errata03-os-part2-url-conventions-complete.html#_T= oc453752335 = >>=20 >> Thank you for any feedback, >>=20 >> Matt Randall >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = >=20 >=20 --Apple-Mail=_02BAE721-2B7F-4067-9D5D-2351000C20A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No,  x-www-form-urlencoded is not = actually required to be supported (as currently specified). They = aren=E2=80=99t quite the same. The main difference is encoding of the = space character as =E2=80=9C%20=E2=80=9D or =E2=80=9C+=E2=80=9D.

SCIM only references = Sec 2.1 of RFC3986 which indicates non-permitted characters are to be = percent encoded (e.g. space as %20). 

AFAIK supporting =E2=80=9C+=E2=80=9D is = common practice and most implementations probably support *both* %20 and = =E2=80=9C+=E2=80=9D. However officially support for the =E2=80=9C+=E2=80=9D= characters is not actually required.   IMV, this is ok as the spec = is silent on x-www-form-urlencoded.

I=E2=80=99ll let others on the list = comment as to their support or lack of support for =E2=80=9C+=E2=80=9D = in URL encoding.




On Sep 12, 2016, at 7:20 AM, Matt Randall <matthew.a.randall@gmail.com> wrote:

Thank you for the reply, Phil.

In response to your = question - yes, RFC7644 is the RFC in question.  Can you confirm = "URL encoding" with respect to the query component of SCIM URLs = specifically means "x-www-form-urlencoded query strings?  The = specification mentions "query parameters", but there's not any RFC that = I am aware of that defines what a query parameter is (the w3 defines it = in HTML forms [1], but that's about it.)

[1]:= https://www.w3.org/TR/html401/interact/forms.html

On Fri, Sep 9, 2016 at 11:01 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Matt,

Are you reading = RFC7644?

See = section 1.2 regarding URL encoding.  The examples are not URL = encoded for readability reasons as stated in the Notational = Conventions.

URL= parameters are mostly used in the GET requests (Section 3.4) for things = like filters, paging, sorting.  For parameters that can be used in = all operations, see section 3.9 and 3.10 on attribute = notation.

SCIM=E2=80=99s similarity with ODATA probably arises because = it is about RESTful identity data. There was no intended similarity. = Though SCIM is being used for Identity Services (a directory) its = primary intent in the specification is provisioning. This changes some = of the design emphasis.

One other major difference in that the SCIM does not permit = nested objects or references (e.g. /Users/<id>/manager).  So = where ODATA can have many many ways to reference the same object, SCIM = has a relatively flat hierarchy consisting of containers for = ResourceTypes and has only one way to reference a resource.  The = chief reason is to avoid referential integrity issues when resources = reference each other (e.g. such as with groups). 

Hope this = helps.

Phil

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




=

On Sep 9, 2016, at 7:36 PM, = Matt Randall <matthew.a.randall@gmail.com> = wrote:

The SCIM specification mentions RFC7230 (which defines the = https:// scheme) and also mentions that URLs (URIs) must be = percent-encoded per RFC3986.  Notably, SCIM queries make use of = "query parameters", but does not include any normative references that = provide a first-class definition.  Some implementations have made = the implicit assumption that the presence of "query parameters" means = that the entire query component is structured per x-www-form-urlencoded, = as no definition is provided in any of the normative specifications for = how query parameters are to be lexed.  It's difficult to know = whether that was the intent for SCIM, however; for example, OData (in = which SCIM queries seem to share much in common with) define their own = processing rules for URIs query components [1], which notably does not = use x-www-form-urlencoded conventions.

This has ramifications specifically with regard to = handling the "+" character in queries, and whether the "+" character is = considered lexically equivalent to %20 when parsing the query = component. 

Should query parameters = be treated as x-www-form-urlencoded, or should they be treated as a more = generic interpretation of a "query parameter" (similar to OData) where = only the "=3D" and "&" are treated as reserved separators, and the = URI is percent-encoded purely based on RFC3986?

[1]: http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-url-conventions/odata-v4.0-errata03-os-part2-url-conventions-complete.html#_Toc453752335

Thank you for any = feedback,

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



= --Apple-Mail=_02BAE721-2B7F-4067-9D5D-2351000C20A2-- From nobody Mon Sep 12 13:47:54 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EA012B112 for ; Mon, 12 Sep 2016 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4-wrTeJXswQr for ; Mon, 12 Sep 2016 13:47:51 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B1A12B10E for ; Mon, 12 Sep 2016 13:47:51 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id q188so219505197oia.3 for ; Mon, 12 Sep 2016 13:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OUnBevWI0pmN7ndbPYSrYtFu8jNflrcNhTfg9rb4Up4=; b=ZaBExeWhdOEOGViVDDX0MXXETsPkq4Y2c6fIjlNIcJ6jJpFPS138CqwHqWnysgZCNw jMYDEDHr2SChO5K6Woaj4/e4p6kpGe8DAsaTUGXnQ7c5hEcYFEMevTH8B8ui4WX0qES5 eSoj+Gr12NC8EzfInalrGYoRGLN0u/yaHfMTUDaU5uc+nWJWEWza+q+rxcDk++saXJDD dyxvGkyY+OdERWR/IPdgCG9ciwQzcb8+EUEd0tBGiVealDz36ZwO3+K9B1LBEi1M2Okq 45VaC9lJKhb/tYfyj5Pt4whbJsE5zB4qm8UNvjayXwcVkSd/Id8rsaqDc0X4qopnNDUr G4Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OUnBevWI0pmN7ndbPYSrYtFu8jNflrcNhTfg9rb4Up4=; b=MN3vzRnMSkvqfV5R5N5dmyAV2h0qf7Sy/Ka/FmPgeNaQMYSe8cZmRHybSf3hBZxlHn N/QPU2IWWjAP3ChQm01dsO2HmO3maeSz3WGsd/864AMOr+g/DirfvVvdD+SPjNfqv6x2 Oj+YlplPiHa6DSWa57brG8hrYuf3IwR1ymNnA+d8mep86S5FkLQJD2niILoDPsDP+XPc 0Pp0ZlmMcYPUC2zVSxBDMzWtJEDqtTjRbCGjCscZB2jKngYqUaa8Wwzph4x+VBxyzBfs reyg0AiXkv4i806KNzThfUndymHnfGOqACddZ282S548Dz1pq6y7aMA+pNg8J80dHXzD ULcw== X-Gm-Message-State: AE9vXwMOJqS2O+PnpUOAe2vbpp1fhRuKpAVCzAfnCZi4c3/h3jvdj/eGS2ogX8mZTuVD6G7RNDaNZ3PG4zmMFQ== X-Received: by 10.202.83.70 with SMTP id h67mr1308496oib.87.1473713270864; Mon, 12 Sep 2016 13:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.175.14 with HTTP; Mon, 12 Sep 2016 13:47:50 -0700 (PDT) In-Reply-To: References: From: Matt Randall Date: Mon, 12 Sep 2016 15:47:50 -0500 Message-ID: To: "scim@ietf.org" , "dclippard@cerner.com" , shelley.baker@cerner.com Content-Type: multipart/alternative; boundary=001a113de44602c559053c559ca8 Archived-At: Subject: Re: [scim] www-form-url-encoding for query parameters? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 20:47:53 -0000 --001a113de44602c559053c559ca8 Content-Type: text/plain; charset=UTF-8 Just for those following along, here's an example of where it is necessary to know if the incoming request was encoded using x-www-form-urlencoded rules, or using the basic URI rules allowing for the reserved characters "&" and "=". An x-www-form-urlencoded implementation could send: ?filter=meta.lastModified+le+"2011-05-13T04:42:34%2B05:00" Using x-www-form-urlencoded rules, this value of "filter" would be interpreted as: meta.lastModified le "2011-05-13T04:42:34+05:00" Using only the rules provided in the SCIM spec, the value of "filter" would be interpreted as: meta.lastModified+le+"2011-05-13T04:42:34+05:00" Alternatively, a client could decide not to use x-www-form-urlencoded rules and might send: ?filter=meta.lastModified%20le%20"2011-05-13T04:42:34+05:00" Using x-www-form-urlencoded rules, this value of "filter" would be interpreted as: meta.lastModified le "2011-05-13T04:42:34 05:00" Using only the rules provided in the SCIM spec, the value of "filter" would be interpreted as: meta.lastModified le "2011-05-13T04:42:34+05:00" The most straightforward way to prevent the ambiguity is to simply declare "+" as a reserved character for SCIM query string implementations, such that consumers are required to encode plus signs as %2B, and advising SCIM providers to treat "+" characters as spaces for backwards compatibility. --001a113de44602c559053c559ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just for those following along, here's an example of w= here it is necessary to know if the incoming request was encoded using x-ww= w-form-urlencoded rules, or using the basic URI rules allowing for the rese= rved characters "&" and "=3D".=C2=A0 An x-www-form-= urlencoded implementation could send:
?filter=3Dmeta.lastModified+le+"2011-05-13T= 04:42:34%2B05:00"
Using x-www-form-urlencoded rules, this v= alue of "filter" would be interpreted as:
meta.lastModified le "2011-05-13T0=
4:42:34+05:00"
Using only the rules provided in the SCIM spec, th= e value of "filter" would be interpreted as:
meta.lastModified+le+"2011-05-1=
3T04:42:34+05:00"
Alternatively, a client could decide not to use= x-www-form-urlencoded rules and might send:
?filter=3Dmeta.lastModified%20le%20"=
2011-05-13T04:42:34+05:00"
Using x-www-f= orm-urlencoded rules, this value of "filter" would be interpreted= as:
meta.lastMo=
dified le "2011-05-13T04:42:34 05:00"
Using only the rules p= rovided in the SCIM spec, the value of "filter" would be interpre= ted as:
meta.las=
tModified le "2011-05-13T04:42:34+05:00"

The=
 most straightforward way to prevent the ambiguity is to simply declare &qu=
ot;+" as a reserved character for SCIM query string implementations, s=
uch that consumers are 
required to encode plus signs as %2B, and advisi=
ng SCIM providers to treat "+" characters as spaces for backwards=
 compatibility.


--001a113de44602c559053c559ca8-- From adr_gonzalez@yahoo.fr Tue Sep 13 01:51:17 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269AF12B21D for ; Tue, 13 Sep 2016 01:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.fr 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 P7cdGjty1jle for ; Tue, 13 Sep 2016 01:51:15 -0700 (PDT) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A236B12B211 for ; Tue, 13 Sep 2016 01:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1473756675; bh=8xeaoh5buimcBYxDvkjiIPlNEBx2mN4LXDQaauVnvao=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=sM/33sh7YtXwbtKCt+LJpgpma+pD0+Rcoy+0FOAT0JTzf0W1sY59FVR2SwLkbu7aMC/dnAdiUCxr8vgkV9X+0+DW7f73azS00pEenyiHQS8J66SN5hAY+AWCn3cyPc5TIT79IHA0/oTo/wRQwOaYGrFSCYOIDDbHpwYBg/aAlousjk/Ep2bftBG9HHirTbgfVYfIYm/eF6hMoQoikCs3mgSj3IoAuyT3vIDEjaao64iCri69o0aX0xejLXvtMI26wXo9RYajZ7HsNUQd0DRUKixV7YKiFntYPp53MIfEDE2RHoyJ+gzb3qHyXTTpIWKNIEHe3UDcyuhKWEd35GUT2w== Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 08:51:15 -0000 Received: from [98.138.100.114] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 08:48:23 -0000 Received: from [212.82.98.125] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 08:48:23 -0000 Received: from [212.82.98.95] by tm18.bullet.mail.ir2.yahoo.com with NNFMP; 13 Sep 2016 08:48:23 -0000 Received: from [127.0.0.1] by omp1032.mail.ir2.yahoo.com with NNFMP; 13 Sep 2016 08:48:23 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 692055.4764.bm@omp1032.mail.ir2.yahoo.com X-YMail-OSG: JhPy9bMVM1nJ1yxqIuFwyJn.Tr.eX3h95Mc4o.xwhWTaFxcty6.aDzOBREqJynl nkJV0nylUVlhdv.yvJ3onNrG1fIZtLPGMPBiaOZ5AhTvtQmqw_8RAp8EHb9L1twTlF1fu34jT6AW wDDri47GWPiYNaT3LRfVSORPZKB42Oz5j9F.T1y6aRfmOrGseb05ocff59J9DQaseg79SFyeHRMc 1iPXtrFm1_kRrHg1xnCOOYFo43XD0HQX8TzS7R9m0PpPW.zN9FS4Q43AVNPVLwDZi.v670BDSklC 1mzzcB46IKn4rSx3RGqEBtWkmL_Deebquwbxd1r36Sl0IZdGV_vyT7Gbg_1cYkssyLqYwgGC9hkt Q_L84u3LgbHEZXyiabsVgtT58EQFmav1hqw0jCqRfPD2WLz7XxQt6Gx8rDsIKDMPhuwrdIig329Y xG5rG2fDif19nzw89BGLA6Xk7b1Og_YJCWAnFTACd49m7AL8sNw62Xz1PJsD4.K2GPdfVRQ8wB0. .bp23LPpItZglBHCkdNPklhW5bN04WIo- Received: from jws11107.mail.ir2.yahoo.com by sendmailws104.mail.ir2.yahoo.com; Tue, 13 Sep 2016 08:48:23 +0000; 1473756503.273 Date: Tue, 13 Sep 2016 08:48:22 +0000 (UTC) From: Adrian Gonzalez To: "scim@ietf.org" Message-ID: <1312708598.238311.1473756502733@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_238310_126058601.1473756502728" References: <1312708598.238311.1473756502733.ref@mail.yahoo.com> Archived-At: Subject: [scim] SCIM Provider how to handle unknown extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrian Gonzalez List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 08:55:37 -0000 ------=_Part_238310_126058601.1473756502728 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello dear experts, Could you please tell me how an SCIM Provider is expected to react when he = receives a SCIM representation using unknown extensions ? (extensions the p= rovider doesn't handle). Should he :=C2=A0* just ignore them=C2=A0* returns an exception ?=C2=A0* no= t mandated by the spec (implementation-specific then) I've looked at SCIM 2.0 specs, but didn't found a related section on that.P= erhaps I've missed something ? Thanks,Adrian ------=_Part_238310_126058601.1473756502728 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello dear experts,

Could you please tell me how an SCIM Provider= is expected to react when he receives a SCIM representation using unknown = extensions ? (extensions the provider doesn't handle).

Should he :
 * just ignore them
 * re= turns an exception ?
 * not mandated by the spec (implementation-specific then= )
I've = looked at SCIM 2.0 specs, but didn't found a related section on that.
=
Perhaps I've = missed something ?

Thanks,
Adrian
=
------=_Part_238310_126058601.1473756502728-- From nobody Thu Sep 15 00:45:25 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999012B1A0 for ; Thu, 15 Sep 2016 00:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ziWmWtxC5ANp for ; Thu, 15 Sep 2016 00:45:21 -0700 (PDT) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973A512B19D for ; Thu, 15 Sep 2016 00:45:21 -0700 (PDT) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8F7goJA118805 for ; Thu, 15 Sep 2016 03:45:21 -0400 Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by mx0a-001b2d01.pphosted.com with ESMTP id 25exqs5wgg-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Sep 2016 03:45:21 -0400 Received: from localhost by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Sep 2016 17:45:18 +1000 Received: from d23dlp01.au.ibm.com (202.81.31.203) by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Sep 2016 17:45:17 +1000 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: sweeden@au1.ibm.com X-IBM-RcptTo: scim@ietf.org Received: from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 90E262CE8046 for ; Thu, 15 Sep 2016 17:45:16 +1000 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u8F7jGaM459258 for ; Thu, 15 Sep 2016 17:45:16 +1000 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u8F7jGOo005560 for ; Thu, 15 Sep 2016 17:45:16 +1000 Received: from d50lp02.ny.us.ibm.com (d50lp02.pok.ibm.com [146.89.104.208]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u8F7jDru005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Sep 2016 17:45:15 +1000 Received: from localhost by d50lp02.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Sep 2016 03:45:13 -0400 Received: from smtp.notes.na.collabserv.com (192.155.248.72) by d50lp02.ny.us.ibm.com (158.87.18.21) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128/128) Thu, 15 Sep 2016 03:45:11 -0400 X-IBM-Helo: smtp.notes.na.collabserv.com X-IBM-MailFrom: sweeden@au1.ibm.com X-IBM-RcptTo: scim@ietf.org Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Thu, 15 Sep 2016 07:45:10 -0000 Received: from us1a3-smtp05.a3.dal06.isc4sb.com (10.146.71.159) by smtp.notes.na.collabserv.com (10.106.227.158) with smtp.notes.na.collabserv.com ESMTP; Thu, 15 Sep 2016 07:45:08 -0000 X-IBM-Helo: us1a3-smtp05.a3.dal06.isc4sb.com X-IBM-MailFrom: sweeden@au1.ibm.com X-IBM-RcptTo: scim@ietf.org Received: from us1a3-mail98.a3.dal06.isc4sb.com ([10.146.21.239]) by us1a3-smtp05.a3.dal06.isc4sb.com with ESMTP id 2016091507450756-64904 ; Thu, 15 Sep 2016 07:45:07 +0000 MIME-Version: 1.0 To: scim@ietf.org From: "Shane B Weeden" Date: Thu, 15 Sep 2016 17:44:51 +1000 X-KeepSent: 652099BF:4F33D6BD-4A25802F:002A1CF8; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1EXT SHF692 April 27, 2016 X-LLNOutbound: False X-Disclaimed: 58203 X-TNEFEvaluated: 1 Content-type: multipart/alternative; Boundary="0__=C5BB0ABCDFB99A688f9e8a93df938690918cC5BB0ABCDFB99A68" Content-Disposition: inline x-cbid: 16091507-0048-0000-0000-000001BA38A9 X-IBM-ISS-SpamDetectors: Score=0.439231; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.439231; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00005763; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000185; SDB=6.00757876; UDB=6.00359556; UTC=2016-09-15 07:45:09 x-cbparentid: 16091507-6060-0000-0000-0000021883B7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-15_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609150103 Archived-At: Subject: [scim] SCIM filter example with extended UTF-chars X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 07:45:23 -0000 --0__=C5BB0ABCDFB99A688f9e8a93df938690918cC5BB0ABCDFB99A68 Content-Transfer-Encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 I was hoping someone could provide a command-line curl example of how a SCIM query filter that uses extended UTF-8 chars should be formed. E.g. consider I have a user with userName=3Dj=F6hn In case that doesn't come across properly in email, the second char is the umlat 'o', i.e. UTF-8 char represented by the two bytes 0xC3 0xB6 I want the equivalent of "userName eq j=F6hn" For ascii-chars only (like "testuser"), I know this works: curl -H "Accept: application/scim+json" "https://server/scim/Users?filter=3DuserName%20eq%20testuser" Can anyone help me find "j=F6hn" ? :) Thanks, Shane. --0__=C5BB0ABCDFB99A688f9e8a93df938690918cC5BB0ABCDFB99A68 Content-Transfer-Encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

I was hoping someone could provide a command-line curl examp= le of how a SCIM query filter that uses extended UTF-8 chars should be form= ed.

E.g. consider I have a user with userName=3Dj=F6hn

In cas= e that doesn't come across properly in email, the second char is the umlat = 'o', i.e. UTF-8 char represented by the two bytes 0xC3 0xB6

I want t= he equivalent of "userName eq j=F6hn"

For ascii-chars only= (like "testuser"), I know this works:

curl -H "Accep= t: application/scim+json" <authentication headers as needed> &qu= ot;= https://server/scim/Users?filter=3DuserName%20eq%20testuser"
Can anyone help me find "j=F6hn" ?
:)

Thanks,
Sh= ane.

--0__=C5BB0ABCDFB99A688f9e8a93df938690918cC5BB0ABCDFB99A68-- From prvs=106619e285=corey.schooler@cerner.com Thu Sep 15 09:31:41 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9629512B87B for ; Thu, 15 Sep 2016 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cerner.com 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 x70NbxZ4nrS5 for ; Thu, 15 Sep 2016 09:31:39 -0700 (PDT) Received: from PPKC2MAIL5.cernercloud.com (ppkc2mail5.cernercloud.com [159.140.195.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBDE12B571 for ; Thu, 15 Sep 2016 08:42:09 -0700 (PDT) Received: from pps.filterd (PPKC2MAIL5.cernercloud.com [127.0.0.1]) by PPKC2MAIL5.cernercloud.com (8.16.0.17/8.16.0.17) with SMTP id u8FFfPNl018196 for ; Thu, 15 Sep 2016 10:42:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cerner.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201512; bh=n/tVamqLQPtXNCFhh9sXRRJUwk7EKEL7UzBwNCSkWnE=; b=t5hDFwA8dpLrENdcv8iJZrnSSbuyEv7/Aeh4VFigR9an/3NnfNZp+WmX8jtUf0lFlMq8 bdu7vbFDQP633ZYeO7VmMz5NhbrPh6gtXF3LzOwCNKZD5ychPTDSIggKt4Khm+u8vSnm jfJw95hpMRDFjbWin1mHVXhiQ4ifsRds3lD50D5WyLNI3+yzVa+V8qdzA5yGzVqKwXX5 gFagyzPk9kDBLvCJAGz7E4TkEP+1WMKpfkWa8KS8g2wWZ/7ntzWmQDHi+DhPRSA6oXBk 1kNnv37yHsTRzTDxBZ4VJCbBzTWAY5OR+xBYN7QTkkFeUqZ0j6+nZp4Wm6PCfGs6WSKC kQ== Received: from cernmsgkc2ex08c.cerner.net ([170.71.113.88]) by PPKC2MAIL5.cernercloud.com with ESMTP id 25eywjdkk1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 15 Sep 2016 10:42:07 -0500 Received: from CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) by CERNMSGKC2EX08C.cerner.net (2002:aa47:7158::aa47:7158) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 15 Sep 2016 10:42:07 -0500 Received: from CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58]) by CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58%20]) with mapi id 15.00.1178.000; Thu, 15 Sep 2016 10:42:07 -0500 From: "Schooler,Corey" To: "scim@ietf.org" Thread-Topic: [scim] Expected behavior for null JSON values Thread-Index: AQHSD2e2JuM6jVLoUkCkGTOGmeTJ1A== Date: Thu, 15 Sep 2016 15:42:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cm-message-id: 147395410932941756d88c9b89550dd46eb23e16aca58d1057dac13d50777117902415 x-cm-draft-id: WyJhIiw0LCJkcmFmdF9pZCIsIjE0NzM5NTQxMDkwMDAiLCJ2IiwxXQ== x-mailer: CloudMagic x-cm-tracking-code: 1473954109/64cb1a8b8c0458c9278c43a25aec8eec/7d408c7f05e36c5489b456d42fe29965/5b8e2d7a1366cf442a1aa9cb515927b9/9efab2399c7c560b34de477b9aa0a465 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [54.210.254.249] Content-Type: multipart/alternative; boundary="_000_be48c82c68234c9392dd6b5f83e715aeCERNMSGLS5EX08Bcernerne_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-15_08:, , signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 22:26:28 -0700 Subject: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 18:40:47 -0000 --_000_be48c82c68234c9392dd6b5f83e715aeCERNMSGLS5EX08Bcernerne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was looking for guidance on how a v1.1 Service Provider should handle nul= l values provided within the json for a PATCH request. Example: { "schemas": ["urn:scim:schemas:core:1.0"], "displayName": null } Should the "displayName" attribute be ignored or should it be treated the s= ame as if "displayName" was supplied in "meta.attributes"? CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_be48c82c68234c9392dd6b5f83e715aeCERNMSGLS5EX08Bcernerne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was looking for guidance on how a v1.1 Service Provider should handl= e null values provided within the json for a PATCH request.

Example:
{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "displayName": null
}

Should the “displayName" attribute be ignored or should it = be treated the same as if “displayName" was supplied in “m= eta.attributes"?
CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_be48c82c68234c9392dd6b5f83e715aeCERNMSGLS5EX08Bcernerne_-- From nobody Tue Sep 20 22:26:40 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB2912B4EA for ; Mon, 19 Sep 2016 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cerner.com 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 qZ9uf9IraUhy for ; Mon, 19 Sep 2016 14:41:23 -0700 (PDT) Received: from PPLS5Mail2.cernercloud.com (ppls5mail2.cernercloud.com [159.140.193.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF8A12B14F for ; Mon, 19 Sep 2016 14:41:23 -0700 (PDT) Received: from pps.filterd (PPLS5Mail2.cernercloud.com [127.0.0.1]) by PPLS5Mail2.cernercloud.com (8.16.0.17/8.16.0.17) with SMTP id u8JLSYAw014864 for ; Mon, 19 Sep 2016 16:41:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cerner.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201512; bh=8mgX3UT7eM0ql7bNdhIHXvRMj0PtyJDvGvXqxPm1hK4=; b=PWwRnldzy+ROPTIYCaQgBSWMqsGH54Sn6p8zboiAgnNVMyxyhM8B201MNoNzgBSj3BQn b6Oq3M4/qEnEuzJ2p1VoUqahidaK4nWSVlacP4ikBd+M+Knt6BHdM1Hr2Zdo4ZQ7VOjC ySbojcNFNTSrAam0vLradu7/QDLJlLeqs8TvrJXfqWiMI6HUhDSoUOiU17djwFequr6Y SIzna5PH9XvN+PAgk9KJoK1pLQ53ilvWul8CWLJnmMnpZ4eYAm7hQIXN+rNVPJ0Bzx9N YUtR+lN6WdY02VBOf8VDIMP0qcvgE8v62bNyklLMFVcKZpz749C3ZuXLGNzxeZVdWK0m 8A== Received: from cernmsgls5ex08b.cerner.net ([170.71.96.153]) by PPLS5Mail2.cernercloud.com with ESMTP id 25h26f4ag3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 19 Sep 2016 16:41:22 -0500 Received: from CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) by CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 19 Sep 2016 16:41:22 -0500 Received: from CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58]) by CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58%20]) with mapi id 15.00.1178.000; Mon, 19 Sep 2016 16:41:22 -0500 From: "Schooler,Corey" To: "scim@ietf.org" Thread-Topic: [scim] Expected behavior for null JSON values Thread-Index: AQHSEr6PHsf/zHqZ4EehR/AZVr2ATw== Date: Mon, 19 Sep 2016 21:41:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cm-message-id: 14743212642676743699af110dd14039f8e53701e89f8b2b57e05b7041651118030827 x-cm-draft-id: WyJhIiw0LCJkcmFmdF9pZCIsIjE0NzQzMjEyNjQwMDAiLCJ2IiwxXQ== x-mailer: CloudMagic x-cm-tracking-code: 1474321264/64cb1a8b8c0458c9278c43a25aec8eec/7d408c7f05e36c5489b456d42fe29965/041e30c455e4328f08eb62c5b3e6ab72/9efab2399c7c560b34de477b9aa0a465 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [54.210.254.250] Content-Type: multipart/alternative; boundary="_000_aee05446f78d4c3f9654018222061bd7CERNMSGLS5EX08Bcernerne_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-19_13:, , signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 22:26:29 -0700 Subject: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 21:41:28 -0000 --_000_aee05446f78d4c3f9654018222061bd7CERNMSGLS5EX08Bcernerne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was looking for guidance on how a v1.1 Service Provider should handle nul= l values provided within the json for a PATCH request. Example: { "schemas": ["urn:scim:schemas:core:1.0"], "displayName": null } Should the "displayName" attribute be ignored or should it be treated the s= ame as if "displayName" was supplied in "meta.attributes"? CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_aee05446f78d4c3f9654018222061bd7CERNMSGLS5EX08Bcernerne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I was looking for guidance on how a v1.1 Service Provider should handle nul= l values provided within the json for a PATCH request.

Example:
{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "displayName": null
}

Should the “displayName" attribute be ignored or should it be tr= eated the same as if “displayName" was supplied in “meta.a= ttributes"?

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_aee05446f78d4c3f9654018222061bd7CERNMSGLS5EX08Bcernerne_-- From nobody Tue Sep 20 22:26:44 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D412B54A for ; Mon, 19 Sep 2016 14:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cerner.com 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 jN56ZJoDWSkw for ; Mon, 19 Sep 2016 14:49:33 -0700 (PDT) Received: from PPKC2MAIL4.CERNERCLOUD.COM (ppkc2mail4.cernercloud.com [159.140.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9F612B435 for ; Mon, 19 Sep 2016 14:49:33 -0700 (PDT) Received: from pps.filterd (PPKC2MAIL4.CERNERCLOUD.COM [127.0.0.1]) by PPKC2MAIL4.CERNERCLOUD.COM (8.16.0.17/8.16.0.17) with SMTP id u8JLmNAh025316 for ; Mon, 19 Sep 2016 16:49:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cerner.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201512; bh=tl1jKdU++64G4unqCAVn0ePzkcaiiHaRIqldxHVlCnc=; b=uSMUWuV5py8VFDKqQGaTgdRI5vCE7AMMJ7P1zu8Wc0XX3esTM8pcvFzIIMmPxJ6UPCnw Jv2BmLIVl8dU00PfsWjgEZFddTGDTxeEtRWjJFPQ1fCKklj40ZYyalqjXBMb9cozmGnM IbuFcMZkxIwzGn6qbThGPjM51ZMe8kw50i8jUVN995czuhguUHxmRzJTz67U+upYUDcg Iy5iGgDWH0tl0FwTsctd5pT4b9eyWzw2riP2eG+IX6DeckDst8cI8RA406NEUWUoU6Nl wgs+xCf1kTWBtdE7sm3+bf+bx8tDrKgUZMbixX6xyIrLwsSZgfpMbxlD/RXz/ehhIxsc SA== Received: from cernmsgkc2ex08d.cerner.net ([170.71.113.89]) by PPKC2MAIL4.CERNERCLOUD.COM with ESMTP id 25h1e3db2v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 19 Sep 2016 16:49:32 -0500 Received: from CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) by CERNMSGKC2EX08D.cerner.net (2002:aa47:7159::aa47:7159) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 19 Sep 2016 16:49:31 -0500 Received: from CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58]) by CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58%20]) with mapi id 15.00.1178.000; Mon, 19 Sep 2016 16:49:31 -0500 From: "Schooler,Corey" To: "scim@ietf.org" Thread-Topic: [scim] SCIM Provider deletion of multivalued sub-attributes via PATCH Thread-Index: AQHSEr+zP1bgqMIkJk6gXXad8ZfSOg== Date: Mon, 19 Sep 2016 21:49:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cm-message-id: 14743217540284753699af110dd14039f8e53701e89f8b2b57e05d5a06fec129808858 x-cm-draft-id: WyJhIiw0LCJkcmFmdF9pZCIsIjE0NzQzMjE3NTMwMDAiLCJ2IiwxXQ== x-mailer: CloudMagic x-cm-tracking-code: 1474321753/64cb1a8b8c0458c9278c43a25aec8eec/7d408c7f05e36c5489b456d42fe29965/236e6d4448ee71b765c75ecb65970eb5/9efab2399c7c560b34de477b9aa0a465 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [54.210.254.250] Content-Type: multipart/alternative; boundary="_000_cd2ff22be6974bffb452d9e9ba28e0a7CERNMSGLS5EX08Bcernerne_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-19_13:, , signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 22:26:29 -0700 Subject: [scim] SCIM Provider deletion of multivalued sub-attributes via PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 21:49:37 -0000 --_000_cd2ff22be6974bffb452d9e9ba28e0a7CERNMSGLS5EX08Bcernerne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should service providers support the removal of multi-valued sub-attributes= via the PATCH meta.attributes section? example: { "meta": { "attributes": [ "addresses.region", "phoneNumbers.primary" ] } } CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_cd2ff22be6974bffb452d9e9ba28e0a7CERNMSGLS5EX08Bcernerne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Should service providers support the removal of&nbs= p;multi-valued sub-attributes via the PATCH meta.attributes section?

example:
{
    "meta": {
        "attributes": [
            "addresses.region= ”, "phoneNumbers.primary"
        ]
    }
}

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_cd2ff22be6974bffb452d9e9ba28e0a7CERNMSGLS5EX08Bcernerne_-- From nobody Tue Sep 20 22:26:49 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7412B50F for ; Tue, 20 Sep 2016 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cerner.com 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 y0Xbj5eEeXTf for ; Tue, 20 Sep 2016 13:41:18 -0700 (PDT) Received: from PPKC2MAIL5.cernercloud.com (ppkc2mail5.cernercloud.com [159.140.195.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E9B12B52C for ; Tue, 20 Sep 2016 13:41:18 -0700 (PDT) Received: from pps.filterd (PPKC2MAIL5.cernercloud.com [127.0.0.1]) by PPKC2MAIL5.cernercloud.com (8.16.0.17/8.16.0.17) with SMTP id u8KKOJH9006622 for ; Tue, 20 Sep 2016 15:41:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cerner.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201512; bh=UIQ6xdArkGtqV0YT99QJfOoNWpwmuHvFOedVcrRGsr0=; b=gf6513WLQ7dtQh0J0pSyNtRNHeLmmanH8keViCbIE+GQp0X+U4/Ilbp1UWpxrl0Ag5jI g6eelFuB5S/FjvuLoTaxwCkMfrmcTyQVJQ9TY87gD5jXMG7F96pIiL3B3haW8KkOQYBM xznTdP9/K8Ct7KJlVpafpH7MYihMKK1MYtdAs7hPHiwH8PlVKuGR4o9jWjOl9jaOUpFt eAa3eNWp9dnVkcMFYc1R2FmWruwlvag19ict3h5wfG/yu59Kk5WwPPTn8zXiCs0moMMR xRn9y5yicXbtBFPSjWaZZLTtQaxmHlJXZ3hYfNS4v//XJc4pUsZ682jHu1msKP68ez5S vQ== Received: from cernmsgkc2ex08c.cerner.net ([170.71.113.88]) by PPKC2MAIL5.cernercloud.com with ESMTP id 25h2tn5xa7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Tue, 20 Sep 2016 15:41:17 -0500 Received: from CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) by CERNMSGKC2EX08C.cerner.net (2002:aa47:7158::aa47:7158) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 15:41:16 -0500 Received: from CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58]) by CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58%20]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 15:41:16 -0500 From: "Schooler,Corey" To: "scim@ietf.org" Thread-Topic: [scim] Expected behavior for null JSON values Thread-Index: AQHSE39UH2t+bgT/P0Kg0x1W90WK3w== Date: Tue, 20 Sep 2016 20:41:16 +0000 Message-ID: <03aeb98140284ccda68982c49faf2b16@CERNMSGLS5EX08B.cerner.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cm-message-id: 147440405880033657b24f7b72ebc51af70bc46960cc131957e19edac36ff1671406909 x-cm-draft-id: WyJhIiw0LCJkcmFmdF9pZCIsIjE0NzQ0MDQwNTgwMDAiLCJ2IiwxXQ== x-mailer: CloudMagic x-cm-tracking-code: 1474404058/64cb1a8b8c0458c9278c43a25aec8eec/7d408c7f05e36c5489b456d42fe29965/93f3210816a3dbd664d0e643f2b81c5e/9efab2399c7c560b34de477b9aa0a465 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [54.210.254.130] Content-Type: multipart/alternative; boundary="_000_03aeb98140284ccda68982c49faf2b16CERNMSGLS5EX08Bcernerne_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-20_08:, , signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 22:26:30 -0700 Subject: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 20:41:21 -0000 --_000_03aeb98140284ccda68982c49faf2b16CERNMSGLS5EX08Bcernerne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was looking for guidance on how a v1.1 Service Provider should handle nul= l values provided within the json for a PATCH request. Example: { "schemas": ["urn:scim:schemas:core:1.0"], "displayName": null } Should the "displayName" attribute be ignored or should it be treated the s= ame as if "displayName" was supplied in "meta.attributes"? CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_03aeb98140284ccda68982c49faf2b16CERNMSGLS5EX08Bcernerne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I was looking for guidance on how a v1.1 Service Provider should handle nul= l values provided within the json for a PATCH request.

Example:
{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "displayName": null
}

Should the “displayName" attribute be ignored or should it be tr= eated the same as if “displayName" was supplied in “meta.a= ttributes"?

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_03aeb98140284ccda68982c49faf2b16CERNMSGLS5EX08Bcernerne_-- From nobody Tue Sep 20 22:26:51 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEAF12B52C for ; Tue, 20 Sep 2016 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cerner.com 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 q3b-zuRvCYIy for ; Tue, 20 Sep 2016 13:41:44 -0700 (PDT) Received: from PPLS5MAIL1.cernercloud.com (ppls5mail1.cernercloud.com [159.140.193.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A75E12B50F for ; Tue, 20 Sep 2016 13:41:44 -0700 (PDT) Received: from pps.filterd (PPLS5MAIL1.cernercloud.com [127.0.0.1]) by PPLS5MAIL1.cernercloud.com (8.16.0.17/8.16.0.17) with SMTP id u8KKO41h017781 for ; Tue, 20 Sep 2016 15:41:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cerner.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201512; bh=ABPS/ybeBe1sYm0hv/owBWrJa6ieUih/1Gs1JMWHvE0=; b=AIvNqGbdC6bcM8tlkq+xAri8g6mGU2kxCBd1dk0/wR4DH/Dm0MGmxZOYY/QG2MqG6XvN Xex3lgKGdotQI73W9u+CVky/0ykZ/GqOogtBznXxgEdz2UasLQsa7GBiEqML0Qd9Bb1M OTLmWZI+MJG7okEKis/8IFX3J8CsKajoAVhIx8KdA6/634BzK789nZE0IghxSu5iMoPS m6LGlSkJetCH2qTokzv27rsiJm0JLUNQRSMcEsLWCa6BXgIjeTy0w0ze+VBn9OIGc5pj rsPL/IhARTtmjt6pMc7klk6HY60S1z0eY90SECcnrOcxQeQt6BTeHv3/0tiPdK3TK3c5 XQ== Received: from cernmsgkc2ex08d.cerner.net ([170.71.113.89]) by PPLS5MAIL1.cernercloud.com with ESMTP id 25k6p3y6gk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Tue, 20 Sep 2016 15:41:43 -0500 Received: from CERNMSGLS5EX08B.cerner.net (2002:aa47:6099::aa47:6099) by CERNMSGKC2EX08D.cerner.net (2002:aa47:7159::aa47:7159) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 15:41:42 -0500 Received: from CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58]) by CERNMSGLS5EX08B.cerner.net ([fe80::1181:5a1b:79b5:1c58%20]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 15:41:42 -0500 From: "Schooler,Corey" To: "scim@ietf.org" Thread-Topic: [scim] SCIM Provider deletion of multivalued sub-attributes via PATCH Thread-Index: AQHSE39kXERwEjfKhkmtJlDszF4MzQ== Date: Tue, 20 Sep 2016 20:41:42 +0000 Message-ID: <28d03f02bb694a26bf8c42938d44cd68@CERNMSGLS5EX08B.cerner.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cm-message-id: 147440408494504857b24f7b72ebc51af70bc46960cc131957e19ef4e6c452141205070 x-cm-draft-id: WyJhIiw0LCJkcmFmdF9pZCIsIjE0NzQ0MDQwODQwMDAiLCJ2IiwxXQ== x-mailer: CloudMagic x-cm-tracking-code: 1474404084/64cb1a8b8c0458c9278c43a25aec8eec/7d408c7f05e36c5489b456d42fe29965/80ad083bec50a80adfab4a8c15f4c1bc/9efab2399c7c560b34de477b9aa0a465 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [54.210.254.130] Content-Type: multipart/alternative; boundary="_000_28d03f02bb694a26bf8c42938d44cd68CERNMSGLS5EX08Bcernerne_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-20_08:, , signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 22:26:30 -0700 Subject: [scim] SCIM Provider deletion of multivalued sub-attributes via PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 20:41:45 -0000 --_000_28d03f02bb694a26bf8c42938d44cd68CERNMSGLS5EX08Bcernerne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should service providers support the removal of multi-valued sub-attributes= via the PATCH meta.attributes section? example: { "meta": { "attributes": [ "addresses.region", "phoneNumbers.primary" ] } } CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_28d03f02bb694a26bf8c42938d44cd68CERNMSGLS5EX08Bcernerne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Should service provid= ers support the removal of multi-valued sub-attributes via the PATCH m= eta.attributes section?

example:
{
    "meta": {
        "attributes": [
            "addresses.region”, &q= uot;phoneNumbers.primary"
        ]
    }
}

CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_28d03f02bb694a26bf8c42938d44cd68CERNMSGLS5EX08Bcernerne_-- From nobody Fri Sep 23 12:08:28 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD14E12B24F for ; Fri, 23 Sep 2016 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BDFpNWoTj64h for ; Fri, 23 Sep 2016 12:08:25 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD9012B1C9 for ; Fri, 23 Sep 2016 12:08:25 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 15so55245006uai.3 for ; Fri, 23 Sep 2016 12:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qMqpY9vM9Af6Fbc+n05DH+bPhZwcp4vTBj8e8n4ZiuM=; b=JkrX/iA2DaEENCWtDWsqIq5xOjGk+1a8ARJAdVywc84NOCkQLvlylSUHs460EuBkbV xqjXO9DsWz0YfnqnAf40meP20GbnyNZKgAF3hjj/bZaZ/FfgV6SRjCQCw8BhpxQHGxFt owrUPSD4HZi+1UUONPyG9uVcOnajojLt85vjHj6xOSJ+I7au9qMlhFvWPaD1P7Nuv+SW sbno8ljcQk9f3E9JzhAGH7y7i/AFFRgTktbbGMocy+SVFAsdmp/xSzD11oQOa0GKYxBE R845uNdxoSGqXNHboLOrs57aww7FnGBVynIJFqN8QPBFh+idBAc+61QKbpXdiugOJsB/ fG4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qMqpY9vM9Af6Fbc+n05DH+bPhZwcp4vTBj8e8n4ZiuM=; b=VGD9y1AT9octh6RK9R5LdIWcBEv1YTo6DjvdxS47D+D/de1LUL0+CjmudzsMVDvdMr fJjsegK+G3XcO2al8sEqaIZx9nU4+WENEPjL8yM4ccFscJ2kzzu/o1KsP0/9vY3CasXI 87k1ywl2ZeCrNEpgbWpBylwb3zjOZU6eh8RdHN81NEAzP2XTj+EYiIIceOyxt+L6Oux6 WB2/B2ADsJr7oHxIsBGHrnvsrwMFodAShm6+Q2memNrji/xw6zfvbCI4chjykO3azl1/ cRgHKnHN5h7Tj4tkS8cyEgAh2mtoD0V0wTvo+4MmZ2wR9xqeRs8tgpzSIcV+HYbNU+sN V8ow== X-Gm-Message-State: AE9vXwN6FWJBZcDQLI/stQR3Ly/lZulYpLb9Wm+qnOeHq6lEuy2TLt0dmtk+VIAsgV2pBqondwo6fKyz9Gg9tA== X-Received: by 10.159.36.79 with SMTP id 73mr5429059uaq.98.1474657704227; Fri, 23 Sep 2016 12:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.141.17 with HTTP; Fri, 23 Sep 2016 12:08:23 -0700 (PDT) In-Reply-To: References: From: Shelley Date: Fri, 23 Sep 2016 14:08:23 -0500 Message-ID: To: "Schooler,Corey" Content-Type: multipart/alternative; boundary=001a113db798a03a7e053d3180c7 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:08:27 -0000 --001a113db798a03a7e053d3180c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd propose that Service Providers should simply ignore null attributes in PATCH requests. Attributes should only be removed via the meta.attributes attribute. On Thu, Sep 15, 2016 at 10:42 AM, Schooler,Corey wrote: > I was looking for guidance on how a v1.1 Service Provider should handle > null values provided within the json for a PATCH request. > > Example: > { > "schemas": ["urn:scim:schemas:core:1.0"], > "displayName": null > } > > Should the =E2=80=9CdisplayName" attribute be ignored or should it be tre= ated the > same as if =E2=80=9CdisplayName" was supplied in =E2=80=9Cmeta.attributes= "? > CONFIDENTIALITY NOTICE This message and any included attachments are from > Cerner Corporation and are intended only for the addressee. The informati= on > contained in this message is confidential and may constitute inside or > non-public information under international, federal, or state securities > laws. Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you are n= ot > the addressee, please promptly delete this message and notify the sender = of > the delivery error by e-mail or you may call Cerner's corporate offices i= n > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a113db798a03a7e053d3180c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd propose that Service Providers should simply ignor= e null attributes in= PATCH requests. Attributes should only be removed via the meta.attributes attribute.
=

On Thu, Sep 15, 2= 016 at 10:42 AM, Schooler,Corey <Corey.Schooler@cerner.com>= wrote:
I was looking for guidance on how a v1.1 Service Provider should handl= e null values provided within the json for a PATCH request.

Example:
{
=C2=A0 "schemas": ["urn:scim:schemas:core:1.0"],
=C2=A0 "displayName": null
}

Should the =E2=80=9CdisplayName" attribute be ignored or should i= t be treated the same as if =E2=80=9CdisplayName" was supplied in =E2= =80=9Cmeta.attributes"?
CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.

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


--001a113db798a03a7e053d3180c7-- From nobody Fri Sep 23 12:35:38 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B912B5FA for ; Fri, 23 Sep 2016 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9HTXT42M954f for ; Fri, 23 Sep 2016 12:35:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A08112B60A for ; Fri, 23 Sep 2016 12:35:34 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8NJZVSw018139 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Sep 2016 19:35:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u8NJZVaQ013173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2016 19:35:31 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u8NJZSgB003878; Fri, 23 Sep 2016 19:35:30 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2016 12:35:28 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_BC0ECE98-BEB8-4180-99BE-BF126B31797B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Fri, 23 Sep 2016 12:35:27 -0700 Message-Id: References: To: Shelley X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org" , "Schooler, Corey" Subject: Re: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:35:36 -0000 --Apple-Mail=_BC0ECE98-BEB8-4180-99BE-BF126B31797B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 + 1 This kind of unspecified stuff was some of the shortcomings of 1.1 that = made interop hard. You really have to test major implementers to see what they do from a = defacto perspective. Also, when it comes to =E2=80=9CPUT=E2=80=9D you may find similar = issues. What does a missing attribute or null attribute mean? Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 23, 2016, at 12:08 PM, Shelley wrote: >=20 > I'd propose that Service Providers should simply ignore null = attributes in PATCH requests. Attributes should only be removed via the = meta.attributes attribute. >=20 > On Thu, Sep 15, 2016 at 10:42 AM, Schooler,Corey = > wrote: >=20 > I was looking for guidance on how a v1.1 Service Provider should = handle null values provided within the json for a PATCH request. >=20 > Example: > { > "schemas": ["urn:scim:schemas:core:1.0"], > "displayName": null > } >=20 > Should the =E2=80=9CdisplayName" attribute be ignored or should it be = treated the same as if =E2=80=9CdisplayName" was supplied in = =E2=80=9Cmeta.attributes"? > CONFIDENTIALITY NOTICE This message and any included attachments are = from Cerner Corporation and are intended only for the addressee. The = information contained in this message is confidential and may constitute = inside or non-public information under international, federal, or state = securities laws. Unauthorized forwarding, printing, copying, = distribution, or use of such information is strictly prohibited and may = be unlawful. If you are not the addressee, please promptly delete this = message and notify the sender of the delivery error by e-mail or you may = call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) = (816)221-1024 . >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_BC0ECE98-BEB8-4180-99BE-BF126B31797B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 + 1

This = kind of unspecified stuff was some of the shortcomings of 1.1 that made = interop hard.

You = really have to test major implementers to see what they do from a = defacto perspective.

Also, when it comes to =E2=80=9CPUT=E2=80=9D you may find = similar issues.  What does a missing attribute or null attribute = mean?




On Sep 23, 2016, at 12:08 PM, Shelley <randomshelley@gmail.com> wrote:

I'd propose that Service Providers should simply ignore null = attributes in PATCH requests. Attributes should only be removed = via the meta.attributes attribute.

On Thu, = Sep 15, 2016 at 10:42 AM, Schooler,Corey <Corey.Schooler@cerner.com> = wrote:
I was looking for guidance on how a v1.1 Service = Provider should handle null values provided within the json for a PATCH = request.

Example:
{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "displayName": null
}

Should the =E2=80=9CdisplayName" attribute be ignored or = should it be treated the same as if =E2=80=9CdisplayName" was supplied = in =E2=80=9Cmeta.attributes"?
CONFIDENTIALITY NOTICE This message and any included attachments are = from Cerner Corporation and are intended only for the addressee. The = information contained in this message is confidential and may constitute = inside or non-public information under international, federal, or state = securities laws. Unauthorized forwarding, printing, copying, = distribution, or use of such information is strictly prohibited and may = be unlawful. If you are not the addressee, please promptly delete this = message and notify the sender of the delivery error by e-mail or you may = call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

_______________________________________________
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=_BC0ECE98-BEB8-4180-99BE-BF126B31797B-- From nobody Fri Sep 23 12:48:47 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A204C12B186 for ; Fri, 23 Sep 2016 12:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l1rmEHlvs4M3 for ; Fri, 23 Sep 2016 12:48:40 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF69512B22C for ; Fri, 23 Sep 2016 12:48:38 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 107so56353227uah.2 for ; Fri, 23 Sep 2016 12:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n9uOQfqWAxZ2pTjUO8uXUYhaELEipZ2jfLy0JtaM8kA=; b=Ajxbjjme0G+4g1Vmg1dNHbMyA8To/u+N0Snw754fOjmQOV+ogaC0+afKm8KafEmRKl FnyyONIoJylGH0npCo/c8gtHg88RFNtHAf7NIXOMQBC4EUNmGcseDnjamtrKj7+7cvRL SDnlL3ju4bQl2WmSxHzFQsa7RxWqy1fGiTniBzXstdnB/Se0iLisZ56lxf5okgadTsNt 9CiUxYAvCNshFBDjoVZ1zmie58N2h3/xOiHp+wwFBF6turoSSdztXreBXBltL8n/BOLu pXXFBSkBP+PJlHm/MuU0wBGWbVETbvdjMUizRC0lxWhF7nn7emt2RJyacTvhbT8Ld31l G2dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n9uOQfqWAxZ2pTjUO8uXUYhaELEipZ2jfLy0JtaM8kA=; b=e+0NgAAg3CbeMAtGpDhAgwj1elBFgto2q614504+tqzoSUhbkyblZK3yiBWDzxEq25 lwRwucFIw8/MUMz8P2ZJ8tbDYXyHakidIDMVufv/WcBz7MAK4lfza+lPBorbZkh+AJ1G yyrqrJYS87HkMD/fnLJ82o+MMhTtXMvOfw4+gmcfz8Ykmkez6sf8oJa0H1hTFf3EwnyU MmYISUzgRE8ZuatwK6SP7bFuDheN7YviHUf+13ZlKUiL4k1xfTZfQOfW5rIBD9Dw0hoj rkSrjJqlyKYNbmPQz/tRfO+YuIy1cMGep4vK0EGxTUvYfGEskdFXPntrQ2ZX7THL6HGl FW4A== X-Gm-Message-State: AE9vXwMHQ3UIN1Nje1YtUpYQ/py12iCfg1a79iYkiyrcr1jhEZMuuCdBt3vPXeLCJ51+BU5YtIt4EdsttKsUMw== X-Received: by 10.159.34.84 with SMTP id 78mr6090477uad.50.1474660117930; Fri, 23 Sep 2016 12:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.141.17 with HTTP; Fri, 23 Sep 2016 12:48:37 -0700 (PDT) In-Reply-To: References: From: Shelley Date: Fri, 23 Sep 2016 14:48:37 -0500 Message-ID: To: "Schooler,Corey" Content-Type: multipart/alternative; boundary=001a113f9f807e6986053d321069 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Provider deletion of multivalued sub-attributes via PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:48:43 -0000 --001a113f9f807e6986053d321069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Neither the PATCH documentation [1], attribute notation [2], nor filter documentation [3] include any examples nor clarification regarding multi-valued sub-attributes, so I'd be curious to know the specification's intent with respect to this as well and/or the expectations from other service providers / consumers. I can't think of too many use cases for removing multi-valued sub-attributes with the core schema via PATCH (update all emails so that none are primary? remove the formatted addresses from all addresses?), and can only think of a couple potential use cases for referencing sub-attributes via filtering (e.g. return all users that live in a particular country); however, it would be good to get some clarification on whether these should still be supported, and if so, confirmation as to how these attributes should be notated. [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-with= -patch [2] http://www.simplecloud.info/specs/draft-scim-api-01.html#attribute-notation [3] http://www.simplecloud.info/specs/draft-scim-api-01.html#rfc.section.3.2.2.= 1 On Mon, Sep 19, 2016 at 4:49 PM, Schooler,Corey wrote: > Should service providers support the removal of multi-valued > sub-attributes via the PATCH meta.attributes section? > > example: > { > "meta": { > "attributes": [ > "addresses.region=E2=80=9D, "phoneNumbers.primary" > ] > } > } > > CONFIDENTIALITY NOTICE This message and any included attachments are from > Cerner Corporation and are intended only for the addressee. The informati= on > contained in this message is confidential and may constitute inside or > non-public information under international, federal, or state securities > laws. Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you are n= ot > the addressee, please promptly delete this message and notify the sender = of > the delivery error by e-mail or you may call Cerner's corporate offices i= n > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a113f9f807e6986053d321069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Neither the PATCH documentation [1], attribute notation [2= ], nor filter documentation [3] include any examples nor clarification rega= rding multi-valued sub-attributes, so I'd be curious to know the specif= ication's intent with respect to this as well and/or the expectations f= rom other service providers / consumers.

I can't think of too ma= ny use cases for removing multi-valued sub-attributes with the core schema = via PATCH (update all emails so that none are primary? remove the formatted= addresses from all addresses?), and can only think of a couple potential u= se cases for referencing sub-attributes via filtering (e.g. return all user= s that live in a particular country); however, it would be good to get some= clarification on whether these should still be supported, and if so, confi= rmation as to how these attributes should be notated.

[1] http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-reso= urce-with-patch
[2] http://www.simplecloud.info/specs/d= raft-scim-api-01.html#attribute-notation
[3] http://ww= w.simplecloud.info/specs/draft-scim-api-01.html#rfc.section.3.2.2.1
=

On Mon, Sep= 19, 2016 at 4:49 PM, Schooler,Corey <Corey.Schooler@cerner.com> wrote:
Should service providers support the removal of=C2= =A0multi-valued sub-attributes via the PATCH meta.attributes section?

example:
{
=C2=A0 =C2=A0=C2=A0"meta": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "attributes": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "addresses.region= =E2=80=9D, "phoneNumbers.primary"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 }
}


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


--001a113f9f807e6986053d321069-- From nobody Fri Sep 23 12:59:47 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9551E12B1C9 for ; Fri, 23 Sep 2016 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eXH3KkOi54P9 for ; Fri, 23 Sep 2016 12:59:44 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D901712B199 for ; Fri, 23 Sep 2016 12:59:43 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 15so56493377uai.3 for ; Fri, 23 Sep 2016 12:59: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:from:date:message-id:subject:to :cc; bh=rFbVPSD3bKXaPjPmZBSqfREc6c2Es1w+rJ9r8aKBcTo=; b=D0z3z9LkKz/OzwQ5LxChLQOy9sFQeSsBFPkx30Ntr/XyvEbWAHC/J+xKygg8FTUIHr bsYcNJJycZDZ5O42dspVXg6ZYdv4rr0CC1L2GNry5I/zZoc4zx15IasHlX+G5lWaemKn fNJ6C33L6NuMYizeKSfMbe4pa1gZpSwALWb4L4yOTiGM5g1jJXIwRWhE5gbwVKWbvK7V wa0gyimYpwUij1+IS1Iixb0aWVTqL/QV5tTlXE26Ba1qL81EfeKy5vxIbD4QE3sSj3mZ eGzdPQl861bAjNzxyH0xVxc1OL3CKZeOaogeuztYP+3S+8lPPVZiyxOShimEjryFbxJo m9HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rFbVPSD3bKXaPjPmZBSqfREc6c2Es1w+rJ9r8aKBcTo=; b=KfM6/ngrUkMwGXf6/VsT3TE3YrekwMTYuWW3xNVOcFlIDqs2R+Fe98//tZrqi53VLn +njT0AX7xYWW9GnlIsPr0n1SHJE9u9i3DX2PkWCXlVk47IKVj7Yvu7FBuATNczYXu4th ElxFRE+BlY7Xj63tWPqKfttqW6eSSW13RwWLH+MxEGZzctDIgaldXVdKAw2vFE3Yv1WK NkUoM2tGAQHVhR/GrdlcMZADZGlnsSX7CKSpYNQlzh4E9EiB8z9U9HeON7m4n4HI3AzV EnL3V90mAVRNaf3Jrt0vhK3NymJhnmm4/mwCs7ZVnRnqGIxj2nrRfNiEq2vXrdxxLRbj ZV8A== X-Gm-Message-State: AA6/9RmavyADyA7MvMc3SpqdKlFMNgyOGkVEdQSIzc9zaDVQS+7jJvZNzRDs3RZbvTsEgePVr2iM9YzcpWIs7g== X-Received: by 10.159.36.52 with SMTP id 49mr5781458uaq.45.1474660782934; Fri, 23 Sep 2016 12:59:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.141.17 with HTTP; Fri, 23 Sep 2016 12:59:42 -0700 (PDT) In-Reply-To: References: From: Shelley Date: Fri, 23 Sep 2016 14:59:42 -0500 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c15d7c219079053d323803 Archived-At: Cc: "scim@ietf.org" , "Schooler, Corey" Subject: Re: [scim] Expected behavior for null JSON values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:59:46 -0000 --001a11c15d7c219079053d323803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PATCH is a little bit different since it represents only a partial resource, so a consumer might think that explicitly providing null for an attribute will actually set the attribute to null (whereas with a full resource representation in POST/PUT, a null attribute is essentially the same thing as not providing the attribute). Despite this ambiguity, for simplicity/consistency across all methods (POST/PUT/PATCH), and in alignment with the purpose of the meta.attributes, my vote is to ignore missing/null attributes for PATCH. On Fri, Sep 23, 2016 at 2:35 PM, Phil Hunt wrote: > + 1 > > This kind of unspecified stuff was some of the shortcomings of 1.1 that > made interop hard. > > You really have to test major implementers to see what they do from a > defacto perspective. > > Also, when it comes to =E2=80=9CPUT=E2=80=9D you may find similar issues.= What does a > missing attribute or null attribute mean? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Sep 23, 2016, at 12:08 PM, Shelley wrote: > > I'd propose that Service Providers should simply ignore null attributes > in PATCH requests. Attributes should only be removed via the > meta.attributes attribute. > > On Thu, Sep 15, 2016 at 10:42 AM, Schooler,Corey < > Corey.Schooler@cerner.com> wrote: > >> I was looking for guidance on how a v1.1 Service Provider should handle >> null values provided within the json for a PATCH request. >> >> Example: >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "displayName": null >> } >> >> Should the =E2=80=9CdisplayName" attribute be ignored or should it be tr= eated the >> same as if =E2=80=9CdisplayName" was supplied in =E2=80=9Cmeta.attribute= s"? >> CONFIDENTIALITY NOTICE This message and any included attachments are fro= m >> Cerner Corporation and are intended only for the addressee. The informat= ion >> contained in this message is confidential and may constitute inside or >> non-public information under international, federal, or state securities >> laws. Unauthorized forwarding, printing, copying, distribution, or use o= f >> such information is strictly prohibited and may be unlawful. If you are = not >> the addressee, please promptly delete this message and notify the sender= of >> the delivery error by e-mail or you may call Cerner's corporate offices = in >> Kansas City, Missouri, U.S.A at (+1) (816)221-1024. >> >> _______________________________________________ >> 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 > > > --001a11c15d7c219079053d323803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PATCH is a little bit different since it represents o= nly a partial resource, so a consumer might think that explicitly providing= null for an attribu= te will actually set the attribute to null (whereas with a full resource representation in POST= /PUT, a null attribu= te is essentially the same thing as not providing the attribute).

Despite this ambiguity, for simplicity/consistency across all methods (= POST/PUT/PATCH), and in alignment with the purpose of the meta.attributes, my vote is to ignore= missing/null attrib= utes for PATCH.


On Fri, Sep 23, 2016 at 2:35 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
+ 1

This kind of unspecified stuf= f was some of the shortcomings of 1.1 that made interop hard.

You really have to test major implementers to see what they do from a= defacto perspective.

Also, when it comes to =E2= =80=9CPUT=E2=80=9D you may find similar issues.=C2=A0 What does a missing a= ttribute or null attribute mean?


On Sep 23, 2016, at 12:08 PM, Shell= ey <randoms= helley@gmail.com> wrote:

I'd prop= ose that Service Providers should simply ignore null attributes in PATCH requests. Attributes s= hould only be removed via the meta.attributes attribute.
On Thu, Sep 15, 2016 at 10:42 AM, Schooler,Cor= ey <Corey.Schooler@cerner.com> wrote:
I was looking for guidance on how a v1.1 Service Provider should handl= e null values provided within the json for a PATCH request.

Example:
{
=C2=A0 "schemas": ["urn:scim:schemas:core:1.0"],
=C2=A0 "displayName": null
}

Should the =E2=80=9CdisplayName" attribute be ignored or should i= t be treated the same as if =E2=80=9CdisplayName" was supplied in =E2= =80=9Cmeta.attributes"?
CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.

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


_______________________________________________
scim mailing listscim@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/scim" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/scim


--001a11c15d7c219079053d323803-- From nobody Fri Sep 23 13:01:09 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2812B349 for ; Fri, 23 Sep 2016 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Cn4qAyTxeldJ for ; Fri, 23 Sep 2016 13:01:02 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B778D12B2A1 for ; Fri, 23 Sep 2016 13:01:02 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id z126so898159vkd.0 for ; Fri, 23 Sep 2016 13:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oms70cz8HxUrfhUHdYPCx3UK/u3v1umvWPHnD07kBIE=; b=iQYecHHLgL8+XCtWHoNyBBBxNJnHF/vYbDcQuYPdZZn6lDwACZEz+mkMd+5M1PHROZ haNg1ImXt0jfk/gjhkJcmN93J5M+A3ZLCfW8Elsj8WXhNJtLxSXdEgx/jFUtlIzYSXuD Y7Mi0NiMMRoQoLPzgXJlvIOy0jnv7XaNah29/acT8FmfyqpEOSTH2Z4PltN7LBytQbi1 riBF1mOgGnwq+yA6Do8KGJg3rVZDsqxC4szYi3vu3YMSTWo9Lr3ZLgtBsTBFoX+7py+f ouLm7V2m3wzD221iz/OXRcUPUwOhf9k7hY70+bTkUCHAq+Y4fPmVhvESIAg5Oqa2PDya bQUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oms70cz8HxUrfhUHdYPCx3UK/u3v1umvWPHnD07kBIE=; b=XqGPtIija04VscJljR+Kbvp2K6PbfGv8Np0EOQgUg0B37fS2o+RqcRFamBuVTgxTS8 IMhxRmr3Sr44GwCQA75NhaVxKXpOwHhD5cT+KL2fLcvVfnrAfo+Yr81cFpEyJOGAy2xA CzpKkHfILMWAi5XHiHo4UlHCCE+6ewb/NOTypGpvm05lHMcR/Kn2gyZSL9++aCoP07x3 CBfPLK5e9obUw1XF1VBztkkA7NJ58WtURdFKLE3vaLHuBsopBYn5ZTqdXK3kf9LsFD6l VojHC7ZNt0AMCLFF8fcDLNIGwkYf/JH1qulb/tZFIwe9UwQx7jpPyRw8z5gJNQ8FfIJC 2xvg== X-Gm-Message-State: AA6/9RnfYHBPr7WAELan/W5n3W+uMI1K2euT+5DSBMrCSIfixXrCatUQsNpX33prNEUlgBPvY+U5zXt0riodYw== X-Received: by 10.31.163.134 with SMTP id m128mr146717vke.70.1474660861938; Fri, 23 Sep 2016 13:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.141.17 with HTTP; Fri, 23 Sep 2016 13:01:01 -0700 (PDT) In-Reply-To: References: From: Shelley Date: Fri, 23 Sep 2016 15:01:01 -0500 Message-ID: To: Matt Randall Content-Type: multipart/alternative; boundary=001a1142d3c4d712ea053d323c84 Archived-At: Cc: "scim@ietf.org" , "dclippard@cerner.com" , shelley.baker@cerner.com Subject: Re: [scim] www-form-url-encoding for query parameters? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 20:01:05 -0000 --001a1142d3c4d712ea053d323c84 Content-Type: text/plain; charset=UTF-8 +1 to Matt's proposal: > The most straightforward way to prevent the ambiguity is to simply declare "+" as a reserved character for SCIM query string implementations, such that > consumers are required to encode plus signs as %2B, and advising SCIM providers to treat "+" characters as spaces for backwards compatibility. > > On Mon, Sep 12, 2016 at 3:47 PM, Matt Randall wrote: > Just for those following along, here's an example of where it is necessary > to know if the incoming request was encoded using x-www-form-urlencoded > rules, or using the basic URI rules allowing for the reserved characters > "&" and "=". An x-www-form-urlencoded implementation could send: > > ?filter=meta.lastModified+le+"2011-05-13T04:42:34%2B05:00" > > Using x-www-form-urlencoded rules, this value of "filter" would be > interpreted as: > > meta.lastModified le "2011-05-13T04:42:34+05:00" > > Using only the rules provided in the SCIM spec, the value of "filter" > would be interpreted as: > > meta.lastModified+le+"2011-05-13T04:42:34+05:00" > > Alternatively, a client could decide not to use x-www-form-urlencoded > rules and might send: > > ?filter=meta.lastModified%20le%20"2011-05-13T04:42:34+05:00" > > Using x-www-form-urlencoded rules, this value of "filter" would be > interpreted as: > > meta.lastModified le "2011-05-13T04:42:34 05:00" > > Using only the rules provided in the SCIM spec, the value of "filter" > would be interpreted as: > > meta.lastModified le "2011-05-13T04:42:34+05:00" > > The most straightforward way to prevent the ambiguity is to simply declare "+" as a reserved character for SCIM query string implementations, such that consumers are > required to encode plus signs as %2B, and advising SCIM providers to treat "+" characters as spaces for backwards compatibility. > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1142d3c4d712ea053d323c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Matt's proposal:
The most straightforward way to prevent the ambiguity is to simply d=
eclare "+" as a reserved character for SCIM query string implemen=
tations, such that 
consumers are required to encode plus signs as %2B, =
and advising SCIM providers to treat "+" characters as spaces for=
 backwards compatibility.


On Mon, Sep 12, 2016 at 3:47 PM= , Matt Randall <matthew.a.randall@gmail.com> wrote= :
Just for those followi= ng along, here's an example of where it is necessary to know if the inc= oming request was encoded using x-www-form-urlencoded rules, or using the b= asic URI rules allowing for the reserved characters "&" and &= quot;=3D".=C2=A0 An x-www-form-urlencoded implementation could send:
?filter=3Dmeta.lastModified+le+"=
;2011-05-13T04:42:34%2B05:00"
Using x-www-form-urlenco= ded rules, this value of "filter" would be interpreted as:
meta.lastModified le "2011-05-13T04:42:34= +05:00"Using only the rules provided in the SCIM spec, the value= of "filter" would be interpreted as:
meta.lastModified+le+"2011-05-13T04:42:34+05:00"Alternatively, a client could decide not to use x-www-form-urlencoded rul=
es and might send:
?filter=3Dmeta.l=
astModified%20le%20"2011-05-13T04:42:34+05:00"
Using x-www-form-urlencoded rules, this value of &quo=
t;filter" would be interpreted as:
=
meta.lastModified le "2011-05-13T04:42:34 05:00"
Using only =
the rules provided in the SCIM spec, the value of "filter" would =
be interpreted as:
meta.lastModified le =
"2011-05-13T04:42:34+05:00"

The most straightforward way to prevent t=
he ambiguity is to simply declare "+" as a reserved character for=
 SCIM query string implementations, such that consumers are 
required to=
 encode plus signs as %2B, and advising SCIM providers to treat "+&quo=
t; characters as spaces for backwards compatibility.



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


--001a1142d3c4d712ea053d323c84-- From nobody Wed Sep 28 07:08:23 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95312B62C for ; Wed, 28 Sep 2016 07:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com 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 sQDe1ZpeYvmi for ; Wed, 28 Sep 2016 07:08:21 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBA112B64C for ; Wed, 28 Sep 2016 07:07:15 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z126so44974343vkd.0 for ; Wed, 28 Sep 2016 07:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=PsfhKcTdR9hWeaR10zeNjbR7OnIAdp3fvGZeuAexXN0=; b=bTjWtKmcb6p9SrVE42YbDZ1NwRAf1qL4N4WYd58vmWB+//k4SrclG8JPWhE3Q/FpgD 80pcIr8/+c7PWRPqhuy6ywsRY85XKm7xzAWsVu9LpjmFcyOSMMQaO4+SKFfGm2rBCRtP bMAUx8602bYqsCLw9U7dX+3Qy2bDogDppQ5gU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PsfhKcTdR9hWeaR10zeNjbR7OnIAdp3fvGZeuAexXN0=; b=BTYZrcvXZ2m2zArIzajPq0VDVUbP2VFS+K59iqoCGzO+68OECK/YkaUKLCcbVmT0Jo FyGRUsvH/f5TlLSGG+NwzV6haIC4xi6UPXgpfQwRxjZqm6hU+ATP0yjExLTUlQcsdQ/x jI01WvFvo6Dxu0UzXNrVXdPq8Gex63q9FIs/qEpVSsUwu4VH5LeqLwjic6PU43x7jWJi z0+TV1uDgzSznL8ynA888PL3b3CDb2ZfO2b+riblJCs8vGKgPnIwPid+l5QOfXjI0ze6 UUSRMqp0RFMsj6raX9FBrSfAr3pcstS0l3kYrDwDCU2RdWHL5RwEJtvoaof2EwAEBwBz frUA== X-Gm-Message-State: AA6/9RnHpCUUR9EJ2zLh8nwBwPsz8+OTt6Zsvt8xkrW22IqhLCtvXfZrePfHBSHB9+CAAi0Or6TWBs4BNfNOVAWK X-Received: by 10.31.63.86 with SMTP id m83mr13905375vka.103.1475071633760; Wed, 28 Sep 2016 07:07:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.23 with HTTP; Wed, 28 Sep 2016 07:06:53 -0700 (PDT) From: Ian Glazer Date: Wed, 28 Sep 2016 10:06:53 -0400 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=001a114dc2eabfe811053d91e05f Archived-At: Subject: [scim] Another v2 interop? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 14:08:22 -0000 --001a114dc2eabfe811053d91e05f Content-Type: text/plain; charset=UTF-8 Gang - Anyone have interest in doing another interop ahead of Gartner IAM Summit in late November? There's an opportunity to do a small readout during Erik Wahlstrom's tutorial before the conference proper. i -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a114dc2eabfe811053d91e05f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gang -

Anyone have interest in doing an= other interop ahead of Gartner IAM Summit in late November? There's an = opportunity to do a small readout during Erik Wahlstrom's tutorial befo= re the conference proper.

i
=
--
Ian Glazer
Senior Director, Ide= ntity
+1 202 255 3166
--001a114dc2eabfe811053d91e05f-- From nobody Wed Sep 28 08:04:01 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820EC12B1CD for ; Wed, 28 Sep 2016 08:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YItFjGpXMXko for ; Wed, 28 Sep 2016 08:03:55 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5410312B1B1 for ; Wed, 28 Sep 2016 08:03:14 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id y6so55362510lff.1 for ; Wed, 28 Sep 2016 08:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a9jtg++vUEgu//mrvYwTUQPSEpl7NlwPMN6khrBWLng=; b=DKp4/4lZ6k1c96BNHIomY2N+FbVK+QrZObLxgow29pJUXsfsfo7NBXGeAobxlluoyh wzzaX9Ru0z9T+PA/JGYT7fi/jGmb2x56lua5DuNkioNMENGd4sadwx+DZ6uZTSAFEKC6 AReLAJTHUBxwELctHYxXzUXTPtrLxTFzdz7eDuFbpHdhCoI4R8xtCoYAtnMO9kVAzYLN g0csFhoFfTRqqX5uVKslzvywS6/oLD3pMB/Sog+RYcxJT83V5qhlWrE7vyPkCwocX2z+ IBJPrpi6+ssq4+1TvrWmallUUyupRfFnYz2bRYIN0FLDaozMhTM4Y0x/Nqkhs/TvO0Bc yjkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a9jtg++vUEgu//mrvYwTUQPSEpl7NlwPMN6khrBWLng=; b=DkiW9bt7PX62z6jM+A9G3QQqqPwxedCWYqkbs9UHurHTGtc2x/31JDY5xeaudaqen+ MEBwTsHT+ljLut+Yq5eiMKXPQ/pUmJByN69PZTRIY2IsodDoGkNn1tC4eXylXKAVoCFn gDJ9t5co5sj6SPMRpPG71hsJrfoTrDOTu5Yc+8N1RRXZ5N+I9RPUOfc9uSewwCl+Zbr9 WlCzWSpLYXnkv4MJkYppEQ8Fe/gqRH6/2UPA8YnXPSfGafNOJpB0kjGuxCNwpJahR/WM aqQvpjIWY1rvI2R3gfDKNJB3xMIs8Y3b0DeLhVvZPYzZAdWPbqHAecEIl3yhBVC0IlQJ /k+A== X-Gm-Message-State: AE9vXwNxy93+DynqGXIB7hj1lGMEs53N2RHo7Xzm8np8tPGBVd02IT267qiVGRar899Ek+Ko2A6Ry96Ib3SxXw== X-Received: by 10.25.196.199 with SMTP id u190mr12062175lff.97.1475074991256; Wed, 28 Sep 2016 08:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.228 with HTTP; Wed, 28 Sep 2016 08:03:10 -0700 (PDT) In-Reply-To: References: From: Steve Hutchinson Date: Wed, 28 Sep 2016 11:03:10 -0400 Message-ID: To: Ian Glazer Content-Type: multipart/alternative; boundary=001a114b2086defa4a053d92a8f2 Archived-At: Cc: "scim@ietf.org WG" Subject: Re: [scim] Another v2 interop? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 15:03:59 -0000 --001a114b2086defa4a053d92a8f2 Content-Type: text/plain; charset=UTF-8 We finally have a good testing environment here at GE and would be interested. On Wednesday, September 28, 2016, Ian Glazer wrote: > Gang - > > Anyone have interest in doing another interop ahead of Gartner IAM Summit > in late November? There's an opportunity to do a small readout during Erik > Wahlstrom's tutorial before the conference proper. > > i > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > --001a114b2086defa4a053d92a8f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We finally have a good testing environment here at GE and would be interest= ed.



On Wednesday, September 28, 2016, Ian Glazer= <iglazer@salesforce.com&g= t; wrote:
Gang -
Anyone have interest in doing another interop ahead of Gartner = IAM Summit in late November? There's an opportunity to do a small reado= ut during Erik Wahlstrom's tutorial before the conference proper.

i

--
Ian Glazer
Se= nior Director, Identity
+1 202 255 3166
--001a114b2086defa4a053d92a8f2-- From nobody Wed Sep 28 21:09:17 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8512B047 for ; Wed, 28 Sep 2016 21:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 gcycI6QxSDx1 for ; Wed, 28 Sep 2016 21:09:14 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD14A12B016 for ; Wed, 28 Sep 2016 21:09:13 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b4so1054582wmb.0 for ; Wed, 28 Sep 2016 21:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mPH6Kf6jvlgzweSpEOTMXrn23IghrwWlAY3inWdzKzQ=; b=Lxinnt2u9i7bNGSxeMGkvnc9tyB0+c+ylwTHFFQ4Wxsts0LsQGW1WycVkna7v0lcxf uoSvREvZ7VDhw6osunneqqA38Tozq9r2VyJ3YD4m/qjXi09NcHdYZxILcq10HvOFDN5k 5wwh1/+cnT9g+jg8OOmaCuopmiBeis/jFHrb4oeiRTmIEKeHpg8IAuKI8GliahDAH/Cp ATaM9danezPz4FHEOElbZiDOKVuOBmz9asb2Sk+wXEZxkVsiSRsPY4Qmk4/O1KB7uFgj kQJVJLxxM375TZi8e9Gm6p/oCvfNRvi2TPH92ZDyie3lP25BvL9YfeHJqzTYNmIZyZ/3 5fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mPH6Kf6jvlgzweSpEOTMXrn23IghrwWlAY3inWdzKzQ=; b=jnJm59GWfpkrkK6OrYDzHX82FGpMaRn3WEFQhxN+dHP7CaN0tRjqRI7RR2m2IVyvml kFDO3lqv6y33B3DIrXMkQPgej3rfaEVneJ7b8pM3jPzRyUACDKLbj5XcDWYMGphkVcu+ PaVWB7msUpqMIDeZ5hppRsONxr66RzJ1rKvjkVpR1KcgkpYKciLg2PQO5p8o1ELgrmJg DsV5vKue7vUXD2vyr/NV603/OCRVFnmuj9pfDsrFWJXfxRMtxhdAjpk/U/T9ob09do4b LbjECMZ14oMxXBe/EGfOCajH/Bi/ap62uaTdIG9gFAbqEAjA9fgzqCuKHMdEPlifW2RX cmEQ== X-Gm-Message-State: AA6/9RnYQK/a4WP+Ax6BC1SqkHE1gcxWOLIvHha9LkeR0lnWXcTTkepT8TnJr0Ne1pPFxfEBSroWQq4+Lk8DWk4W X-Received: by 10.28.87.16 with SMTP id l16mr517567wmb.75.1475122152119; Wed, 28 Sep 2016 21:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.32.11 with HTTP; Wed, 28 Sep 2016 21:08:51 -0700 (PDT) In-Reply-To: References: From: Shalini Gupta Date: Thu, 29 Sep 2016 09:38:51 +0530 Message-ID: To: Steve Hutchinson Content-Type: multipart/alternative; boundary=001a1144375ae0fa44053d9da3a3 Archived-At: Cc: "scim@ietf.org WG" , Ian Glazer Subject: Re: [scim] Another v2 interop? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 04:09:16 -0000 --001a1144375ae0fa44053d9da3a3 Content-Type: text/plain; charset=UTF-8 +1 Great opportunity. Lets do it.. Last interop was quite useful. Will be great if we see more participation this time.. On Wed, Sep 28, 2016 at 8:33 PM, Steve Hutchinson wrote: > We finally have a good testing environment here at GE and would be > interested. > > > > On Wednesday, September 28, 2016, Ian Glazer > wrote: > >> Gang - >> >> Anyone have interest in doing another interop ahead of Gartner IAM Summit >> in late November? There's an opportunity to do a small readout during Erik >> Wahlstrom's tutorial before the conference proper. >> >> i >> >> -- >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Regards, Shalini --001a1144375ae0fa44053d9da3a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 Great opportunity.=C2=A0
Lets do it.. La= st interop was quite useful. Will be great if we see more participation thi= s time..=C2=A0


On Wed, Sep 28, 2016 at 8:33 PM, Steve Hutchinson <= span dir=3D"ltr"><sehutchinson@gmail.com> wrote:
We finally have a good testing environment here at GE and would b= e interested.


On Wednesday, September 28, 2016, Ian Glazer <iglazer@salesforce.com> wrot= e:
Gang -

=
Anyone have interest in doing another interop ahead of Gartner IAM Sum= mit in late November? There's an opportunity to do a small readout duri= ng Erik Wahlstrom's tutorial before the conference proper.

i

--
Ian Glazer
Senior = Director, Identity
=

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




--
Regards,
Shal= ini
--001a1144375ae0fa44053d9da3a3-- From nobody Thu Sep 29 15:27:16 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98012B314; Thu, 29 Sep 2016 15:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kenhRKcs_pPC; Thu, 29 Sep 2016 15:27:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B380912B213; Thu, 29 Sep 2016 15:27:13 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8TMRCUL009914 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2016 22:27:12 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u8TMRBhV031693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2016 22:27:12 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8TMRBuf002031; Thu, 29 Sep 2016 22:27:11 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2016 15:27:11 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_4755B4CE-2298-43E4-B7C4-F507A973F110" Message-Id: <5B0B1CA9-E542-4C70-895D-35273032BC42@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 29 Sep 2016 15:27:09 -0700 References: <147518730587.18511.15769334083378030049.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org WG" , "openid-specs-ab@lists.openid.net Ab" , openid-specs-risc@lists.openid.net Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-distribution-01.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 22:27:16 -0000 --Apple-Mail=_4755B4CE-2298-43E4-B7C4-F507A973F110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a substantial re-work of the distribution draft that Marius, = Morteza and myself have been working on. The following major changes: 1. Specifies a fairly simple HTTP POST delivery method for now that = provides assured delivery 2. Proposes a registry so that new methods may be defined as needed. 3. Profiles SCIM for subscription registration and management including = appropriate metadata This more or less should line up with the distribution objective in the = charter as a starting point for discussion. I would like to thank my co-author Marius and the OIDF RISC working = group for providing substantial input into the draft. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-hunt-idevent-distribution-01.txt > Date: September 29, 2016 at 3:15:05 PM PDT > To: "Phil Hunt" , "Morteza Ansari" = , "Marius Scurtescu" >=20 >=20 > A new version of I-D, draft-hunt-idevent-distribution-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-distribution > Revision: 01 > Title: SET Token Distribution and Subscription = Management Profile > Document date: 2016-09-29 > Group: Individual Submission > Pages: 30 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-distribution-01.tx= t > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-distribution/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-distribution-01 >=20 > Abstract: > The specification defines how a subscriber to a feed of security > events (SETs) may query for, subscribe and receive SETs from a > security event feed. The specification defines a single mandatory- > to-implement method using HTTP Post to deliver events to registered > subscribers and a registry for new methods. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_4755B4CE-2298-43E4-B7C4-F507A973F110 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is a substantial re-work of the distribution draft that = Marius, Morteza and myself have been working on.

The following major changes:

1.  Specifies a = fairly simple HTTP POST delivery method for now that provides assured = delivery
2.  Proposes a registry so that new = methods may be defined as needed.
3.  Profiles = SCIM for subscription registration and management including appropriate = metadata

This = more or less should line up with the distribution objective in the = charter as a starting point for discussion.

I would like to thank my co-author = Marius and the OIDF RISC working group for providing substantial input = into the draft.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-distribution-01.txt
Date: = September 29, 2016 at 3:15:05 = PM PDT
To: = "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Marius Scurtescu" <mscurtescu@google.com>


A new version = of I-D, draft-hunt-idevent-distribution-01.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-distribution
Revision: 01
Title:= = SET Token Distribution and Subscription Management Profile
Document date: 2016-09-29
Group:= = Individual Submission
Pages: 30
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-distrib= ution-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-distributio= n/
Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-distribu= tion-01

Abstract:
=   The specification defines how a subscriber to a feed of = security
  events (SETs) may query for, = subscribe and receive SETs from a
  security = event feed.  The specification defines a single mandatory-
  to-implement method using HTTP Post to deliver = events to registered
  subscribers and a = registry for new methods.




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.

The IETF = Secretariat


= --Apple-Mail=_4755B4CE-2298-43E4-B7C4-F507A973F110-- From nobody Thu Sep 29 15:39:08 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E58F12B1F8; Thu, 29 Sep 2016 15:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ez2qaTrDbRbw; Thu, 29 Sep 2016 15:39:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2E112B0C5; Thu, 29 Sep 2016 15:39:04 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8TMd3a5021471 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2016 22:39:03 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8TMd2EM028273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2016 22:39:03 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8TMd2T1024226; Thu, 29 Sep 2016 22:39:02 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Sep 2016 15:39:01 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_983829E5-A634-42FA-9DFB-93F2A87A15B9" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 29 Sep 2016 15:39:00 -0700 References: <147518764595.18469.13842294313586215202.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org WG" , "openid-specs-ab@lists.openid.net Ab" , openid-specs-risc@lists.openid.net Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 22:39:06 -0000 --Apple-Mail=_983829E5-A634-42FA-9DFB-93F2A87A15B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a minor update to the SET Token draft. Based on the mailing = list feedback, I made some revisions to the text on transactions and = sequencing. I dropped the term =E2=80=9Cidempotency=E2=80=9D as this is = not really the correct usage of the word. =20 The issue I was trying to get at was whether SETs can be delivered in = any sequence or whether there sequence is critical. For example in an = Idempotent service, one cannot modify a resource that has not yet been = created. So while commands may be repeated achieving the same result, = the sequence of different commands is critical. 8) My gut feeling on sequencing (when needed) is most likely resolved by = specs that profile SET Tokes by adding sequencing claim or defining = =E2=80=9Ctxn=E2=80=9D for the purpose. There may be some delivery = methods that can provide sequencing, but I think that has more to do = with deployment architecture rather than protocol. For example, in a = distributed system, the way events are delivered to a Feed Publishing = Service might enable the Feed Publisher to guarantee order. That=E2=80=99= s not to say I haven=E2=80=99t overlooked a =E2=80=9Cduh=E2=80=9D simple = solution.=20 This draft should be a good starting place for the SEC Event WG proposed = charter. Thanks, =20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-06.txt > Date: September 29, 2016 at 3:20:45 PM PDT > To: "Michael B. Jones" , "William Denniss" = , "Phil Hunt" , "Morteza = Ansari" , "Michael Jones" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-06.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 06 > Title: Security Event Token (SET) > Document date: 2016-09-29 > Group: Individual Submission > Pages: 19 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-06.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-06 >=20 > Abstract: > This specification defines the Security Event token, which may be > distributed via a protocol such as HTTP. The Security Event Token > (SET) specification profiles the JSON Web Token (JWT) and may be > optionally signed and/or encrypted. A SET describes a statement of > fact that may be shared by an event publisher with event = subscribers. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_983829E5-A634-42FA-9DFB-93F2A87A15B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is a minor update to the SET Token draft.  Based on = the mailing list feedback, I made some revisions to the text on = transactions and sequencing.  I dropped the term =E2=80=9Cidempotency= =E2=80=9D as this is not really the correct usage of the word. =  

The issue I = was trying to get at was whether SETs can be delivered in any sequence = or whether there sequence is critical. For example in an Idempotent = service, one cannot modify a resource that has not yet been created. =  So while commands may be repeated achieving the same result, the = sequence of different commands is critical. 8)

My gut feeling on sequencing (when = needed) is most likely resolved by specs that profile SET Tokes by = adding sequencing claim or defining =E2=80=9Ctxn=E2=80=9D for the = purpose. There may be some delivery methods that can provide sequencing, = but I think that has more to do with deployment architecture rather than = protocol. For example, in a distributed system, the way events are = delivered to a Feed Publishing Service might enable the Feed Publisher = to guarantee order.  That=E2=80=99s not to say I haven=E2=80=99t = overlooked a =E2=80=9Cduh=E2=80=9D simple solution. 

This = draft should be a good starting place for the SEC Event WG proposed = charter.

Thanks,
 



Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-06.txt
Date: = September 29, 2016 at 3:20:45 = PM PDT
To: = "Michael B. Jones" <mbj@microsoft.com>, = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-06.txt
has been successfully submitted by Phil Hunt and posted to = the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: 06
Title:= = Security Event Token (SET)
Document date: = 2016-09-29
Group: Individual Submission
Pages:= = 19
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 6.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-06
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-06=

Abstract:
=   This specification defines the Security Event token, which = may be
  distributed via a protocol such as = HTTP.  The Security Event Token
  (SET) = specification profiles the JSON Web Token (JWT) and may be
=   optionally signed and/or encrypted.  A SET describes a = statement of
  fact that may be shared by an = event publisher with event subscribers.




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.

The IETF Secretariat


= --Apple-Mail=_983829E5-A634-42FA-9DFB-93F2A87A15B9-- From nobody Thu Sep 29 17:15:34 2016 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DBE12B208; Thu, 29 Sep 2016 17:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Q1T9M9xA-uiz; Thu, 29 Sep 2016 17:15:26 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749F112B09C; Thu, 29 Sep 2016 17:15:26 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id t83so112395855oie.3; Thu, 29 Sep 2016 17:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4h2ESaZFbkP+yrGG1SIi5duGJ44AGaxTBCtRj0Sy3Ts=; b=k6VmmEotroexKsyICdqHuf0zvVXzCnb3t6hqGUeHCGFS6AT0AsHkn3DlkuZJf+1sko Poa20GdMGOUkQXJxVK1Izk3abOE0Uq0+NmzY9grRTmS4CAugk7gFRr8x60wzWnF1a3+W 5A719bPIDu0we1oihxIuNuxqjmZzjTuakvoZapo2eZEypWcf5hjqSswFcNfs7XhLMZpT cMupcHrZIjtgkA19wMQKdof/05DrVVLccopTWNf4qtxMGhkAqXedOn4mRSGGS0xy0T4+ 390Z2QnemJiCUfWS4NvnyOynE5vX2YihCyyUXobtEeEL3e98DvJc/CnaThBGfqPKaznd reCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4h2ESaZFbkP+yrGG1SIi5duGJ44AGaxTBCtRj0Sy3Ts=; b=VC++6AuqrqGvarrHIC9xC4u0CxWcGy8s8HJPa/oQABW3xOF3gjV17TxUO3Qp7FX8XZ mHlZECo5/Lh+DemBx1h/HBzmopRYSBJBFBN9OycvOZdHZZzDsJxvEQVF2WyGjSA16SCc Tf2805VaEIqhFkKfG0OjQuAHLzoRLOqWUGWhdLoMtZMBnGX/N6s4CuRoRO5hTNwKg28n wKweol9NlyZBzLn4kxmSCzmYdGXNruLu1L/FFg8MxEShusySssqb4ZpooGc2g8trur/l e9c+7VKxEEMDXzp641QebOrzpoIzEjAEaYpOvLR4ZTy23vQscgBLQxrbGCO/t4GBv2Bt QKSg== X-Gm-Message-State: AA6/9RlwrB40a8Cc4FJaL7hXzEMCsBYZiWBpXAXxkfXD7IXt0EdPLgw6AVreSUD1bvFgMDuj4I1Etx2pXfJtPw== X-Received: by 10.157.6.46 with SMTP id 43mr2794914otn.33.1475194525874; Thu, 29 Sep 2016 17:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.142.39 with HTTP; Thu, 29 Sep 2016 17:15:25 -0700 (PDT) In-Reply-To: References: <147518764595.18469.13842294313586215202.idtracker@ietfa.amsl.com> From: Alan Karp Date: Thu, 29 Sep 2016 17:15:25 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=94eb2c09b6c4b08047053dae7dd0 Archived-At: Cc: "scim@ietf.org WG" , "openid-specs-ab@lists.openid.net Ab" , id-event@ietf.org, openid-specs-risc@lists.openid.net Subject: Re: [scim] [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 00:15:28 -0000 --94eb2c09b6c4b08047053dae7dd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil Hunt wrote: For example, in a distributed system, the way events are delivered to a Feed Publishing Service might enable the Feed Publisher to guarantee order. That=E2=80=99s not to say I haven=E2=80=99t overlooked a =E2=80=9Cd= uh=E2=80=9D simple solution. Having worked with distributed systems for more years than I care to admit, I doubt that you overlooked a "duh" solution. -------------- Alan Karp --94eb2c09b6c4b08047053dae7dd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil Hunt=C2=A0<phil.hunt@oracle.com>=C2= =A0wrote:

For example, in a distributed syst= em, the way events are delivered to a Feed Publishing Service might enable = the Feed Publisher to guarantee order.=C2=A0 That=E2=80=99s not to say I ha= ven=E2=80=99t overlooked a =E2=80=9Cduh=E2=80=9D simple solution.=C2=A0

Having worked with = distributed systems for more years than I care to admit, I doubt that you o= verlooked a "duh" solution. =C2=A0

--------------
Alan Karp

--94eb2c09b6c4b08047053dae7dd0--