Re: [scim] SCIM Events
"Paulo Jorge N. Correia (paucorre)" <paucorre@cisco.com> Mon, 15 January 2024 09:21 UTC
Return-Path: <paucorre@cisco.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDCC14F614 for <scim@ietfa.amsl.com>; Mon, 15 Jan 2024 01:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.603
X-Spam-Level:
X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlzp2RepWyPv for <scim@ietfa.amsl.com>; Mon, 15 Jan 2024 01:21:46 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (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 92482C14F610 for <scim@ietf.org>; Mon, 15 Jan 2024 01:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=49192; q=dns/txt; s=iport; t=1705310506; x=1706520106; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvKkLwwBhFYy/NMrmdIDvP+d6C4wyca4vdosRRdnlgs=; b=ATfdJXYGUuFlKnae872epjNNK86/thPYT65/+4D8SUUkhDU5284RPUwp Fc9sG9rWoPBwSvUfyDKlfTye07TbFq5bwE2W7Dv7Pd4m5Id3mT4jrNuog X4FcOfWs+P3IfS5aqK4aRGp2yX7bl/wCtORlaPI+dcFo7HYuyJjzJTo6a A=;
X-CSE-ConnectionGUID: m7ewDUQiQhy1DX7s4G7uQg==
X-CSE-MsgGUID: hI9WHenGTPq6EZpOT58YaQ==
X-Files: smime.p7s : 5478
X-IPAS-Result: A0AOAABa+KRlmIcNJK1RBgMcAQEBAQEBBwEBEgEBBAQBAWWBFgcBAQsBgTUxKih6AitsSIRSg0wDhE5fiGcDgROQK4YtgTiEXxSBEQNCDwUIBwEBAQoDAQEuAQoLBAEBhQYCh0QCJjQJDgECBAEBAQEDAgMBAQEBAQEBAQYBAQUBAQECAQcFFAEBAQEBAQEBHhkFDhAnhWwNhkUBAQEBAwEBEAgJCjoHBAcQAgEGAg4DAwEBASEBBgMCAgIkCxQJCAIECgQFCAYNB4IGWAGCFzcRAwEQmHqPTgGBQAKJcTd6gTKBAYIWBYE8BAGxLBCBSAGBVoZEAYFOAQGCcoEJgyiBLwgfG4FJRIEVQoIwOD6BBQGBWwEBAoEfCgEICgEjFQkBCwoICYMUOYIvBIIWVYIQXYEOAYIkhkGGWFSBHwOBBQRcDwUWDx43ERATDQMIbh0CMTwDBQMEMgoSDAshBRNCA0MGSQsDAhoFAwMEgTAFDRoCEBoGDCYDAxJJAhAUAzsDAwYDCjEDMFVBDFADZR8yCTwPDBoCGx4NJyMCLEIDEQUQAhYDJBYENBEJCyYDKgY3AhIMBgYJXSYWCQQlAwgEA1QDI3QRAwQKAxQHCwd5gV0DRB1AAwtoBQ4CLTUUGwUEgTYFk1F5AYE/CgULDlNoGhUjARQMAjUECx8MBwcVDwIIAwoSFgEBCQYDEgQLBgsBBQIWEZIzLS6DKZlhk0CBOgcDhBGGUYMqggqHGYZ+hzAXhAFMgQqLH4Z2kRMvZJhSiw6CXpUNLQ8DCg+EcAIEAgQFAg4BAQaBYzprcHAVO4JnCUkZD4odhByDX4JkgjCKZXYCOQIBBgEKAQEDCYhwLWtfAQE
IronPort-PHdr: A9a23:X4rC6xzAyQ8iFQbXCzMVngc9DxPP8539OgoTr50/hK0LK+Ko/o/pO wrU4vA+xFPKXICO8/tfkKKWqKHvX2Uc/IyM+G4Pap1CVhIJyI0WkgUsDdTDCBjTJ//xZCt8F 8NHBxd+53/uCUFOA47lYkHK5Hi77DocABL6YBJ8O+/yAJTfp8+2zOu1vZbUZlYAiD+0e7gnN Byttk2RrpwMjIlvIbp5xhrS931PfekXjW89LlOIlBG67cC1lKM=
IronPort-Data: A9a23:T+CsS62Zzmvhqz+ro/bD5Sxxkn2cJEfYwER7XKvMYbSIpGtil2len TNbADbYJb/RMSHyZpovP9PnsQ9E7KZh/KYgFVsx+Dd1EGkiRaHtVN/DJx6rZXjCfsCZQhk3t ZVEYITMcpltFCTSq0nxP7Lt9XIjhPrRGeCgAbCZa34qGAJvESlx2R89l75h2dAyjbBVb+/jV fba+6Uzb3f4h2EkWo5t15++lf9PgBjTkGlD71Ziaf4V5gHUnXJFBZ9EdfzqI3bxGIBfQrHnS u2Y5bzopWmxEzXBpT+GfhcXVmVQH9Y+6CDX0iI+t5CK20UE/mpqlP9jaJLwUG8P4x2Rhdd91 d5RgpK5TAYtL8Xklf8UO/ViO3kW0ZZupvmffRBTjeTJlxeaKyK1nq00ZK0LFdRwFthfUDkmG cMwcFjhXjjb78qqzbSyTPVbh8hLBKEH66tG5xmMZRmAZRoXacirr5fivLe07x9s7ix6JssyU uJCAdZZgLssVDUUUrsfIMpWcO5FHRATeRUAwL6ejfJfD2Q+UGWd3ZC1WOc5dOBmSu1QwUuHi l///l35E0g2BIOElRXa70uj07qncSPTAOr+FZWx8vpsxVaU3GFWUlsdVECwpr+yjUvWt9B3c hNPvHFw6/FpshXwE7ERXDXgyJKAlgYVRtFXCfc3wAqM0aHTpQ2eAwDoSxYbMIx37pRqGWVCO lmhn/K4OhxitpKpcWvD24WMig/vaRkcFDpXDcMDZVBYu4a4+t5bYgj0Zs1oEaudj9DpF3f32 T/ikcQlr7wXichO3KKh8BWdxTmtvZPOCAUy4207Q15J8Ct8O4O6S7GR6GHb/K9sHNmCEnbeo UELzp32AP81MbmBkymEQeMoFb6v5uqYPDC0vbKJN8R9n9hK0yPyFb288A1DyFFV3tHokAIFj WfavQdXoZRUJnbvN+l8Ypm6DIIhyq2I+TXZuhL8MIQmjntZLVPvEMRSiam4hDGFraTUuftjU ap3iO71ZZrgNYxpzSCtW8AW2qIxyyY1yAv7HM+jkk76juLBPiPJFt/p1WdiiMhksMtoRy2Lq 75i2zeimn2zrcWnO3aHr9RPRbz0BSFkW8meRzNrmh6reVc+Rzp7VJc9MJsqepdumOxOh/zU8 3SmEk5ewxyXuJE0AVviV5yXU5u2BcwXhStiZUQEZA/0s1B9OtzHxPlEKPMKkUwPqbYLIQhcF adVIq1tw51nF1z6xtjqRcOk9NQzJE7z2lnm0ujMSGFXQqOMjjfho7fMVgDu7yIJSCGwsKMDT 3eIj2s3nbJrq9xeMfvr
IronPort-HdrOrdr: A9a23:MA6a869OwfYXQ7Kafp1uk+GRdr1zdoMgy1knxilNoENuA6+lfp GV/MjziyWUtN9IYgBfpTnhAsW9qXO1z+8S3WBjB8bSYOCGghrlEGgM1/qZ/9SNIVybygcZ79 YeT0EcMqy+MbEZt7eG3ODQKb9Jq7f3ktHMuQ6d9QYQcegAUdAY0+4NMHfhLqQAfng/OXNWLu v62uN34xCbVTA8aMO9CnMZX+7FieHqufvdCyIuNloM0iXLqSmnxoLbPnGjsyv2VQkh/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc2lkKEuW3TRozftQL4kd6yJvTgzru3qwk0tis PwrxApONk2w2/Nf1uyvQDm12DboXYTAj7ZuBylaEnY0InErQEBeo58bEViA1zkAn8bzZNBOW RwriSkXtRsfEr9dW/Glqj1vllR5zmJSDwZ4KAuZ7g1a/pEVFeXxrZvpH99AdMOGjn355sgF/ QrBMbA5OxOeVffdHzBuHJzqebcFUjbMy32C3TqgPblmwR+jTR81Q8V1cYflnAP+NY0TIRF/f 3NNuBtmKtVRsEbYKphDKNZKPHHR1DlUFbJKiafMF7nHKYINzbErIP2+qw84KWvdIYTxJU/lZ zdWBdTtHI0eUjpFcqStac7uCzlUSG4R3Dg28te7592tvn1Q6fqKzSKTBQ0n86ps5wkc7vmsj aISeVr6tPYXB/T8Nxyrn/DsrFpWAwjbPE=
X-Talos-CUID: 9a23:ZWQ8P2ucwbqfzp+QocWVANMl6IsgLXDC4ErpIna4GD9FeOKOFXDP5Zprxp8=
X-Talos-MUID: 9a23:QT4o2wp6GhiMV2Vf7oQezzFDZfhI7qKBNHgUz7g0o+64aHxBMg7I2Q==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 09:21:45 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 40F9LjL7026272 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <scim@ietf.org>; Mon, 15 Jan 2024 09:21:45 GMT
X-CSE-ConnectionGUID: Qu4sKjK3SbyNytazKioTXg==
X-CSE-MsgGUID: N3E+lnl4S8CyR4xvLTD6HQ==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=paucorre@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.04,196,1695686400"; d="p7s'?scan'208,217";a="19889195"
Received: from mail-mw2nam12lp2041.outbound.protection.outlook.com (HELO NAM12-MW2-obe.outbound.protection.outlook.com) ([104.47.66.41]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 09:21:44 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EF6WRBsJP5O1EDcU3deAY/NL6fan/F4Qk5CKlywz0nBZt09lGJEpWPipdrNuTsIDj5pe8Vqn/SBYyIO1wfWW7qanH8IPJiTAGOgjlJJ+TzyAA8tyaD9spSrEQpHluXHk2v3zwywbDsvz0j7eq73Y96nUxOv76d+PlVsP4JZX9NZJejpRnY/8MQo/INw0o9dLK6yiv3LhGUuplbhlRE4AHdQ+IO/8zXDvsf9aheVwl7Z1pWU4bVwp/u0QP16a8BJ+QylwNYP0+OdPhU3ejhVJ9oTBLf7iv1eTSIrXPpyaWScKexfMrTI3pPmUV062Tb6lpTXvN6KnDONcgQmynaLJUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XvKkLwwBhFYy/NMrmdIDvP+d6C4wyca4vdosRRdnlgs=; b=aKZp1ahj7T3NpnRSjbyafjoHg+K6cNaRhbNQjWgKcCnQV1ruXpd464e5hCXLwblr+wWplKQ/YNer+bqjrzO0SWDXNE+ye1zV0NGXGSJoFcGE/sDmE39GGmnTyC6GHyyMv88IdfNqoTAVS+UHuIyJyfHQKCf5E+aiimE3wHJErd63HRTqTLkVKKOH40ysPwkIED3Xa3n4qfb1IBJMwrE3WcGTZRpnU5cVFAveCmScwuZHDrF12YydbiDM5leEs2ZBwHO5LMbgs/TpAND0vHd2kQotlXQZWTE6EfYfryuo3KtMgwe7QOBfiULL5src6Kq0m4ehlutDPpAWqr3rKR17Yw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
Received: from MW3PR11MB4730.namprd11.prod.outlook.com (2603:10b6:303:58::8) by SN7PR11MB7510.namprd11.prod.outlook.com (2603:10b6:806:349::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.23; Mon, 15 Jan 2024 09:21:41 +0000
Received: from MW3PR11MB4730.namprd11.prod.outlook.com ([fe80::a7ec:be2d:52c:42bc]) by MW3PR11MB4730.namprd11.prod.outlook.com ([fe80::a7ec:be2d:52c:42bc%3]) with mapi id 15.20.7181.022; Mon, 15 Jan 2024 09:21:41 +0000
From: "Paulo Jorge N. Correia (paucorre)" <paucorre@cisco.com>
To: Phillip Hunt <phil.hunt@independentid.com>
CC: "Paulo Jorge N. Correia (paucorre)" <paucorre=40cisco.com@dmarc.ietf.org>, SCIM WG <scim@ietf.org>
Thread-Topic: [scim] SCIM Events
Thread-Index: AQHaRyHUKcM9EH5VqEqXlsqQjIEZnbDZvdIAgAAEraCAAAgFAIAAzRxQ
Date: Mon, 15 Jan 2024 09:21:41 +0000
Message-ID: <MW3PR11MB47300D695A2581BCC59F025DCD6C2@MW3PR11MB4730.namprd11.prod.outlook.com>
References: <MW3PR11MB4730CEEB7CB55C8BD38661A6CD6D2@MW3PR11MB4730.namprd11.prod.outlook.com> <8542CFAC-D49A-4B1A-BF11-DB047627BDD1@independentid.com>
In-Reply-To: <8542CFAC-D49A-4B1A-BF11-DB047627BDD1@independentid.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MW3PR11MB4730:EE_|SN7PR11MB7510:EE_
x-ms-office365-filtering-correlation-id: e5513e81-cb2c-4214-b968-08dc15ab6250
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: M2rZNCSB4Hey0cLd2324thwD2S9jOZV7mlYrwn5pJyu1o65CwYNJF7sfMnBohiGFAR55mOlXI2JFW/KMwv087HcVZ4TLRs8Q+lJtJd92cGgDUu7/pc4beJI/mD84rzTzdl63tf/CVQuUOaKxnYd2FVkVwBCVelSkQ14oS3Gr4qtPdvEM8CGfrOACiTbYvnRH2wraLSkRQJMbepwpJ4pS1rbT4kjltcy23lusZZEj8eN/UeEA4hV++TqGEsopFE7Rvx75tXxk2hMK5FjL+txnPNF+aT8E1Yu5CufXA3Txtzp2vLsQosoaAg2j0TTjmz2+HC3Ry9JwcCVAlpjJBgQ1CX3XVT9lRf/9fFIVN9G3dqrolx80t2f1xQe+al1IG1oKkthepJasl/hKk+aJTeuooqCSUDXA3PDwLPzboiu1zIXMdtBNqyMLpeKcaJvSUPpXKhuE+3zCIyURc+b+RuSycKY5i3iGQVN10aZn7WPzXFufLh708J4n44GOb8Demc6dJr2KjHI06th5KLWHT8IHL4VmgOUw9KZmS/qqSln2FsnfOoO0841ZMIwpdWmT4Vs9poRK092DSzSF2CUaFEiYI0iHhY2OcGF7QWhLUmyDc6Y9/IlrnRn8WDPlfsBD4VYb8mYE+PgfKdK/whblR0tZ5jgMqOBv5t6w+kCBdsMYkosv+bogDD+w0puuzvWrlQ1ra4mzIjYA4Tt+Mg2ifBQtsGAmX65y+wZhFgks7Z11mPQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4730.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(396003)(136003)(346002)(376002)(366004)(230173577357003)(230373577357003)(230473577357003)(230273577357003)(230922051799003)(1800799012)(64100799003)(186009)(451199024)(55016003)(83380400001)(26005)(66446008)(38070700009)(166002)(41300700001)(66946007)(33656002)(76116006)(86362001)(99936003)(40140700001)(38100700002)(6506007)(122000001)(71200400001)(52536014)(66574015)(54906003)(316002)(30864003)(53546011)(9686003)(8676002)(2906002)(966005)(66476007)(8936002)(6916009)(66556008)(7696005)(64756008)(478600001)(5660300002)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PiokGvIwUAEwww8p/ayy1PPB1QI+zwCJOhykrikGpYH32CC/Rx9OYbz4XLnM12jXhtQWErglJvbPRW31f3FC4OJ7VjhMAfqLuFz0GGsF1ZBUeS3nAkJ2glSHr+fets9owxMDR9KEXMgxl0jn/Fcbo/fSpnt3SLpYFJ2Y6LGXMEig2x+pT/Kg0s98rwbOCEhNQh33D+OWPUXMxGiwN8568A34nHj61xqB8QAaI7RFgaAEXSmjz0HFgBYt2mRvIECOecLjjNKGvqyYdMBtg7p6JgqxTSxdOYKgwzh4SdIwG7DmF//rYoHQTmp6aTwMn5EaIilDsXIogtXi/yyZ+3CPNcr4bhROH2N8ZG3zsCY5fYe8HCo4tKBcazl1pavuIT0SHdOSYZiW6p5yQXixZmYqcc6FEK0o2ih0NFc+k17lplyCNszc8xNvv3xYfofqoHYm5XI+u1c3+WQ/4buBgABRPvgBcEykZpBAOPnePg1eTvusIELYdH3WRuLOv60lSEuUnkOtA02jY0PGHus1STHj/6xtjZWa9BpfgFnepAVSEFmfS7Gg+yGXYPoYTQd6PJajnYgvJfCrNedfALsvy8gv9MA6KnXnVwk8qbVWWPqfgkGLHEo6BlEbxGojxS0huxmrwaQDIERmmzid8/Qfr/oxycBBsjNn/83Lng2J9IlkU7xNqshoblLuJfFs9NM8KDuWZ1M+iu/qR8MI+xaN5yd9mXDm67G4hWwdJiSh/c+D7vEWp42ppIU0yS/AwUWbo8MYp/51v9XD6eif2pGWXk8kFr3GhjJeaUtNSIXup4iC/5UZ1i3P+IHfLRoO2GHSufm9Qw9awilqQKkDQyovabt/ajmErBlOuiM8oROMnD3V+vDgXue8yJilLaJckvqfZtBkubKxip5gLTVnX0YtR5fR2V8wf+nuy/+SIvduaGNn42N1F0URVFln3YiGDCz/aMRZxOzo3U3FDmSWqhwA/VemKJah5cph561oqthxHwOyiMfqXkGH7/iQe5dTCQWLVuqbs4L687ADbpUSSuQuAaS2bNiRUI1S986JClMHHgDFseUgmJ2Wu7tZeoFLprfj/7u5e7uhEWFm55Z/tPdnrLtYeQvdFLlaWspNy6YFeYzCaiRWmc6sociozISMNUfM2xscoget4M22PPisiFD1cTbPgEAffCRoBXnD5TUic90rGAv4ucu5QxjVhDuCkxnX+CH3e1/TFNC3ECEaxAguZn2AaDGAoy11QLi3vI1YL7tuvy2aMx4rYUhPHtGQ4n5tdH34mcSAiXrVsONEzbBTcr88++npmcvgLnfjlnKkxLVh2bbEXZQmea7MWVi/S0jtujGTpNnBjtjQ/A4nH63Ui09WVEhTF70WjmC/pLDL4uJER4QJeP0cwsSGHseHhs4gIlKoeTFUsjkyG3Jjldgr3yz0a90jG5AKjCI+4Xh1ZiojM3gFwbReor6dZGJfQi6cMZ2Yu+PmixNSWWz1NJ3UMvznLqSY/Gujx6N9R2f6vHvcG7fxSeCxe2jM0tOn/jV8bIAoBlfJ/jyMxGaOo9Ilx+zh9r/77NxlR/2WBuqhbdLPI6U=
Content-Type: multipart/signed; boundary="----=_NextPart_000_028D_01DA4793.FD0A3480"; protocol="application/x-pkcs7-signature"; micalg="SHA1"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4730.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5513e81-cb2c-4214-b968-08dc15ab6250
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2024 09:21:41.2328 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: r3jAfxs+Yo4p9RcPqlhuLLW62VCprBd/0KjPqWFdNWaQgwKjiJl/q55ofqp31m3tVASQ1V3I/mHmVT1Q/X3FEw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7510
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/BfTHHy1PcaqLe-p4lAze8D7uhBw>
Subject: Re: [scim] SCIM Events
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2024 09:21:51 -0000
Phil, Fully understand that the action in the receiver is not mandatory and the receiver does whatever he need to do with the information provided by the publisher/router, that still not address the point that I’m raising. In this draft you are describing the events for provision (urn:ietf:params:SCIM:event:prov) and there can’t be any action or not if you don’t have the right way of matching objects between the publisher and receiver. And I will say it again if you think that doesn’t make sense because it is logical to say that the data provided need to follow the rules of the Schema stated in the data section, I think it is perfectly ok, just saying that I struggle a little bot to figure out how would the publisher and receiver would figure out what object they were talking about if an action would be required. Thank you, Paulo From: scim <scim-bounces@ietf.org> On Behalf Of Phillip Hunt Sent: Sunday, January 14, 2024 8:58 PM To: Paulo Jorge N. Correia (paucorre) <paucorre@cisco.com> Cc: Paulo Jorge N. Correia (paucorre) <paucorre=40cisco.com@dmarc.ietf.org>; SCIM WG <scim@ietf.org> Subject: Re: [scim] SCIM Events It seems like you may be treating events like a normal api service call. A party issuing commands to another. Events are statements of facts regarding a state change that one party gives another. It would contradict 8417 to prescribe command actions on what a receiver must do. Event systems represent an inversion of control compared to typical http services. The receiver decides action based on a state change notice at the scim provider. SCIM complements scim protocol by keeping control in a client domain. For example a change originates in AD (ldap) causes a scim client in the AD domain issues scim protocol requests to the scim provider domain. A change occurring in the scim provider domain is sent as a notice back to the AD domain. The AD domain then decides what to do. In both cases the AD domain retains “control” of its domain. Phil On Jan 14, 2024, at 12:35 PM, Paulo Jorge N. Correia (paucorre) <paucorre@cisco.com <mailto:paucorre@cisco.com> > wrote: Phil, No doubt on the notice mode. In the full mode still don’t understand how it would work………….. if we clearly don’t say that is mandatory to follow the rules of the schema declared in the data section. Thank you, Paulo From: scim <scim-bounces@ietf.org <mailto:scim-bounces@ietf.org> > On Behalf Of Phillip Hunt Sent: Sunday, January 14, 2024 8:13 PM To: Paulo Jorge N. Correia (paucorre) <paucorre=40cisco.com@dmarc.ietf.org> Cc: SCIM WG <scim@ietf.org <mailto:scim@ietf.org> > Subject: Re: [scim] SCIM Events In notice mode the receiver would need to call back to obtain the full information (eg by doing a scim get). The message would just be a trigger to a remote scim client. In full mode, the event mirrors scim protocol so the receiver can act directly as if it were a scim request. I2scim.io does this in order to replicate between nodes. Phil On Jan 14, 2024, at 11:42 AM, Paulo Jorge N. Correia (paucorre) <paucorre=40cisco.com@dmarc.ietf.org <mailto:paucorre=40cisco.com@dmarc.ietf.org> > wrote: Hi Phil, As promised in the last IETF meeting I’m reading the last version of the SCIM event. I’m struggling with 2.4.1 where the Event Provision (EP) or Event Router (ER) is going to create an SCIM event feed for provision, and I’m assuming that the Event Subscriber (ES) doesn’t has that user yet, how would this work if we don’t mandate the userName attribute in the data event payload attribute, in fact I would argue that similar to RFC 7863 this needs to be require for all the operations. Or at this point it is irrelevant and there should be a statement saying that the data event payload should use the rules defined the schema defined in the schemas attribute in the data section, this will cover [RFC7633] but will cover others schemas like the work that Elliot is doing with devices. Am I missing something ? Thank you, Paulo From: scim <scim-bounces@ietf.org <mailto:scim-bounces@ietf.org> > On Behalf Of Saxe, Dean Sent: Monday, December 11, 2023 11:40 PM To: Phillip Hunt <phil.hunt@independentid.com <mailto:phil.hunt@independentid.com> >; SCIM WG <scim@ietf.org <mailto:scim@ietf.org> > Subject: Re: [scim] SCIM Events Pull Request #20 - Unsecured Tokens Thanks for raising this, Phil. Intercepting proxies are in wide use, as is TLS termination that occurs in front of the targeted destination. In both of these scenarios, unencrypted SETs may be observed by the TLS terminator, the data may be logged, and thus available to unauthorized parties. I see two specific issues here. First, disclosure of information is a risk with any sort of intercepting proxy or TLS termination if the SET is unencrypted. If the content of the SET is not sufficiently sensitive as to be a risk if disclosed, this is not a problem. However, for some data such as PII this is a challenge that needs to be solved. Second, modification of the SET in flight is a risk that is sufficiently solved by signing. Perhaps the focus should be on the security considerations section and the handling of unencrypted SETs when terminating TLS proxies may be in use. The risk can be called out, a solution of using JWE proposed, and the attendant risks with JWEs as you outline below described. Implementers must then make a decision about the handling of PII in SETs. I’m going to reach out to some folks deep in the SSF world to get their feedback, as well. I’ll post any relevant responses to the list. Thanks, -dhs -- Dean H. Saxe, <https://idpro.org/cidpro/> CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: <mailto:deansaxe@amazon.com> deansaxe@amazon.com | M: <tel:206-659-7293> 206-659-7293 From: scim <scim-bounces@ietf.org <mailto:scim-bounces@ietf.org> > on behalf of Phillip Hunt <phil.hunt@independentid.com <mailto:phil.hunt@independentid.com> > Date: Sunday, December 10, 2023 at 11:13 AM To: SCIM WG <scim@ietf.org <mailto:scim@ietf.org> > Subject: [EXTERNAL] [scim] SCIM Events Pull Request #20 - Unsecured Tokens CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I am just bringing to the group an issue that Dean raised in PR #20 (https://github.com/ietf-scim-wg/draft-ietf-scim-events/pull/20) on the SCIM Events Github site. This change occures in Section 3.1 which provides advice on use of encryption and signing (original below). Any new proposals from the group that address both Dean and my concerns would be greatly appreciated. Please reply to this email thread so we can record the decision. Dean’s request is to change the paragraph under “Unsecured" to: Unsecured tokens SHALL NOT be used. The justification in the PR was: Updated language to prevent the use of unencrypted, unsigned tokens in this profile. The concept of "inside" and "outside" networks is no longer sufficient to consider whether transmitting over a TLS-only protocol is sufficient for securing such information. Supporting such tokens is likely to lead to implementations that leak sensitive information and / or man in the middle interception/modification of SETs. Based on this assumption (that TLS is unsuffient) we would have to also disallow the use of “signed” tokens as JWS does not provide confidentiality. Note that in many cases because SETs may be processed through gateways (e.g. aggregating events from a cluster), using JWE may become challenging as the iss and aud values would not be accessible. Using JWE effectively forces point-to-point use only which again may cause the receiver to have to forward the unencrypted token on to its own internal endpoints. It’s my belief that TLS is sufficient in most cases. MITM is not a threat except if administrative systems are compromised or faulty. To the contrary, RFC8935/8936 talks about exchanging events through fixed endpoints. I believe editorially it would be out of scope for this spec to imagine the number of subsequent poorly security or designed systems that might lead to a mis-configuration. AFAIK, most OpenID Security Signals Framework implementations currently do not support signed or encrypted SETs (though i2gosignals does). These unencrypted systems are running in production now. While I do generally agree using unencrypted tokens is a bad practice, saying SHALL NOT will likely be ignored. Editorially my goal is to give guidance that in the absence of SET signatures, what the alternative requirements should be. I am proposing the following revised text for the “Unsecured Token” section: Per Section 6 <xref target="RFC7519"/>, tokens MAY be generated with <tt>{"alg":"none"}</tt>. This mode potentially speeds up processing by avoiding what would be redundant cryptographic processing. An example would be replication scenarios within a cluster (e.g. Kubernetes). Unencrypted tokens MUST be transferred over mutually-authenticated TLS layer encryption and SHOULD only be used in restricted network environments. Cheers, Phil phil.hunt@independentid.com <mailto:phil.hunt@independentid.com> Original text: 3.1. Security Event Token Signing and Encryption This specification uses Security Event Tokens as the message format for SCIM Events. As SETs are based on JWT tokens [RFC7519], they can be transmitted insecurely, signed, or encrypted. For more information see the JWT Cookbook specification [RFC7520] for examples. The decision on whether to use JWS and JWE depends on operational considerations. For each SCIM Feed relationship, it is up to deployers to decide on signing, encryption and algorithm requirements. Deployers SHOULD be aware that too much emphasis on turning on every possible encryption feature may cause operational performance to suffer. Deployers MUST weigh the security trade-offs of up-to-date SCIM services, vs. the potential information loss of an event. Unsecured Per Section 6 [RFC7519], tokens MAY be generated with {"alg":"none"}. This mode speeds up processing and is best used in DBR scenarios. Unencrypted tokens MUST be transferred over authenticated TLS layer encryption and SHOULD only be used in a restricted network environment. Signed JWS ([RFC7515]) signed SETs are useful when it is important to be able to verify the issuer of a SET as valid. In addition, some Hunt, et al. Expires 24 May 2024 [Page 27] ? Internet-Draft draft-ietf-scim-events November 2023 systems MAY wish to validate the authenticity of the event in a review process which may occur at a later date. While the content can be validated as originating from the correct issuer and is unmodified, the message contents remain unsecure. Signed SETs MUST be transferred over encrypted transport. Encrypted JWE ([RFC7516]) are encrypted SETs and are useful when the transport mechanism is not fully secured (e.g. messages carried by a third party). The use of JWEs ensures only the designated receiver can read the event and provides mutual authentication within the SET message itself. _______________________________________________ scim mailing list scim@ietf.org <mailto:scim@ietf.org> https://www.ietf.org/mailman/listinfo/scim
- [scim] SCIM Events Pull Request #20 - Unsecured T… Phillip Hunt
- Re: [scim] SCIM Events Pull Request #20 - Unsecur… Saxe, Dean
- [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt
- Re: [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt
- Re: [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt