Re: [scim] Charter Discussion: Triggers

Phillip Hunt <phil.hunt@independentid.com> Wed, 14 July 2021 05:59 UTC

Return-Path: <phil.hunt@independentid.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 C9F8A3A1123 for <scim@ietfa.amsl.com>; Tue, 13 Jul 2021 22:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.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 PUvVeWIiuKnq for <scim@ietfa.amsl.com>; Tue, 13 Jul 2021 22:59:31 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 009323A1121 for <scim@ietf.org>; Tue, 13 Jul 2021 22:59:30 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id g4-20020a17090ace84b029017554809f35so3062574pju.5 for <scim@ietf.org>; Tue, 13 Jul 2021 22:59:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:message-id:date :cc:to; bh=b3b9Ya8uwuRyE5e+NUh2g6Z4YdNVp6J1Htd3XclO+Kg=; b=lDPyUcTjYObmHHE5c20++dvJrqtWlOz98o1upS3+KcWEC/FVhZC3UxG5YEnSgy9YMD w/zrEj0XX9BIJQ70soT7qPW6DZFeiXX5wnhDu1MDGNx9KG0sQ8cAmHSrfAO9/gZPHXCd fHjtVSTYvfmFyi1KQ7Wr3PQ497+RNyNspUyOD3MCtmn3RetU8B6omP8h8qYJhzLf1ZuV hhuHGcwmvE+jF5hhx4n83R/OPd1FM94KYpCjKjlzBLuV09SwJWA8hT9N9h5PyTHy0+Fx rQbvBWwzigGYTBPlHQ23fwyizGW7vgru2hA79MPhdIgeFI+O4dHbBiqcNudPbeaHih7X GvbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:cc:to; bh=b3b9Ya8uwuRyE5e+NUh2g6Z4YdNVp6J1Htd3XclO+Kg=; b=mTrCnHWkxXN8vxZbCIxhPe63XRjzxmI7Z6zIQvk/qHpnVJFXdh2QjfOIkFi4jmL/Gn mWF6H2OmnV4C3XvSnK1RpWTcdfZtdUd65pGDs7TgVp+m7qo3kQPhOs9InmgmeY6D65oT VZr6/k6RAxxWsBnNRC+xY9tQWxyDjvD1IJeaqj/jT7SXMgU+GTPPswzEb/2VKcKRkUau wHJMJ4WBSYNkgcCHgK3dvjOOC+jbHXvHBrI1F6kJptoL8h2kj+WLPLX7C4C5rdXnTHzD IwVGAt/TKwPLA7H9jkaoCdZ0Gk2GkD/OO0ci5rWfCf8Cy8mDh3piZ/puJCeCkEFBJSdy 2ANQ==
X-Gm-Message-State: AOAM533NBWQiKj2MrKJ3MTfJFscEW6z9v/XyITitS2VHU5cdLn1CW3DQ qXZ5zMGEmcYqS6l4cr26g1U9Ug==
X-Google-Smtp-Source: ABdhPJzOp2b2pQQOo1eGnWBR9TNMskkGRiH7qFd9jkldnYRtaZhgKMVC+sn00QTBnf0ElRzQLIut/Q==
X-Received: by 2002:a17:90a:e56:: with SMTP id p22mr8046286pja.73.1626242369804; Tue, 13 Jul 2021 22:59:29 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qrfoxxar1xbfr02uks1.ipv6.telus.net. [2001:569:7a71:1d00:d430:6a5e:e7b4:76b1]) by smtp.gmail.com with ESMTPSA id m1sm4754412pjk.35.2021.07.13.22.59.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 22:59:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-D79851DC-82AE-4ED7-930B-74D6B54376B8
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Message-Id: <5FFBE771-7012-4F19-B2AE-B07541C41332@independentid.com>
Date: Tue, 13 Jul 2021 22:59:27 -0700
Cc: SCIM WG <scim@ietf.org>
To: Matt Domsch <matt@domsch.com>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Hqj-JQS2GlZQs14iGFI0sWm8Ix8>
Subject: Re: [scim] Charter Discussion: Triggers
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 14 Jul 2021 05:59:37 -0000

 I was heavily involved in these specs. The sET delivery specs aren’t competing (RFCs 8935,8936). The presence of 2 methods may look that way because some cloud providers would not implement polling (eg for firewalled enterprise customers) while others said it was critical. Polling consumes scarce tcp/ip connections and thus costly to scale in some OIDC provider scenarios with large numbers of clients in 100ks or much more. The very rough consensus decision of the WG was to split the draft. 

Still both drafts are almost identical except for push vs poll. Delivery is assured as client receivers are given time to ack transfer success. The ack means the publisher no longer has to retain the event (unlike a changelog). 

The limit of short recovery was a compromise because major providers felt they could not keep events forever for 100ks of clients (eg a single oidc provider and all registered clients).  I don’t believe that is the case in scim scenarios. Scim scrnarios are more balanced.  

In both drafts the client can recover within an unspecified “short” period of time.  I would expect that in scim cases this could be indefinite. 

My belief is this would be easy to implement if you already implemented bulk processing. Unlike bulk endpoint, there are no temporary identifier issues. My implementation prototype simply uses bulk operation messages now. 

Subject identifier is interesting but i think that may be part of a another discussion around external id. Its a huge can of worms if endpoints cannot agree on identifiers. 

Phil

> On Jul 13, 2021, at 8:37 PM, Matt Domsch <matt@domsch.com> wrote:
> 
> I certainly see value in a standardized mechanism to notify subscribers about changes (C/U/D) to objects that would otherwise only be recognized by polling the whole list of objects periodically.  Both Shared Signals / IETF Subject Identifiers, augmented with SCIM object schema, would be a fine representation method.  There are several competing transport methods (SET Push and/or Shared Signals subscriptions) still to be worked out. These would allow real-time notification of object changes, which is highly desirable.   However, these are still "best effort delivery" methods and events can fail to be generated, fail in transport, or fail to be received, meaning systems wanting to maintain as accurate a synchronization as possible may still periodically, though considerably less frequently, poll for the entire object list again.  Therefore you can't supplant one with the other, both would still be necessary.  For the benefits in the majority of cases though it'd be great to have event-delivered changes.
> -Matt
> 
> On Wed, Jul 7, 2021 at 11:23 AM Phil Hunt <phil.hunt@independentid.com> wrote:
>> In the discussion about cursors, it occured to me that some queries are happening as a form of polling by one or more client entities in order to co-ordinate state of user entries across many clients and domains.
>> 
>> Way back when, the original SCIM WG charter had an item called “triggers”. Triggers were events that could be distributed to registered clients to notify them of events. Some of the cursor use cases could be addressed with async triggers (events) rather than using “polling with cursors”t. 
>> 
>> The triggers concept wasn’t actually abandoned,  The work on events did actually go forward (in the SECEVENT WG) and was published as RFC8417  (aka Security Event Tokens).   OpenID Connect as an example uses SETs to notify parties of a logout in the back channel.  The OpenID Shared Signals group is also defining events, many of which, occur within SCIM servers.
>> —> Would defining SCIM Events go a long way to avoid the need for cursors in at least some cases (e.g. notifying receivers that a resource was deleted or a password updated)?  Should we put this on the table?
>> 
>> —> is this something the group would like to pick up and exploit now that the underlying message format is defined?
>> 
>> On the call today, it was also brought up that the interaction pattern of client initiating against the server may need to evolve/expand. Async SET events may be one possibility. To solve these cases.
>> 
>> Phil Hunt
>> @independentid
>> phil.hunt@independentid.com
>> 
>> 
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim