[scim] IETF 115 Corrections to Presentation on Paging Regarding Polling for Security Event specification

Phillip Hunt <phil.hunt@independentid.com> Mon, 14 November 2022 20:30 UTC

Return-Path: <phil.hunt@independentid.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C0490C14F72F for <scim@ietfa.amsl.com>; Mon, 14 Nov 2022 12:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6hRPKKJ6Q3sP for <scim@ietfa.amsl.com>; Mon, 14 Nov 2022 12:30:03 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5ABC14F724 for <scim@ietf.org>; Mon, 14 Nov 2022 12:30:03 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id o7so11411939pjj.1 for <scim@ietf.org>; Mon, 14 Nov 2022 12:30:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=kXRIFLqse6CBFdK1EYxo6lJH570YgoTrRX31LHKbMo4=; b=0rg5JYqMtPz1F4FYJEEMVbK44hHNcRmaMrdYiuTYtAUcoW9QQsC4E5ez/BYq49Cu7B /F7ynmpKOtDOg75H3D9CQ2jd/GVufeDRP/WEMfTOa09/Err2zfVIhwonohFYorxv/lov sUBDJgRuR3+6G48F+Ipk53IAPfUYISAhvL4rLCg/tyxozM/PmgbnNMVcUzVUZql0JABE hrGwEbtWqPpaW3lMOo0U+LjvmtR/L3+LJJknoMbGDgvx9afp42F+C9bAQgeLxkSjOjGk t9Eie8VW52T3FMVYKR0zDm1WfEOc8i4gLx2nQEQDjAAXwy0rJwj20NXwcrFNkQeB0xTy K9GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kXRIFLqse6CBFdK1EYxo6lJH570YgoTrRX31LHKbMo4=; b=511ShD1zIB6BkxGHfWg1CQhQTInR2t59NWH7a5xShkT5XRmQ+0TFqO4CMG2sj2nCDF eTWIuB/YFtEEqVNQHcw08uCkNN/imopHDhZMv3WtHwRG4slOYzzc9tzkEeQTNXhKJVaV 5G4j2mzz+AGYGiYU9AS9Q3+TMWjT6dfH2aOxZyr3PY/oWE1rYbKFj/qRzu3U/ItjkDyb VRwiMzfLDLkuzrzH73mKNSEWEtII1x+Ti7LGIDg98fN4Ei8ALQyuwMLBEOkZ3uWI6mw+ Hh+5zCVGrmuD0mlZpbBFfkwwqBN/4cTirUU8W5TqhMMAv0PWBrqqqXHFWzV0yA3pk/8J J0Fg==
X-Gm-Message-State: ANoB5plMi30vVUeMuwZO7w+CWMcrcDC/HUbipJw5GjyQNif+o8GGfa+E limNL1Y41r7C/Bc3e8xOI3bkyXAY5zHeMw==
X-Google-Smtp-Source: AA0mqf6Pc/KuGcqQDaLPECRLJ1B12WaZnv+UGOLnx7Ok+ItSWy6PWjLevD8FIj8/LE+/KJyvte2xQw==
X-Received: by 2002:a17:903:40d0:b0:182:2589:db21 with SMTP id t16-20020a17090340d000b001822589db21mr772999pld.151.1668457802420; Mon, 14 Nov 2022 12:30:02 -0800 (PST)
Received: from smtpclient.apple (node-1w7jr9plyoqwtkyflilv3qte1.ipv6.telus.net. [2001:569:540c:4900:61ed:181f:e3f7:a649]) by smtp.gmail.com with ESMTPSA id c14-20020a62f84e000000b0052d4cb47339sm7084331pfm.151.2022. for <scim@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2022 12:30:02 -0800 (PST)
From: Phillip Hunt <phil.hunt@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE919B8C-08D9-4931-B1AA-6FE920CCECC4"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Message-Id: <AEA3377D-6002-4F26-B3B0-AD890BB5226A@independentid.com>
Date: Mon, 14 Nov 2022 12:30:01 -0800
To: SCIM WG <scim@ietf.org>
X-Mailer: Apple Mail (2.3696.
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/rMfRss6MIFxVU86yN1xBh6XZUzE>
Subject: [scim] IETF 115 Corrections to Presentation on Paging Regarding Polling for Security Event specification
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, 14 Nov 2022 20:30:08 -0000

As I mentioned on the list before, I was unable to attend the meeting. I just watched the youtube replay of the meeting and I would like to correct some inaccurate information in the paging presentation about SCIM Events.  

This may be because the presenter is not considering the SecEvents workging group SET POLL Transfer RFC8936 (https://www.rfc-editor.org/rfc/rfc8936) which was authored by Microsoft  (Mike Jones and Tony Nadalin), Google, Amazon among others among others. I thought I had mentioned this a couple of times before.

I am paraphrasing the discussion from Danny and others in the room and I hope I have the quotes somewhat close...

Statement: “SCIM Events must be pushed to receivers” 

SET POLL Transfer (RFC8936) is  “polling” as per its name. It works in much the same way as the paging draft.  It does not require separate infrastructure and can be implemented much in the same way as Paging and Delta drafts (but with one protocol).  Rather than return raw SCIM Resources it returns signed JWT/SET objects containing events (which contain transactions and other information).

Statement: "SCIM Events can drop Events on the floor"

Incorrect. Both SecEvent SET transfer RFCs mandate that transfer must be a secure transfer. The specs require the receiver to acknowledge once the event has been securely retained.  If events are dropped on the floor, the implementation is not compliant with the RFCs. Quoting:
> The purpose of the acknowledgement is to inform the SET Transmitter that delivery has succeeded and redelivery is no longer required. Before acknowledgement, SET Recipients validate the received SETs and retain them in a manner appropriate to the recipient's requirements. The level and method of retention of SETs by SET Recipients is out of scope of this specification.

I think what the commentator was concerned about was that specifications do not mandate infinite recovery.  Keep in mind that the SecEvents work covers a wide variety of cases all sharing the use of JWT based messages and requirements varry widely.  For example, in the case of “Logout” messages it makes no sense to retain these messages. In the CASE of SCIM, service providers can indeed maintain events indefinitely. Further, retention can be implemented on publisher or receiver sides OR both! This is far far from “dropping on the floor”.

Statement: “SCIM Events at large scale is going to be a firehose”

One group of event definitions are ultra light weight serving the function that the delta draft proposes. It is equivalent to the idea of the delta draft. In paging, clients are pulling a copy of the entire data set every sync cycle on a schedule.  I stuggle to imagine how one can conclude that brute force downloads scales better than per change notices.  Microsoft, Google, Amazon, and Oracle worked together to produce the SET transfer RFCs (8935 and 8936) specifically to address the scaling issues.

Further, use of the OpenID Shared  Signals framework has the additional value of being able to define which entities a receiver wants and can be part of a consent system. So for example, if a SCIM endpoint has millions or billions of users, a receiver can select specific Users to sync with instead of eating the whole elephant as they say.

Statement: "SCIM Events requires a separate server” 

There is nothing saying that a separate infrastructure is needed. One can certainly have SCIM nodes issue events and transfer them directly using polling. This would be the monolithic architecture approach.   There is nothing saying a SCIM server cannot directly support RFC8936 endpoints. As with the alternate proposed drafts, a receiving client still has to process (and in the case of paging detect changes) and decide what to do in the local domain.

Statement: “SCIM Events reverses the flow”

Well in effect that is the intent of all of the proposals to be able to detect changes in a remote provider and co-ordinate locally.  As for HTTP protocol inversion, either side can initiate requests depending on the method chosen. Thus, Security Events can be exchanged with initiation from either end.  The SCIM Service Provider can “PUSH” using RFC8935, or the SCIM Receiver (client) can initiate with a “POLL” using RFC8936.

I hope the working group finds this useful.

Phillip Hunt