From nobody Thu Sep 8 01:12:30 2022 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 379E5C1524C5 for ; Thu, 8 Sep 2022 01:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bravas-io.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 xNQl0jaYoi07 for ; Thu, 8 Sep 2022 01:12:27 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450: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 560A8C1524C3 for ; Thu, 8 Sep 2022 01:12:26 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id o25so76182wrf.9 for ; Thu, 08 Sep 2022 01:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bravas-io.20210112.gappssmtp.com; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :from:to:cc:subject:date; bh=H2UMpYUWS7MGJVD8O6OXdDWW+n4uR5o8dObgjkXZ8AI=; b=5JmPoc0CS9TPWReXvGfYIpUgHVwVYYWG/kQVa5/RsXeXuHH9ESgXmr+sCu6MoFBHQi TdWFkDFUWS9iUZIAg1g+g2byMz2l6BZGSmlsoKdzy5V8PYh+BrElttSPcRVD4sROlcbW ehDr8/GMYtnYDn/g0sZGV445jkebfCeHMnYv5oPO7ZbbyCu1dv/V2caUHV9DA6E73sFO WrXxybnNd6QTOtxkkMuavf24hvqofEz0HTYTE++nqaFgNCbhfxDx3JcJh/r1bdjV4dX5 v2xXKwYFCpNj/gmdsSCEnAj9t8WzWvrRPEkrsDi7aUj72atCWJRuP8hCjK1OQ8yt3dAH Ovvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :x-gm-message-state:from:to:cc:subject:date; bh=H2UMpYUWS7MGJVD8O6OXdDWW+n4uR5o8dObgjkXZ8AI=; b=XLBY7sMztnIJPdmmBKOtfmphGi+112LBHYEbqqbT0IAJuSI64T07JAQxv2gDMLK4iD mf5uowhvPujRe81j2SQyBqkPr0fornqxxrWcvRYS6t1EfulJHXUl3/NfJWusNlAh3ezd IjRbWozo4TJLhPYLirhYa4vU/BpMuLpgIYq5ncL0Pk5psz7s3a7kUQh+AF0H90ihxW70 SFUeton/XaoNhuHZDuhJ7yazGjjqI8BTb6HGAkSqSa1omCYBhTZACAdROVxSIsYKOhAH 8+PKbBi82v0CHeEZG6sY/7ijU2NzJot+GVnJEWToQWWNdq4d7gP2lptHK+fBaLNb42N8 wWNA== X-Gm-Message-State: ACgBeo2p96qGYzZUHyBxh6rcaI6kV0kjyOxLbFHy+6Lpu+E6r8OQBSKS WRyZI7C63pNvWZf/aWsCh5ZLjo+TTmg7Iw== X-Google-Smtp-Source: AA6agR7/WYRHfYzhw38x7EJC0ISwebf9FF708gEeIB9Ry0YF4DBU4Ldk4JQgHCcOim9bzhwyDJ5XPw== X-Received: by 2002:a05:6000:1c0d:b0:225:6c66:5ed3 with SMTP id ba13-20020a0560001c0d00b002256c665ed3mr4361465wrb.678.1662624744922; Thu, 08 Sep 2022 01:12:24 -0700 (PDT) Received: from smtpclient.apple (2a01cb068015be9ccdb3b9042cd68461.ipv6.abo.wanadoo.fr. [2a01:cb06:8015:be9c:cdb3:b904:2cd6:8461]) by smtp.gmail.com with ESMTPSA id h28-20020a05600c2cbc00b003b332a7bf15sm770446wmc.7.2022.09.08.01.12.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2022 01:12:24 -0700 (PDT) From: Yoann Gini Content-Type: multipart/alternative; boundary="Apple-Mail=_46C94D40-96B1-4BC2-AB0C-03CBCAD9368B" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Date: Thu, 8 Sep 2022 10:12:22 +0200 References: To: scim@ietf.org In-Reply-To: Message-Id: <15D5AD08-E4BF-4111-833A-821F2280897C@bravas.io> X-Mailer: Apple Mail (2.3696.120.41.1.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2022 08:12:29 -0000 --Apple-Mail=_46C94D40-96B1-4BC2-AB0C-03CBCAD9368B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello > Le 7 sept. 2022 =C3=A0 19:19, Phillip Hunt = a =C3=A9crit : >=20 > I think there have been two scenarios discussed at various times: >=20 > 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). That's our target right now, start/end from lifecycle perspective and = hold time for long vacation such as maternity leave. > 2. Attribute metadata. This can be things like verification status, = expiry, but for attributes. Was this email verified? When does a role = expire? Etc.=20 This one seems to be a complex (but legitimate) one for which I don't = have enough data and experience to work on. > I am talking to a client about this as well, so there does seem to be = interest in the issue from several orgs.=20 It should be a natural request from all orgs that are moving to HRIS = Based Identity Management. Usual workflow around it allows to be sure that hardware is provisioned = in time but account cannot be used before legal start. Some company = defines some policies that create for example the mailbox a week before = the legal start with mailing inclusion, but the account can logon only = when legally allowed. This allows them to onboard people with some = context for ongoing discussion, for example. > 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? =20 That's the key point here. The reason I was looking for a standard or a = draft is because this information needs to be exchanged between HRIS and = IDP when adopting HRIS Based Identity Management. So the goal here would be to have a standard representation method that = would allow any HRIS system to provide lifecycle and on hold information = to org's IDP. Regardless of the brand of each. It seems to be a good use = case for SCIM registered schema. > Le 7 sept. 2022 =C3=A0 22:26, Danny Mayer a = =C3=A9crit : >=20 > This gets into the issue of what's confidential information for HR = systems. I did send out a message about some of that but it hasn't = really been discussed. I can probably dig it back out. You also really = need to understand the privacy requirements of different countries and = the EU. Being French and for 14 years in the field of identity management for = organization, I do have some sensibility regarding privacy requirements. Here for the need of identity lifecycle and hold events, I gave the = example of maternity leave. The goal was to give an example of use. However, the reason why people = have their account on hold for X months is not a useful information in = SCIM I would say (or at least should be an option field that people will = use or not). Some example of legal reason in France to put an account on hold in = France will be, for example =E2=80=94 maternity leave =E2=80=94 military reservists called back to service=20 =E2=80=94 prison time (FR org are required to keep them in the employees = and give them back their job once their time is done) etc. An extension for "HRISUser" could be, for example =E2=80=94 notValidBefore =E2=80=94 notValidAfter =E2=80=94 holdPeriods =E2=80=94=E2=80=94 startDate =E2=80=94=E2=80=94 endDate =E2=80=94=E2=80=94 reason (optional) That's what I see as useful from my own perspective and would be = interested to work on something if we are multiple to agree on a need = for standardized extension. Yoann= --Apple-Mail=_46C94D40-96B1-4BC2-AB0C-03CBCAD9368B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello

Le 7 sept. 2022 =C3=A0 19:19, = Phillip Hunt <phil.hunt@independentid.com> a =C3=A9crit :

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).

That's= our target right now, start/end from lifecycle perspective and hold = time for long vacation such as maternity leave.

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

This one seems to be a complex (but legitimate) = one for which I don't have enough data and experience to work = on.

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

It = should be a natural request from all orgs that are moving to HRIS Based = Identity Management.

Usual workflow = around it allows to be sure that hardware is provisioned in time but = account cannot be used before legal start. Some company defines some = policies that create for example the mailbox a week before the legal = start with mailing inclusion, but the account can logon only when = legally allowed. This allows them to onboard people with some context = for ongoing discussion, for example.

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? =  

That's the key point here. The reason I was looking for a = standard or a draft is because this information needs to be exchanged = between HRIS and IDP when adopting HRIS Based Identity = Management.

So = the goal here would be to have a standard representation method that = would allow any HRIS system to provide lifecycle and on hold information = to org's IDP. Regardless of the brand of each. It seems to be a good = use case for SCIM registered schema.

Le 7 sept. 2022 =C3=A0 22:26, Danny Mayer <mayer@pdmconsulting.net> a =C3=A9crit :

This gets into the = issue of what's confidential information for HR systems. I did send out = a message about some of that but it hasn't really been discussed. I can = probably dig it back out. You also really need to understand the privacy = requirements of different countries and the EU.

Being = French and for 14 years in the field of identity management for = organization, I do have some sensibility regarding privacy = requirements.

Here for the need of identity lifecycle and hold events, I = gave the example of maternity leave.

The goal was to give an example of = use. However, the reason why people have their account on hold for X = months is not a useful information in SCIM I would say (or at least = should be an option field that people will use or not).

Some example of legal = reason in France to put an account on hold in France will be, for = example
=E2=80=94 maternity leave
=E2=80=94 military reservists called back to = service 
=E2=80=94 prison time (FR org are = required to keep them in the employees and give them back their job once = their time is done)

etc.

An extension for "HRISUser" could be, for example
=E2=80=94 notValidBefore
=E2=80=94 = notValidAfter

=E2=80=94 holdPeriods
=E2=80=94=E2=80=94 = startDate
=E2=80=94=E2=80=94 endDate
=E2=80=94=E2=80=94 reason (optional)

That's what I see as useful from my own = perspective and would be interested to work on something if we are = multiple to agree on a need for standardized extension.

Yoann
= --Apple-Mail=_46C94D40-96B1-4BC2-AB0C-03CBCAD9368B--