From nobody Fri Jul 20 06:56:42 2018 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 39EA3131168 for ; Fri, 20 Jul 2018 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pQPfnc-t-91M for ; Fri, 20 Jul 2018 06:56:38 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 0DCEF1310E1 for ; Fri, 20 Jul 2018 06:56:38 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id s14-v6so9954972wmc.1 for ; Fri, 20 Jul 2018 06:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d8wELqJEyzlnj/8HDNUgMtImMjaApQwmSGc1nRHFJcA=; b=HOqvgAOzuP6VtNQYpWlcdqczaIBzbXsR0Wb32fbjw/MIGeLxtrVvboUdwbRxhXM7AW 07JzhznAfUY4EaQAqwHQUfLRPwUjgmiVHYe8MsPpnnHOG7ZQQuSj5jozdTmdTF0CntI2 qltSbmqfNgEkCRLwJTWN++OnVDkHcSNl60yh/ECKTYU66kgq9XLjhwy7qA43bgZ6PAcA 7PnIMo6MO4BtfYzvXYZPDpziGBt0x4VsMSyT3AgI6SCaTjrdw0PEoRIuuRjp6z5t6Yqx xtJBiEash1PntKnQgjNYvqGDrvSENt2Gg2GEw+gTy7YfYeZBRJaWJ/1pZIv93P83mDVk BgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d8wELqJEyzlnj/8HDNUgMtImMjaApQwmSGc1nRHFJcA=; b=S9zHkxdu9PIi9Rvb4SAyeqSiOLoc1rIDQ6lMw5pW3dmfIbpMgaDktoAGxov9054H24 kQ1UGybYG8WyTKvvfM9OjDeJQpDAxjGjYGvpfYgoroeo/8S/yDy4Av3gn5VrLGFhx1Dw lMEUWQo7kTTIG/ibVe9l0vHVIOD8WNPwpp5MeV8sb4siqMIzh/0fb5BFUSB9vGa4vDBG Vnk85/3JqeRitaxBCBrVnEjs33gG+2HUV7k3a2bOXQGSR4VLKXSWFrJplqHLt4oz/eUY PjPeuVQl4f91GN2LOmbh/0X3cFh376E5GYue8rIjPeWM0Pe55aOWbs4Si0F2cSe93RbX rYOQ== X-Gm-Message-State: AOUpUlHZKn2M0J0x5XrcdDrN8s3Mo1YEIzXU/keVVTXXcJ+2Qx6+wyBd Z0vOk/Sd1lRKab5w+Kw5Ab7+epEhjTq7Q7EeqVl8UA== X-Google-Smtp-Source: AAOMgpcefcAskcWAE57G/d3yVGmuEWzZ5UsP2rFyyDo42HARKiCPBHFLDObFotx7Dn4gt520/htdQSUuUrDxWJckZRo= X-Received: by 2002:a1c:8010:: with SMTP id b16-v6mr1714637wmd.41.1532094996249; Fri, 20 Jul 2018 06:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:d105:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 06:56:35 -0700 (PDT) From: Matt Randall Date: Fri, 20 Jul 2018 08:56:35 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="0000000000000380fe05716eaa50" Archived-At: Subject: [scim] Storing "federated" user identifiers using SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 13:56:40 -0000 --0000000000000380fe05716eaa50 Content-Type: text/plain; charset="UTF-8" Our company has an interesting use case - I was curious if any members of the group had encountered it when developing their own SaaS platform, if there were perhaps an existing schema / schema attribute that I had overlooked, or if there is some sort of existing convention for the following use case? For our SaaS platform, we want to enable our customers to push users to our platform and enable those users to log in with a potential multiplicity of identity providers (1:M relationship between a user and their individual identities at different identity provider(s)). This would require the storage of both the "issuer" (SAML entity ID, OIDC Issuer) and principal (and, in the case of SAML, potentially the NameID type.) I'd imagine this type of data would be modeled as a multi-valued attribute of user whose values are complex attributes, containing the 2-3 prerequisite data points mentioned above. To date, we had always aligned SCIM as a 1:1 feed with an identity provider, requiring the IdP's asserted principal to match the SCIM username. We're encountering scenarios where it would be useful for customers to have a single feed where users use potentially different identity providers, and where a single user might be serviced by multiples. Does anyone else share our use case in this community, or perhaps encountered an existing pattern for this? Thank you, - Matt Randall --0000000000000380fe05716eaa50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our company has an interesting use case - I was curio= us if any members of the group had encountered it when developing their own= SaaS platform, if there were perhaps an existing schema / schema attribute= that I had overlooked, or if there is some sort of existing convention for= the following use case?

For our SaaS platform= , we want to enable our customers to push users to our platform and enable = those users to log in with a potential multiplicity of identity providers (= 1:M relationship between a user and their individual identities at differen= t identity provider(s)).=C2=A0 This would require the storage of both the &= quot;issuer" (SAML entity ID, OIDC Issuer) and principal (and, in the = case of SAML, potentially the NameID type.)

I'= d imagine this type of data would be modeled as a multi-valued attribute of= user whose values are complex attributes, containing the 2-3 prerequisite = data points mentioned above.

To date, we had alway= s aligned SCIM as a 1:1 feed with an identity provider, requiring the IdP&#= 39;s asserted principal to match the SCIM username.=C2=A0 We're encount= ering scenarios where it would be useful for customers to have a single fee= d where users use potentially different identity providers, and where a sin= gle user might be serviced by multiples.=C2=A0 Does anyone else share our u= se case in this community, or perhaps encountered an existing pattern for t= his?

Thank you,

- Matt Ra= ndall

--0000000000000380fe05716eaa50-- From nobody Fri Jul 20 09:01:03 2018 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 5AD0F129385 for ; Fri, 20 Jul 2018 09:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 NXaETNSxj-AK for ; Fri, 20 Jul 2018 09:00:55 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 BB56B130FDB for ; Fri, 20 Jul 2018 09:00:55 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6KFwu3J001717; Fri, 20 Jul 2018 16:00:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=xupEmxbE5w1s+00X7bRvE4B9OCZ19RVjNLaYB0Xw7eY=; b=aZTZmcuCOXgfEpY1QnzIRQroMGrDGbekHfZomv3oqpjsHMIpVa0RZve7kjOMzP9IPlv3 LHBiY06qv0mvjiYw+nQhZdUjUXM29K1kdUBNLHnsxy/ZyE0PS9V1XaITO3zkEkBSHZxG bmL1I+UA9qLiPB4DmoUsdra+jv59/37tkSL6bbXhA8nVy3zjtq2fCFiyfP+FHkhFR+gR 0Jx124KlcHFqfWbB0JpC9PAp9X9/Y/yubrf08JxbaZ2yeDF5fUP85XJeGDJe4+LtZsni bMnn5MlHZNXGK3eToOLJGLLSZNnQLF1Gispxvnqt5dZw4ZAYK27BfrcO0HLacWDn0nNd lA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2k9yjguv97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 16:00:52 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6KG0pZo009472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 16:00:52 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6KG0p5Q031776; Fri, 20 Jul 2018 16:00:51 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Jul 2018 09:00:51 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DAD0B047-015B-4CC5-BC29-08525D828415" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 20 Jul 2018 09:00:48 -0700 In-Reply-To: Cc: scim@ietf.org To: Matt Randall References: X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200178 Archived-At: Subject: Re: [scim] Storing "federated" user identifiers using SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 16:01:02 -0000 --Apple-Mail=_DAD0B047-015B-4CC5-BC29-08525D828415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Matt, I think this is an interesting question. It may be that a new claim = should be defined for tracking identifier relationships with IDPs when = users associate more than one IDP. It goes beyond classic federation and also includes implicit federation = through things like email and telephone numbers. For example, a telephone number used as a verification channel (e.g. = sms) vs. telephone number for phone calls is different. IMO, the phone attribute in SCIM should not be used for this purpose. So here is the issue. While such a spec might be useful to tell people = how they might do this, is it important from an inter-op perspective = that people migrate to a common way of doing it? Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Jul 20, 2018, at 6:56 AM, Matt Randall = wrote: >=20 > Our company has an interesting use case - I was curious if any members = of the group had encountered it when developing their own SaaS platform, = if there were perhaps an existing schema / schema attribute that I had = overlooked, or if there is some sort of existing convention for the = following use case? >=20 > For our SaaS platform, we want to enable our customers to push users = to our platform and enable those users to log in with a potential = multiplicity of identity providers (1:M relationship between a user and = their individual identities at different identity provider(s)). This = would require the storage of both the "issuer" (SAML entity ID, OIDC = Issuer) and principal (and, in the case of SAML, potentially the NameID = type.) >=20 > I'd imagine this type of data would be modeled as a multi-valued = attribute of user whose values are complex attributes, containing the = 2-3 prerequisite data points mentioned above. >=20 > To date, we had always aligned SCIM as a 1:1 feed with an identity = provider, requiring the IdP's asserted principal to match the SCIM = username. We're encountering scenarios where it would be useful for = customers to have a single feed where users use potentially different = identity providers, and where a single user might be serviced by = multiples. Does anyone else share our use case in this community, or = perhaps encountered an existing pattern for this? >=20 > Thank you, >=20 > - Matt Randall >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D4huGrUWTzM7INaDfFAyjd= X5Zuv-IroMCn7fvjCf-S6k&s=3DR8YOT-RYy6UdMSYBx62oRmMBpzTpv_qJOLpZXoeiuSM&e=3D= --Apple-Mail=_DAD0B047-015B-4CC5-BC29-08525D828415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Matt,

I think this = is an interesting question. It may be that a new claim should be defined = for tracking identifier relationships with IDPs when users associate = more than one IDP.

It = goes beyond classic federation and also includes implicit federation = through things like email and telephone numbers.

For example, a = telephone number used as a verification channel (e.g. sms) vs. telephone = number for phone calls is different.

IMO, the phone attribute in SCIM should = not be used for this purpose.

So here is the issue. While such a spec = might be useful to tell people how they might do this, is it important = from an inter-op perspective that people migrate to a common way of = doing it?

Phil

Oracle = Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jul 20, 2018, at 6:56 AM, Matt Randall <matthew.a.randall@gmail.com> wrote:

Our company has an interesting use case - I = was curious if any members of the group had encountered it when = developing their own SaaS platform, if there were perhaps an existing = schema / schema attribute that I had overlooked, or if there is some = sort of existing convention for the following use case?

For = our SaaS platform, we want to enable our customers to push users to our = platform and enable those users to log in with a potential multiplicity = of identity providers (1:M relationship between a user and their = individual identities at different identity provider(s)).  This = would require the storage of both the "issuer" (SAML entity ID, OIDC = Issuer) and principal (and, in the case of SAML, potentially the NameID = type.)

I'd = imagine this type of data would be modeled as a multi-valued attribute = of user whose values are complex attributes, containing the 2-3 = prerequisite data points mentioned above.

To date, we had always aligned SCIM as = a 1:1 feed with an identity provider, requiring the IdP's asserted = principal to match the SCIM username.  We're encountering scenarios = where it would be useful for customers to have a single feed where users = use potentially different identity providers, and where a single user = might be serviced by multiples.  Does anyone else share our use = case in this community, or perhaps encountered an existing pattern for = this?

Thank = you,

- Matt = Randall

_______________________________________________
scim = mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3D4huGrUWTzM7INaDfFAyjdX5Zuv-IroMCn7fvjCf-S6k&s=3DR8YOT-RYy6UdMSYB= x62oRmMBpzTpv_qJOLpZXoeiuSM&e=3D

= --Apple-Mail=_DAD0B047-015B-4CC5-BC29-08525D828415--