Re: [scim] User extension for not valid before / after ?

Phillip Hunt <phil.hunt@independentid.com> Wed, 07 September 2022 17:19 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 F370EC14F736 for <scim@ietfa.amsl.com>; Wed, 7 Sep 2022 10:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 317FKcPlIAED for <scim@ietfa.amsl.com>; Wed, 7 Sep 2022 10:19:27 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 5D729C14F72A for <scim@ietf.org>; Wed, 7 Sep 2022 10:19:27 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d82so1668621pfd.10 for <scim@ietf.org>; Wed, 07 Sep 2022 10:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=8FOEvPScYgn9C35pLjglvFsaTGNZ/TNSOuurnYm7GVw=; b=OxXfOpP4pT7DVXeUi3mh6Lu6kx4MZJGGo3Dnh3MmuJs7MlWCh34MxHefBNY7wf7NgG /2BrYmHMB2Vwl3aUmrq2T9knVDake/cmLgc4+74Rz6ri/iXOds4+Lvs+jegWyWftMRU8 CB3YBaVdWwODLXawt5iz8hn52ef9myIerE16ihf1CGOTy3c2nZdaBbJZNIoonPKbSDXU Uzpv3QlJok7ymBK9dnLUXxwsgXPyRgKg2ZgfxcBZHnULBeFKC2UBBj8HTlpG2bS6lbtJ cLOcQoWHq+XYAFyTk2KYaBaXM5zt66qJTiA8gMDXTTruKY5bmyrbjQbUEPjAxp7aovwD m6wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date; bh=8FOEvPScYgn9C35pLjglvFsaTGNZ/TNSOuurnYm7GVw=; b=HM+jdZuioDN3kuoT2quDwRKY5TJUDD0SOIVahDSEVz8JvbiV5/PUVc7nY769tFP4Uy eUK8BL9AbSw6DBo7gwIdMBgOXcgB4ys4X8mfTIaT3GMU3hhWOB1xBPjDHS1VevdSDUDc TQ3Bgmy2StzXEXzkPo9sSf5AIU9Cux8A05+xia2y8rmAlPWREZSL8TulQKRwCv6PGh8+ zRgIhzZIjR4ToFnNf1g4eMcWwWMZeAY9h2N+cG4RJoNJmWZ04/gLV7JB2y1hr7plhlH/ 9wjGcZfO+KY0GtXaHXgBupcFf38QMX/cC7KjvvzWCmyMFFwMf8tA0ZGF/yg1Qjhbn9D7 sv7A==
X-Gm-Message-State: ACgBeo39INvJCjSZ0RQpFauK+g02Tsqlok2FZxRt5oGgj1L/o31eFUo9 8yS2WJBqXYP8s08M8TlPKBVqQUmIvxHN0Q==
X-Google-Smtp-Source: AA6agR78YAj8rPWMCEjoHfxdF1xY0Y19HeF7qwTjy0Eu1Z5JaQ4oJLJJFwDvgiI9jzJBNsVyJbLbJQ==
X-Received: by 2002:a63:465e:0:b0:430:326c:7e6e with SMTP id v30-20020a63465e000000b00430326c7e6emr4283736pgk.84.1662571166137; Wed, 07 Sep 2022 10:19:26 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9plyoqwsy9vdkl9rcoi3.ipv6.telus.net. [2001:569:540c:4900:387e:8ae2:10ef:160b]) by smtp.gmail.com with ESMTPSA id bf10-20020a170902b90a00b00172ff99d0afsm12608607plb.140.2022.09.07.10.19.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 10:19:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-757D5DB9-A5F8-406D-ABF0-9A55EE8DC8B5"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 07 Sep 2022 10:19:20 -0700
Message-Id: <E716D387-EDA3-4BAF-B7DF-65C9F5CC58CC@independentid.com>
References: <CAKzrJhZ=soh18bXSn7sR=q66mqG=vK0q5ebj4Efx_a2H26V1jQ@mail.gmail.com>
Cc: scim@ietf.org
In-Reply-To: <CAKzrJhZ=soh18bXSn7sR=q66mqG=vK0q5ebj4Efx_a2H26V1jQ@mail.gmail.com>
To: Yoann Gini <y@bravas.io>
X-Mailer: iPhone Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/u78ZcgMOMymtrlNGRZ2ip7Pio8g>
Subject: Re: [scim] User extension for not valid before / after ?
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: Wed, 07 Sep 2022 17:19:31 -0000

Yoann

Thanks for your input. 

I think there have been two scenarios discussed at various times:

1. Account life cycle schema:  eg the start and end of an account.  Could be new attributes in a new schema extension (like enterprise user works).

2. Attribute metadata. This can be things like verification status, expiry, but for attributes. Was this email verified?  When does a role expire? Etc. 

The first one is easy, the second one needs some thoughts. Eg turning existing simple attributes into complex ones(with sub attributes) and be backwards compatible may be tricky. 

I am talking to a client about this as well, so there does seem to be interest in the issue from several orgs. 

Another thing to think about. Specialized schema that is only used in a single environment does not necessarily need to be standardized or registered in IANA. The question is what is the interop requirement? Does this data need to be shared between domains with different implementations?  

Phil

> On Sep 7, 2022, at 6:58 AM, Yoann Gini <y@bravas.io> wrote:
> 
> 
> Hello,
> 
> I'm new to this mailing list so I will quickly introduce myself. I'm Yoann Gini, CTO of a french startup called Bravas who just raised money to build an MDM+IDP all in once, with a big focus on passwordless and modern management for SMBs.
> 
> One of our main work will be to work with SCIM as server to get identities from HRIS and as client to push them in cascade to all federated services.
> 
> One of the issues we have right now is the need for us to know the validity window of an EnterpriseUser.
> 
> For audit purposes and identity lifecycle we consider that all EnterpriseUser in our solution need to have a some attributes defining the contract start date and end date. Some kind of "not valid before" and "not valid after".
> 
> Which can also be extended in depth with hold window, for example with birth vacations, when someone is not supposed to work for a long period of time but still employed, the not valid before/after dates does not change, but we may want to add an "on hold" overlay for that vacation time.
> 
> This is not covered by User or EnterpriseUser scheme, and I do not see other scheme at all here https://www.iana.org/assignments/scim/scim.xhtml 
> 
> Is this kind of need already covered by a Draft? If yes, where to find it/them? If not, do some people here want to collaborate on something? 
> 
> And since I'm new to this list, if this is not the correct way to question existing work in progress on specific topics like that, let me know how and where I should ask.
> 
> Best regards
> Yoann Gini
> 
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim