From nobody Sun Oct 4 11:27:35 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577311B347F for ; Sun, 4 Oct 2015 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 hiqrONXWuntR for ; Sun, 4 Oct 2015 11:27:32 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (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 2F5521B347D for ; Sun, 4 Oct 2015 11:27:32 -0700 (PDT) Received: by qgx61 with SMTP id 61so133113307qgx.3 for ; Sun, 04 Oct 2015 11:27:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=C4Sq/iF7Oh+D4CXO3NW8bxexaiYcufqQzbFuvrnyp00=; b=S63QYQAlswlkr3mylYAJDhECrIsjS43jBFV1Ble80nkexgV591AWRUdHp870gAZEkB VLMtVTWb2LCvvNz8X6vE9pjAwuiWZPCtgMOW6MHe/ImqMMGBP6JlAVcZRL0zRNVee5ai a6W0jqlBmIEMjAF+bh9hSe59NrvZEIzTAwZh/5iFQ2rtdOxOG1UtqCkoNIaV8Ts0Ztvm CXpFhQzpVgoCpSWCvySSmR152lLiMZwaNzA88kvbaDoQ4NslsRCJYarZBbcy5gI/mLQu ItyPBE6SKz7Ez7P7+mrmExcK1aVKea6WgtIn1vA35V3tZFcL1y/sW+o1lZnJzbzTB4oP +uIw== X-Gm-Message-State: ALoCoQm42f6QwMBKtOR16sfo9p2PGw49WMDkIOW5os6hFjlZhWIDuqfMFe6A8ZUQmlHXVF0Xks6b X-Received: by 10.140.234.23 with SMTP id f23mr36471727qhc.1.1443983251286; Sun, 04 Oct 2015 11:27:31 -0700 (PDT) Received: from [10.12.136.13] ([192.171.20.23]) by smtp.googlemail.com with ESMTPSA id o65sm9414657qhb.21.2015.10.04.11.27.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2015 11:27:30 -0700 (PDT) To: scim@ietf.org References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> From: Leif Johansson Message-ID: <56116F92.80202@mnt.se> Date: Sun, 4 Oct 2015 20:27:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 18:27:33 -0000 On 2015-09-30 09:07, Erik Wahlström neXus wrote: > Thursday works for me, not Friday. > / Erik > did you guys have a call? From nobody Mon Oct 5 07:43:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504491ACE87 for ; Mon, 5 Oct 2015 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 iVY2L3k0D5XI for ; Mon, 5 Oct 2015 07:43:22 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 138F01ACE99 for ; Mon, 5 Oct 2015 07:43:22 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so122938912wic.1 for ; Mon, 05 Oct 2015 07:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type; bh=wc1a4nysfkUUuNfCRVNn20t2rWOD63ad5160R7molgM=; b=gB5pRYB2wMEgWWlijLyDfazoFu39GMqIcTUEtVvqCsu8LZGvCJ/l3pmS4Z7d6M9+nl jlgWWVaOVrdijNhRyiOvfXLh555zwO2tL8CVSHTXvIlxll/j3SdRzFSr5atjX+iLuhqQ dnmvn00UbV7uy/149a2dOHu4CAHYDK9awF4NT7GKaYqDmIKlyR8j48XiyR/MYTjn04ug jbO/aORVcBHmT6C7Qe0vX8NbfYUTMvCP3qS8tTvngavvz6TvupwlWeuNu84b1L8wGOG1 B6AY45v+D6GagmT7+BHnx8l/R8XcZ8ugqB15PICvI37adumCJSznG5xp2IWV7GcMi4rG dCgQ== X-Gm-Message-State: ALoCoQnSxJPAPm8odZXCMXvYVSruIWtyyZxY8/grB9Nvf/zKlpCHSrYxPPXJ0HO2oI1PItQTwstL X-Received: by 10.194.80.71 with SMTP id p7mr29253925wjx.83.1444056200477; Mon, 05 Oct 2015 07:43:20 -0700 (PDT) Received: from speedyM.local (ip5651156e.adsl-surfen.hetnet.nl. [86.81.21.110]) by smtp.googlemail.com with ESMTPSA id r4sm14990375wia.19.2015.10.05.07.43.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 07:43:19 -0700 (PDT) To: scim@ietf.org From: Mark Dobrinic X-Enigmail-Draft-Status: N1110 Message-ID: <56128C3A.6050402@twobotechnologies.com> Date: Mon, 5 Oct 2015 16:42:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070909000903050602000805" Archived-At: Subject: [scim] Multiple external id values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 14:43:25 -0000 This is a multi-part message in MIME format. --------------070909000903050602000805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Scim people, While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec. Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider. Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well. For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'. As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better. What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0" that defines an attribute "externalIds", is of type "complex", is multiValued, can be described as "External Identities of a user. Each External Identity is scoped within its domain", is optional, and has the following sub-attributes: - value : string value containing the value of the external id - type : string value containing the domain of the external id In JSON, it would look like this: { "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "externalId":"bjensen", .... "urn:scim:schemas:extensions:external-ids:1.0": { "externalIds": [ { "value": "babs", "type": "home" }, { "value": "labarbara", "type": "work" }] } } Note that we are adding to the baseline features of Scim, and not changing anything existing. I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions. Thanks! -- Regards, Mark Dobrinic Software Engineer and Identity Specialist Twobo Technologies AB mark.dobrinic@twobotechnologies.com www.twobotechnologies.com --------------070909000903050602000805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Scim people,

While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.

What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
- type : string value containing the domain of the external id

In JSON, it would look like this:

                {
                "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
                "id":"2819c223-7f76-453a-919d-413861904646",
                "userName":"bjensen",
                "externalId":"bjensen",
                ....
                "urn:scim:schemas:extensions:external-ids:1.0": {
                    "externalIds": [
                        {
                            "value": "babs",
                            "type": "home"
                        },
                        {
                            "value": "labarbara",
                            "type": "work"
                        }]
                    }
                }



Note that we are adding to the baseline features of Scim, and not changing anything existing.


I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.


Thanks!

-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
--------------070909000903050602000805-- From nobody Mon Oct 5 08:17:48 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756ED1ACED2 for ; Mon, 5 Oct 2015 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 C4nEiF37tcCi for ; Mon, 5 Oct 2015 08:17:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7F76B1ACF57 for ; Mon, 5 Oct 2015 08:17:44 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t95FHhu7010894 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2015 15:17:43 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t95FHgBJ004967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 15:17:42 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t95FHgBa010345; Mon, 5 Oct 2015 15:17:42 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Oct 2015 08:17:42 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-17F1BB1F-F6C1-47B5-9FF0-C27632675DD8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13A452) In-Reply-To: <56128C3A.6050402@twobotechnologies.com> Date: Mon, 5 Oct 2015 08:17:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <56128C3A.6050402@twobotechnologies.com> To: Mark Dobrinic X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Multiple external id values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:17:46 -0000 --Apple-Mail-17F1BB1F-F6C1-47B5-9FF0-C27632675DD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This was discussed and the consensus was single value.=20 What you can do is expose a different single value for each domain client yo= ur server talks to. Thus domains cannot see each other's ids. The spec alre= ady suggests this as a security consideration for the id value.=20 This would provide much better privacy characteristics and reduces propagati= on of PII.=20 Phil > On Oct 5, 2015, at 07:42, Mark Dobrinic wrote: >=20 > Hi Scim people, >=20 > While incorporating Scim client functionality towards a Scim Service Provi= der, we've stumbled upon a limitation regarding our desired use of externalI= d, that doesn't fit the current spec. >=20 > Our usecase involves managing multiple external id's, so that we can both s= upport multiple externalId's to multiple Scim Clients from one Scim Service P= rovider, as well as let a Scim Client manage multiple external id's with one= Scim Service Provider. Each external id lives within the domain of a, well= , domain. There are plenty of real world examples where domain-scoped id's a= re used, so it seems no more than natural to consider this with Scim as well= . >=20 > For example, a user with id barbara has an externalId 'babs' in the domain= 'home', and externalId 'labarbara' in domain 'work'. >=20 > As I understand Scim as being as effective and simple as possible, we've b= een using the extensibility of Scim to make this work. I can imagine this to= be a generic problem that more people are (or will be) facing. Therefore, I= 'd like to propose our solution and would like to discuss whether this could= /should be considered a standard solution to a standard problem, either in t= his form or something better. >=20 > What we did was introduce an extension " urn:scim:schemas:extensions:exter= nal-ids:1.0" > that defines an attribute "externalIds", > is of type "complex", > is multiValued, > can be described as "External Identities of a user. Each External Identity= is scoped within its domain", > is optional, > and has the following sub-attributes: > - value : string value containing the value of the external id > - type : string value containing the domain of the external id >=20 > In JSON, it would look like this: >=20 > { > "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schema= s:extensions:external-ids:1.0" ], > "id":"2819c223-7f76-453a-919d-413861904646", > "userName":"bjensen", > "externalId":"bjensen", > .... > "urn:scim:schemas:extensions:external-ids:1.0": { > "externalIds": [ > { > "value": "babs", > "type": "home" > }, > { > "value": "labarbara", > "type": "work" > }] > } > } >=20 >=20 >=20 > Note that we are adding to the baseline features of Scim, and not changing= anything existing. >=20 >=20 > I would like to hear your feedback on this, and I'm interested whether thi= s could be considered as a standard extension in upcoming Scim versions. >=20 >=20 > Thanks! >=20 > --=20 > Regards, >=20 > Mark Dobrinic > Software Engineer and Identity Specialist > Twobo Technologies AB >=20 > mark.dobrinic@twobotechnologies.com > www.twobotechnologies.com > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-17F1BB1F-F6C1-47B5-9FF0-C27632675DD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

On Oct 5, 2015, at 07:42, Mark Dobrinic <mark.dobrinic@twobotechnologies.com> wrote:

Hi Scim people,

While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.

What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
- type : string value containing the domain of the external id

In JSON, it would look like this:

                {
                "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
                "id":"2819c223-7f76-453a-919d-413861904646",
                "userName":"bjensen",
                "externalId":"bjensen",
                ....
                "urn:scim:schemas:extensions:external-ids:1.0": {
                    "externalIds": [
                        {
                            "value": "babs",
                            "type": "home"
                        },
                        {
                            "value": "labarbara",
                            "type": "work"
                        }]
                    }
                }



Note that we are adding to the baseline features of Scim, and not changing anything existing.


I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.


Thanks!

-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--Apple-Mail-17F1BB1F-F6C1-47B5-9FF0-C27632675DD8-- From nobody Mon Oct 5 08:39:40 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617341AD070 for ; Mon, 5 Oct 2015 08:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 SKDrGF803FWj for ; Mon, 5 Oct 2015 08:39:34 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 1318C1A87B3 for ; Mon, 5 Oct 2015 08:39:34 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so120432518wic.0 for ; Mon, 05 Oct 2015 08:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=4RnSl2R7drSMrUISP1zKhLwl4YTyYsViFo/ljVLKAdk=; b=dohewax28pkeWc1R6rO5xVKBO1pMwvIF1Ak5bhznwLcOgknst2gEU3U/KZco0r76qM z6lxfeP0cLEmV3g+xA0t0ef1aZyABD0IGc6k7+C83J3b6i+UdIzvCijJxCx5CUxillEZ iSin5gJ7X8he9LGrn/SugnIEJlHyEKHdHqziztZL7fRHaGHjSQ0E5fPucdUWGcLym0DW s4+q4uaxKmDrOo1VcL37gInBbhQVMt7B2qgvfSZM14KBBt0IPVaFQqLJ8Kj6bQWBUt0/ AlkBW7RIVSGV/JsgcX6ayw63O0DB3/mxz7kV+8I+RVOd4fGUZIDIa43kG5m9yS7ptesY gktQ== X-Gm-Message-State: ALoCoQlclYiY6DFhPeHQ8hTb6nKvkD+mTm5nzq+wcJ2GNa4i2K6VJhqoXiud1/MwYKs08DjcsvNf X-Received: by 10.180.74.47 with SMTP id q15mr13094898wiv.73.1444059572556; Mon, 05 Oct 2015 08:39:32 -0700 (PDT) Received: from speedyM.local (ip5651156e.adsl-surfen.hetnet.nl. [86.81.21.110]) by smtp.googlemail.com with ESMTPSA id pl7sm15261048wic.4.2015.10.05.08.39.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Oct 2015 08:39:31 -0700 (PDT) To: Phil Hunt References: <56128C3A.6050402@twobotechnologies.com> From: Mark Dobrinic X-Enigmail-Draft-Status: N1110 Message-ID: <561299B2.9010305@twobotechnologies.com> Date: Mon, 5 Oct 2015 17:39:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020201050703050403010502" Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Multiple external id values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:39:37 -0000 This is a multi-part message in MIME format. --------------020201050703050403010502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Phil, Thanks for the quick response. The resolution to expose a client specific externalId only works in half the scenario's, where you have multiple clients all representing one domain. In the other scenario, where one client representing multiple domains is using one Scim Service Provider, the client actually relies on the Service Provider to store multiple identities for its multiple domains, so in that usecase it is multi-valued by design. Do I get it right that this particular use case has not yet come up then? Concerning the privacy cinsideration, given a trust relationship between the Scim Service Provider and the Scim Client (quite some features are based on this already), privacy characteristics of the solution are not of primary concern here. The Scim Client could (should) actually take over the responsibility for protecting privacy in this one. Cheers! Mark On 05/10/15 17:17, Phil Hunt wrote: > This was discussed and the consensus was single value. > > What you can do is expose a different single value for each domain > client your server talks to. Thus domains cannot see each other's > ids. The spec already suggests this as a security consideration for > the id value. > > This would provide much better privacy characteristics and reduces > propagation of PII. > > Phil > > On Oct 5, 2015, at 07:42, Mark Dobrinic > > wrote: > >> Hi Scim people, >> >> While incorporating Scim client functionality towards a Scim Service >> Provider, we've stumbled upon a limitation regarding our desired use >> of externalId, that doesn't fit the current spec. >> >> Our usecase involves managing multiple external id's, so that we can >> both support multiple externalId's to multiple Scim Clients from one >> Scim Service Provider, as well as let a Scim Client manage multiple >> external id's with one Scim Service Provider. Each external id lives >> within the domain of a, well, domain. There are plenty of real world >> examples where domain-scoped id's are used, so it seems no more than >> natural to consider this with Scim as well. >> >> For example, a user with id barbara has an externalId 'babs' in the >> domain 'home', and externalId 'labarbara' in domain 'work'. >> >> As I understand Scim as being as effective and simple as possible, >> we've been using the extensibility of Scim to make this work. I can >> imagine this to be a generic problem that more people are (or will >> be) facing. Therefore, I'd like to propose our solution and would >> like to discuss whether this could/should be considered a standard >> solution to a standard problem, either in this form or something better. >> >> What we did was introduce an extension " >> urn:scim:schemas:extensions:external-ids:1.0" >> that defines an attribute "externalIds", >> is of type "complex", >> is multiValued, >> can be described as "External Identities of a user. Each External >> Identity is scoped within its domain", >> is optional, >> and has the following sub-attributes: >> - value : string value containing the value of the external id >> - type : string value containing the domain of the external id >> >> In JSON, it would look like this: >> >> { >> "schemas": [ "urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extensions:external-ids:1.0" ], >> "id":"2819c223-7f76-453a-919d-413861904646", >> "userName":"bjensen", >> "externalId":"bjensen", >> .... >> "urn:scim:schemas:extensions:external-ids:1.0": { >> "externalIds": [ >> { >> "value": "babs", >> "type": "home" >> }, >> { >> "value": "labarbara", >> "type": "work" >> }] >> } >> } >> >> >> >> Note that we are adding to the baseline features of Scim, and not >> changing anything existing. >> >> >> I would like to hear your feedback on this, and I'm interested >> whether this could be considered as a standard extension in upcoming >> Scim versions. >> >> >> Thanks! >> >> -- >> Regards, >> >> Mark Dobrinic >> Software Engineer and Identity Specialist >> Twobo Technologies AB >> >> mark.dobrinic@twobotechnologies.com >> www.twobotechnologies.com >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- Regards, Mark Dobrinic Software Engineer and Identity Specialist Twobo Technologies AB mark.dobrinic@twobotechnologies.com www.twobotechnologies.com --------------020201050703050403010502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Phil,

Thanks for the quick response.

The resolution to expose a client specific externalId only works in half the scenario's, where you have multiple clients all representing one domain. In the other scenario, where one client representing multiple domains is using one Scim Service Provider, the client actually relies on the Service Provider to store multiple identities for its multiple domains, so in that usecase it is multi-valued by design.

Do I get it right that this particular use case has not yet come up then?

Concerning the privacy cinsideration, given a trust relationship between the Scim Service Provider and the Scim Client (quite some features are based on this already), privacy characteristics of the solution are not of primary concern here. The Scim Client could (should) actually take over the responsibility for protecting privacy in this one.

Cheers!

Mark




On 05/10/15 17:17, Phil Hunt wrote:
This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

On Oct 5, 2015, at 07:42, Mark Dobrinic <mark.dobrinic@twobotechnologies.com> wrote:

Hi Scim people,

While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.

What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
- type : string value containing the domain of the external id

In JSON, it would look like this:

                {
                "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
                "id":"2819c223-7f76-453a-919d-413861904646",
                "userName":"bjensen",
                "externalId":"bjensen",
                ....
                "urn:scim:schemas:extensions:external-ids:1.0": {
                    "externalIds": [
                        {
                            "value": "babs",
                            "type": "home"
                        },
                        {
                            "value": "labarbara",
                            "type": "work"
                        }]
                    }
                }



Note that we are adding to the baseline features of Scim, and not changing anything existing.


I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.


Thanks!

-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
--------------020201050703050403010502-- From nobody Mon Oct 5 08:56:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668D1B31FD for ; Mon, 5 Oct 2015 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZnpF8eWZ1mPX for ; Mon, 5 Oct 2015 08:56:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4C6D01B3206 for ; Mon, 5 Oct 2015 08:55:38 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t95FtaRd004809 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2015 15:55:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t95Ftax1001294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 15:55:36 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t95FtZsF022887; Mon, 5 Oct 2015 15:55:35 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Oct 2015 08:55:34 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-706BF07C-32BD-4A04-BF16-38D23772C719 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13A452) In-Reply-To: <561299B2.9010305@twobotechnologies.com> Date: Mon, 5 Oct 2015 08:55:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <56128C3A.6050402@twobotechnologies.com> <561299B2.9010305@twobotechnologies.com> To: Mark Dobrinic X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Multiple external id values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:56:04 -0000 --Apple-Mail-706BF07C-32BD-4A04-BF16-38D23772C719 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I did raise this issue.=20 The consensus was one and one only.=20 I do have a concern about multiple domains connecting to the same entity.=20= Does one see this as a client hub controlling multiple cloud spokes. Or does= one see this as multiple client spokes contributing to a common hub entity.= =20 The latter has PII propagation concerns.=20 I suspect most for now only care about the former.=20 Phil > On Oct 5, 2015, at 08:39, Mark Dobrinic wrote: >=20 > Hi Phil, >=20 > Thanks for the quick response. >=20 > The resolution to expose a client specific externalId only works in half t= he scenario's, where you have multiple clients all representing one domain. I= n the other scenario, where one client representing multiple domains is usin= g one Scim Service Provider, the client actually relies on the Service= Provider to store multiple identities for its multiple domains, so in that u= secase it is multi-valued by design. >=20 > Do I get it right that this particular use case has not yet come up then? >=20 > Concerning the privacy cinsideration, given a trust relationship between t= he Scim Service Provider and the Scim Client (quite some features are based o= n this already), privacy characteristics of the solution are not of primary c= oncern here. The Scim Client could (should) actually take over the responsib= ility for protecting privacy in this one. >=20 > Cheers! >=20 > Mark >=20 >=20 >=20 >=20 >> On 05/10/15 17:17, Phil Hunt wrote: >> This was discussed and the consensus was single value.=20 >>=20 >> What you can do is expose a different single value for each domain client= your server talks to. Thus domains cannot see each other's ids. The spec a= lready suggests this as a security consideration for the id value.=20 >>=20 >> This would provide much better privacy characteristics and reduces propag= ation of PII.=20 >>=20 >> Phil >>=20 >> On Oct 5, 2015, at 07:42, Mark Dobrinic wrote: >>=20 >>> Hi Scim people, >>>=20 >>> While incorporating Scim client functionality towards a Scim Service Pro= vider, we've stumbled upon a limitation regarding our desired use of externa= lId, that doesn't fit the current spec. >>>=20 >>> Our usecase involves managing multiple external id's, so that we can bot= h support multiple externalId's to multiple Scim Clients from one Scim Servi= ce Provider, as well as let a Scim Client manage multiple external id's with= one Scim Service Provider. Each external id lives within the domain of a, w= ell, domain. There are plenty of real world examples where domain-scoped id'= s are used, so it seems no more than natural to consider this with Scim as w= ell. >>>=20 >>> For example, a user with id barbara has an externalId 'babs' in the doma= in 'home', and externalId 'labarbara' in domain 'work'. >>>=20 >>> As I understand Scim as being as effective and simple as possible, we've= been using the extensibility of Scim to make this work. I can imagine this t= o be a generic problem that more people are (or will be) facing. Therefore, I= 'd like to propose our solution and would like to discuss whether this could= /should be considered a standard solution to a standard problem, either in t= his form or something better. >>>=20 >>> What we did was introduce an extension " urn:scim:schemas:extensions:ext= ernal-ids:1.0" >>> that defines an attribute "externalIds", >>> is of type "complex", >>> is multiValued, >>> can be described as "External Identities of a user. Each External Identi= ty is scoped within its domain", >>> is optional, >>> and has the following sub-attributes: >>> - value : string value containing the value of the external id >>> - type : string value containing the domain of the external id >>>=20 >>> In JSON, it would look like this: >>>=20 >>> { >>> "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:sche= mas:extensions:external-ids:1.0" ], >>> "id":"2819c223-7f76-453a-919d-413861904646", >>> "userName":"bjensen", >>> "externalId":"bjensen", >>> .... >>> "urn:scim:schemas:extensions:external-ids:1.0": { >>> "externalIds": [ >>> { >>> "value": "babs", >>> "type": "home" >>> }, >>> { >>> "value": "labarbara", >>> "type": "work" >>> }] >>> } >>> } >>>=20 >>>=20 >>>=20 >>> Note that we are adding to the baseline features of Scim, and not changi= ng anything existing. >>>=20 >>>=20 >>> I would like to hear your feedback on this, and I'm interested whether t= his could be considered as a standard extension in upcoming Scim versions. >>>=20 >>>=20 >>> Thanks! >>>=20 >>> --=20 >>> Regards, >>>=20 >>> Mark Dobrinic >>> Software Engineer and Identity Specialist >>> Twobo Technologies AB >>>=20 >>> mark.dobrinic@twobotechnologies.com >>> www.twobotechnologies.com >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 > Regards, >=20 > Mark Dobrinic > Software Engineer and Identity Specialist > Twobo Technologies AB >=20 > mark.dobrinic@twobotechnologies.com > www.twobotechnologies.com > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-706BF07C-32BD-4A04-BF16-38D23772C719 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I did raise this issue. 

The con= sensus was one and one only. 

<= /div>
I do have a concern about multiple domai= ns connecting to the same entity. 
=
Does one see this as a client hub c= ontrolling multiple cloud spokes. Or does one see this as multiple client sp= okes contributing to a common hub entity. 

The latter has PII propagat= ion concerns. 

I suspect most for now only care about the former. = ;

Phil

On Oct 5, 2015, at 08:39, Mark Dobrinic <mark.dobrinic@twobotechno= logies.com> wrote:

=20 =20 =20
Hi Phil,

Thanks for the quick response.

The resolution to expose a client specific externalId only works in half the scenario's, where you have multiple clients all representing one domain. In the other scenario, where one client representing multiple domains is using one Scim Service Provider, the client actually relies on the Service Provider to store multiple identities for its multiple domains, so in that usecase it is multi-valued by design.

Do I get it right that this particular use case has not yet come up then?

Concerning the privacy cinsideration, given a trust relationship between the Scim Service Provider and the Scim Client (quite some features are based on this already), privacy characteristics of the solution are not of primary concern here. The Scim Client could (should) actually take over the responsibility for protecting privacy in this one.

Cheers!

Mark




On 05/10/15 17:17, Phil Hunt wrote:
This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus= domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

On Oct 5, 2015, at 07:42, Mark Dobrinic <ma= rk.dobrinic@twobotechnologies.com> wrote:

Hi Scim people,

While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.

What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
= - type : string value containing the domain of the external id
=
In JSON, it would look like this:

           =      {
           =      "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
           =      "id":"2819c223-7f76-453a-919d-413861904646",
           =      "userName":"bjensen",
           =      "externalId":"bjensen",
             &nb= sp;  ....
           =      "urn:scim:schemas:extensions:external-ids:1.0": {
           =          "externalIds": [
           =              {            =             &nbs= p;    "value": "babs",
           =             &nbs= p;    "type": "home"
           =              },<= br>              &nb= sp;          {
           =             &nbs= p;    "value": "labarbara",
           =             &nbs= p;    "type": "work"
           =              }]<= br>            =          }
           =      }



Note that we are adding to the baseline features of Scim, and not changing anything existing.


I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.


Thanks!

--=20
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
_______________________________________________ scim mailing list
sc= im@ietf.org
https://www.ietf.org/mailman/listinfo/scim 


--=20
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
=20
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-706BF07C-32BD-4A04-BF16-38D23772C719-- From nobody Mon Oct 5 10:05:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A81AD37C for ; Mon, 5 Oct 2015 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 iOjYbjfPgBuk for ; Mon, 5 Oct 2015 10:05:13 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 746041AD377 for ; Mon, 5 Oct 2015 10:05:12 -0700 (PDT) Received: by wicge5 with SMTP id ge5so130090441wic.0 for ; Mon, 05 Oct 2015 10:05:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=kpTrzuKXFSLqvvFADZmXRrI/SF+1e36KZ4rHN0RPIuo=; b=fNjR2Bqa0W7s1Le4wM6N+ZcrRVOWOb8hp62eRQGBX8aLNtuvM22N4lrC1LfO65CkXk 0rT2PHx+AQrW84cZN6gTKIgUqNlnoWaNRva61+wAh37hey3Y/Xult6b5C3P+vT+auRT3 V8XMAA0cItvYtBZOSEneS2NUhrM40XPJR26NXsBx1QeP6Vba2p4zY5ieALwBPFO4eH+E mycG7M68e7PCfznT9ev/zCZkAhbxANYsVJeMr84j7eE5dbKZnAqsgp6fj2zWak7flw0W YfPbQf5K3auKePfVgv2JdbyfSJtJmigiCOvs286JdAwQR76PN/YKPkJGxzPVRiNtbLAj 0s+Q== X-Gm-Message-State: ALoCoQnR5YQkBusIqJHXdPGREH9FMOFBVrlSPNkXsilqFArXi4uxaQ8PLEM2mlOzz8abblKQ6nOk X-Received: by 10.180.86.39 with SMTP id m7mr13575268wiz.91.1444064710972; Mon, 05 Oct 2015 10:05:10 -0700 (PDT) Received: from speedyM.local (ip5651156e.adsl-surfen.hetnet.nl. [86.81.21.110]) by smtp.googlemail.com with ESMTPSA id kb9sm27880507wjb.49.2015.10.05.10.05.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 10:05:10 -0700 (PDT) To: Phil Hunt References: <56128C3A.6050402@twobotechnologies.com> <561299B2.9010305@twobotechnologies.com> From: Mark Dobrinic Message-ID: <5612ADC5.10709@twobotechnologies.com> Date: Mon, 5 Oct 2015 19:05:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000801060504070202040109" Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Multiple external id values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:05:17 -0000 This is a multi-part message in MIME format. --------------000801060504070202040109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In our particular case, you can indeed see that the client acts as a hub, applying multiple external identities for multiple domains. I totally agree that is is generally a bad idea to expose an identity that is registered with a client for domain A, to a client for domain B. Not for minimizing PII exposure primarily, but for exposing information that weakens the linkability property of privacy with identifiers. This is not what we try to solve though. It is that first case. We'd like to use Scim towards a backend system for the client-as-hub-case. The externalId attribute can not help with that. That's why I try to raise a general solution that does. Putting it in an extension as described is totally acceptable though. I don't feel like disturbing the choices that were made through consensus, but I do feel like coming up with a general solution for that alternative usecase. Including possible privacy implications. On 05/10/15 17:55, Phil Hunt wrote: > I did raise this issue. > > The consensus was one and one only. > > I do have a concern about multiple domains connecting to the same entity. > > Does one see this as a client hub controlling multiple cloud spokes. > Or does one see this as multiple client spokes contributing to a > common hub entity. > > The latter has PII propagation concerns. > > I suspect most for now only care about the former. > > Phil > > On Oct 5, 2015, at 08:39, Mark Dobrinic > > wrote: > >> Hi Phil, >> >> Thanks for the quick response. >> >> The resolution to expose a client specific externalId only works in >> half the scenario's, where you have multiple clients all representing >> one domain. In the other scenario, where one client representing >> multiple domains is using one Scim Service Provider, the client >> actually relies on the Service Provider to store multiple identities >> for its multiple domains, so in that usecase it is multi-valued by >> design. >> >> Do I get it right that this particular use case has not yet come up then? >> >> Concerning the privacy cinsideration, given a trust relationship >> between the Scim Service Provider and the Scim Client (quite some >> features are based on this already), privacy characteristics of the >> solution are not of primary concern here. The Scim Client could >> (should) actually take over the responsibility for protecting privacy >> in this one. >> >> Cheers! >> >> Mark >> >> >> >> >> On 05/10/15 17:17, Phil Hunt wrote: >>> This was discussed and the consensus was single value. >>> >>> What you can do is expose a different single value for each domain >>> client your server talks to. Thus domains cannot see each other's >>> ids. The spec already suggests this as a security consideration for >>> the id value. >>> >>> This would provide much better privacy characteristics and reduces >>> propagation of PII. >>> >>> Phil >>> >>> On Oct 5, 2015, at 07:42, Mark Dobrinic >>> wrote: >>> >>>> Hi Scim people, >>>> >>>> While incorporating Scim client functionality towards a Scim >>>> Service Provider, we've stumbled upon a limitation regarding our >>>> desired use of externalId, that doesn't fit the current spec. >>>> >>>> Our usecase involves managing multiple external id's, so that we >>>> can both support multiple externalId's to multiple Scim Clients >>>> from one Scim Service Provider, as well as let a Scim Client manage >>>> multiple external id's with one Scim Service Provider. Each >>>> external id lives within the domain of a, well, domain. There are >>>> plenty of real world examples where domain-scoped id's are used, so >>>> it seems no more than natural to consider this with Scim as well. >>>> >>>> For example, a user with id barbara has an externalId 'babs' in the >>>> domain 'home', and externalId 'labarbara' in domain 'work'. >>>> >>>> As I understand Scim as being as effective and simple as possible, >>>> we've been using the extensibility of Scim to make this work. I can >>>> imagine this to be a generic problem that more people are (or will >>>> be) facing. Therefore, I'd like to propose our solution and would >>>> like to discuss whether this could/should be considered a standard >>>> solution to a standard problem, either in this form or something >>>> better. >>>> >>>> What we did was introduce an extension " >>>> urn:scim:schemas:extensions:external-ids:1.0" >>>> that defines an attribute "externalIds", >>>> is of type "complex", >>>> is multiValued, >>>> can be described as "External Identities of a user. Each External >>>> Identity is scoped within its domain", >>>> is optional, >>>> and has the following sub-attributes: >>>> - value : string value containing the value of the external id >>>> - type : string value containing the domain of the external id >>>> >>>> In JSON, it would look like this: >>>> >>>> { >>>> "schemas": [ "urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extensions:external-ids:1.0" ], >>>> "id":"2819c223-7f76-453a-919d-413861904646", >>>> "userName":"bjensen", >>>> "externalId":"bjensen", >>>> .... >>>> "urn:scim:schemas:extensions:external-ids:1.0": { >>>> "externalIds": [ >>>> { >>>> "value": "babs", >>>> "type": "home" >>>> }, >>>> { >>>> "value": "labarbara", >>>> "type": "work" >>>> }] >>>> } >>>> } >>>> >>>> >>>> >>>> Note that we are adding to the baseline features of Scim, and not >>>> changing anything existing. >>>> >>>> >>>> I would like to hear your feedback on this, and I'm interested >>>> whether this could be considered as a standard extension in >>>> upcoming Scim versions. >>>> >>>> >>>> Thanks! >>>> >>>> -- >>>> Regards, >>>> >>>> Mark Dobrinic >>>> Software Engineer and Identity Specialist >>>> Twobo Technologies AB >>>> >>>> mark.dobrinic@twobotechnologies.com >>>> www.twobotechnologies.com >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >> >> >> -- >> Regards, >> >> Mark Dobrinic >> Software Engineer and Identity Specialist >> Twobo Technologies AB >> >> mark.dobrinic@twobotechnologies.com >> www.twobotechnologies.com >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- Regards, Mark Dobrinic Software Engineer and Identity Specialist Twobo Technologies AB mark.dobrinic@twobotechnologies.com www.twobotechnologies.com --------------000801060504070202040109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
In our particular case, you can indeed see that the client acts as a hub, applying multiple external identities for multiple domains.

I totally agree that is is generally a bad idea to expose an identity that is registered with a client for domain A, to a client for domain B. Not for minimizing PII exposure primarily, but for exposing information that weakens the linkability property of privacy with identifiers.

This is not what we try to solve though. It is that first case. We'd like to use Scim towards a backend system for the client-as-hub-case. The externalId attribute can not help with that.

That's why I try to raise a general solution that does.

Putting it in an extension as described is totally acceptable though. I don't feel like disturbing the choices that were made through consensus, but I do feel like coming up with a general solution for that alternative usecase. Including possible privacy implications.


On 05/10/15 17:55, Phil Hunt wrote:
I did raise this issue. 

The consensus was one and one only. 

I do have a concern about multiple domains connecting to the same entity. 

Does one see this as a client hub controlling multiple cloud spokes. Or does one see this as multiple client spokes contributing to a common hub entity. 

The latter has PII propagation concerns. 

I suspect most for now only care about the former. 

Phil

On Oct 5, 2015, at 08:39, Mark Dobrinic <mark.dobrinic@twobotechnologies.com> wrote:

Hi Phil,

Thanks for the quick response.

The resolution to expose a client specific externalId only works in half the scenario's, where you have multiple clients all representing one domain. In the other scenario, where one client representing multiple domains is using one Scim Service Provider, the client actually relies on the Service Provider to store multiple identities for its multiple domains, so in that usecase it is multi-valued by design.

Do I get it right that this particular use case has not yet come up then?

Concerning the privacy cinsideration, given a trust relationship between the Scim Service Provider and the Scim Client (quite some features are based on this already), privacy characteristics of the solution are not of primary concern here. The Scim Client could (should) actually take over the responsibility for protecting privacy in this one.

Cheers!

Mark




On 05/10/15 17:17, Phil Hunt wrote:
This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

On Oct 5, 2015, at 07:42, Mark Dobrinic <mark.dobrinic@twobotechnologies.com> wrote:

Hi Scim people,

While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.

Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.

For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.

As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.

What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
that defines an attribute "externalIds",
is of type "complex",
is multiValued,
can be described as "External Identities of a user. Each External Identity is scoped within its domain",
is optional,
and has the following sub-attributes:
- value : string value containing the value of the external id
- type : string value containing the domain of the external id

In JSON, it would look like this:

                {
                "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
                "id":"2819c223-7f76-453a-919d-413861904646",
                "userName":"bjensen",
                "externalId":"bjensen",
                ....
                "urn:scim:schemas:extensions:external-ids:1.0": {
                    "externalIds": [
                        {
                            "value": "babs",
                            "type": "home"
                        },
                        {
                            "value": "labarbara",
                            "type": "work"
                        }]
                    }
                }



Note that we are adding to the baseline features of Scim, and not changing anything existing.


I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.


Thanks!

-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Twobo Technologies AB

mark.dobrinic@twobotechnologies.com
www.twobotechnologies.com
--------------000801060504070202040109-- From nobody Mon Oct 5 15:12:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66301A6EE7 for ; Mon, 5 Oct 2015 15:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pjaWC_8ap-m7 for ; Mon, 5 Oct 2015 15:12:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF7C1A6EE2 for ; Mon, 5 Oct 2015 15:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bgBJAvfaaMjRw6cHLW640YBQZZ4QXIjnloNJZY7/WgY=; b=lZO1Zb+UFzcKzXnbCitAuNGbe3aNzSIhIMHlK0fcIDKGXYDPKVZ27zK5lSKze4rDiERrR7p8ezoGtAfjUv5Wi23g1VWoYJhJWqCP6hVaUkOGfT0CRHkgrxkQ1a4gVo/Y/0MmMHjRs5tSeOLaYt9Cd26/9lhMsc2iUWETlV0lCgU= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 22:12:21 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0286.019; Mon, 5 Oct 2015 22:12:21 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Call this week Thread-Index: AQHQ+vdixJB0n0Yg6UmGJi2Nw/8i855T+QhQgAASRACAAJwHAIAHB2YAgAFY0AA= Date: Mon, 5 Oct 2015 22:12:20 +0000 Message-ID: References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> <56116F92.80202@mnt.se> In-Reply-To: <56116F92.80202@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [64.134.100.215] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:/LIU8y/9ses5tVYz/kO1Mu3pQ0QQKOvlt8Ikc3zjZ8aneAqy32hTwPxhfOcEfpAE2ccx7LlmwGbncm2JMV4chAnBQtnkLi2djIvqhwCz0IHBWKSaRmHyZPR8uhtTvo5LADwals2oSD0Da4r49Vf0fA==; 24:dxsQQdasVxfRU6xYPbzzLpXkTGkx2qcYOQWjNK7l6IQPrDdPVtqCAyErGJxfviwd+HB2PrYiOPhrBfnp4PLr5j6gYQgoi83r8ay/A9+ZxF0=; 20:04i+RU4FHTgbxXdHvUesxujdp4jdaPkyY3yotYj894YIz6SOa8witLfvsRbukIOKH4fukiCPh2+c9uVhbVRJtw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 07200C0526 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(189002)(16813002)(377454003)(377424004)(199003)(17383004)(66066001)(8990500004)(40100003)(87936001)(33656002)(122556002)(64706001)(93886004)(46102003)(74316001)(19580395003)(5003600100002)(19580405001)(106116001)(106356001)(10290500002)(5005710100001)(86612001)(50986999)(101416001)(54356999)(76176999)(102836002)(99286002)(575784001)(86362001)(15975445007)(107886002)(10090500001)(5001960100002)(77096005)(5004730100002)(2501003)(10400500002)(2900100001)(105586002)(5001770100001)(5001920100001)(5002640100001)(92566002)(5007970100001)(2950100001)(76576001)(11100500001)(5008740100001)(81156007)(97736004)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2015 22:12:21.1239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 22:12:47 -0000 yes -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Sunday, October 4, 2015 11:28 AM To: scim@ietf.org Subject: Re: [scim] Call this week On 2015-09-30 09:07, Erik Wahlstr=F6m neXus wrote: > Thursday works for me, not Friday. > / Erik >=20 did you guys have a call? _______________________________________________ scim mailing list scim@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com%7= cf0af1fbb33ed42d9809908d2cce97b53%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd= ata=3DWBftVaoFTJKJOxLlu71ca7%2bf2BJKj80mIP%2bjVitKemk%3d From nobody Mon Oct 5 15:53:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1671A6FFA for ; Mon, 5 Oct 2015 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9_al97aqlvfK for ; Mon, 5 Oct 2015 15:53:36 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA1F1A7003 for ; Mon, 5 Oct 2015 15:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1200; q=dns/txt; s=iport; t=1444085617; x=1445295217; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TnqQw0C3EZcfKE9iZoL8rskPNen+eR8OTwZ9iKDmKL4=; b=ghFQbK87XuwAoTlNIJeYd9Li6SdxZXvIqeMtbQBZn4OAK7tXRBjxDXyh 09gnfeG8DUknijpjE06EkNh0Np8URxsufllu3FL8eeW6TdoX4amfjq+S3 2EzJlK7OeJQGqp71MTZQkq1Dt1+xBvMWm0rm81WXYcx9PVmu8DEIIvkGi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DyAQAr/xJW/4gNJK1egydUbga+DgENgVoXDIJcgxsCgTY4FAEBAQEBAQGBCoQkAQEBBAEBAWsXBAIBCA4DBAEBAScHJwsUCQgCBAESiBkDEg25EBiFAQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOEfoRaOgaEJgWFfodDiD0BhRaIAJtlHwEBQoIRHYFUcQEBAYc2gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,641,1437436800"; d="scan'208";a="194634394" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 05 Oct 2015 22:53:26 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t95MrPhA022664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 22:53:25 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 17:53:24 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 17:53:24 -0500 Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 17:53:24 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Call this week Thread-Index: AQHQ+vdi2Mh32xF07kOM+0pW53Lt5J5UTQCAgAASHgCAAJwGAIAHB2YAgAHRJwD//5YeAA== Date: Mon, 5 Oct 2015 22:53:23 +0000 Message-ID: References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> <56116F92.80202@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [173.36.7.15] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 22:53:38 -0000 Note that it wasn=B9t a working group call. We talked about a couple of potential new drafts as extensions including the discovery options that were discussed on the list. Cheers, Morteza On 10/5/15, 3:12 PM, "scim on behalf of Anthony Nadalin" wrote: >yes > >-----Original Message----- >From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson >Sent: Sunday, October 4, 2015 11:28 AM >To: scim@ietf.org >Subject: Re: [scim] Call this week > >On 2015-09-30 09:07, Erik Wahlstr=F6m neXus wrote: >> Thursday works for me, not Friday. >> / Erik >>=20 > >did you guys have a call? > >_______________________________________________ >scim mailing list >scim@ietf.org >https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f. >org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com%7= cf >0af1fbb33ed42d9809908d2cce97b53%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda >ta=3DWBftVaoFTJKJOxLlu71ca7%2bf2BJKj80mIP%2bjVitKemk%3d > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Mon Oct 5 16:00:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D11A8766 for ; Mon, 5 Oct 2015 16:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7o1t5jlslru8 for ; Mon, 5 Oct 2015 15:59:59 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 BDBE81A8763 for ; Mon, 5 Oct 2015 15:59:59 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t95MxwN9018171 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2015 22:59:59 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t95Mxv4J019499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 22:59:58 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t95MxvpA011662; Mon, 5 Oct 2015 22:59:57 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Oct 2015 15:59:57 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: Date: Mon, 5 Oct 2015 15:59:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A178263-0BAD-4704-A0E1-83DBA7F54DBF@oracle.com> References: <36E5390F-CB49-490A-9BB5-30CFD545DA4A@nexusgroup.com> <56116F92.80202@mnt.se> To: Tony Nadalin X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Call this week X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 23:00:02 -0000 Summary of the informal last week. These are just my recollections - so = please feel to correct and add on. Attendees: * Erik Wahlstrom * Tony Nadalin * Mike Jones * Morteza Ansari * Ian Glazer As the WG is now between charters, some of us decided to talk about some = of the items that have been discussed on the list. Some items are new, = some are old. At this stage without more formal group discussion, I = would not take this as any indication of priority. This is just what we = managed to get through in the short time we had. :-) We discussed the following items: Well-known: The general feeling is that a simple well-known response for discovery = of a SCIM root is strongly desirable. There was less consensus on WebFinger. Mike indicated this would be = helpful particularly in multi-tenancy scenarios because it could help a = client locate a tenancy specific SCIM service provider based on a filter = (e.g. userid or emails). Notify: Ian and Morteza indicated interest in getting back to work on this. We = noted that there was a presentation from Confyrm at the Cloud Identity = Summer about inter cloud-provider events. Maybe this could tie in? I = (Phil) reported that the work on WebPUSH seems to be more divergent with = out intent.=20 Credentials: We discussed some very rough ideas. Some observations: * Credentials might be shared by more than one user, device etc. E.g a = user might use a device and the same credential might be used to = authenticate a device or the user on the device. Erik mentioned a case = where users might share a credential * We could leverage the OAuth AMR draft from Mike in order to categorize = credential types * Handling as a simple multi-valued attribute might not be enough. Each = credential may have common meta data (creation date, expiry etc) but may = also have credential specific schema. * We discussed making a credential instance its own resource type in = SCIM (e.g. /Credentials). That would mean that each credential has its = own resource identifier where the core schema for the resource type = would have all the common management attributes (e.g. creation, expiry) = etc and may have links to the owner/user of the credential. Schema = extensions for each credential type could be used to add authenticator = specific attributes to the resources. Downside: By separating credentials from the User resources, it may = impact how implementers get scale since credentials may have to be = queried in a separate lookup. On a plus side, keeping credentials away = from the User object may make access control easier to define =97 since = non-priv access should not need access to credential resources. We agreed to try to meet informally at IETF94. Hopefully one of the = chairs can wangle a room. We will work towards amending existing drafts = and in the case of credentials, put enough information together to get = an initial draft together. I believe many of us are also going to IIW the week before. So we can = definitely meet up there too. Apologies if I left anything out or mis-construded/attributed comments. = I didn=92t take notes this is just my recollection. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Oct 5, 2015, at 3:12 PM, Anthony Nadalin = wrote: >=20 > yes >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Sunday, October 4, 2015 11:28 AM > To: scim@ietf.org > Subject: Re: [scim] Call this week >=20 > On 2015-09-30 09:07, Erik Wahlstr=F6m neXus wrote: >> Thursday works for me, not Friday. >> / Erik >>=20 >=20 > did you guys have a call? >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2fscim&data=3D01%7c01%7ctonynad%40microsoft.com= %7cf0af1fbb33ed42d9809908d2cce97b53%7c72f988bf86f141af91ab2d7cd011db47%7c1= &sdata=3DWBftVaoFTJKJOxLlu71ca7%2bf2BJKj80mIP%2bjVitKemk%3d >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Oct 8 07:36:12 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CC81A1A29 for ; Thu, 8 Oct 2015 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 VD_sR3j9aJFE for ; Thu, 8 Oct 2015 07:36:05 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 88F901A1A28 for ; Thu, 8 Oct 2015 07:36:05 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so28415840wic.1 for ; Thu, 08 Oct 2015 07:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:date:message-id:subject:from:to:content-type; bh=hF3bCCjCOQ5kILUNnJo538Ui0oJCYnJ4iZVDoPNevyU=; b=f82RHH/vdWxP7oyeRS7CQACB6fgdq7wFIsf4D81/3NFaEGq3W2dkv2afb5yIg8bdNU EXm/K0/XzBGI8nwyz5QxVXc41mR8Jz9mRa0VfbJiMxz0D/we1k/uwASBKrq3bd9Bx2Ix 3dqbZVYnzqJbya+OUDcwp3RtbzFj41v+QMfho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hF3bCCjCOQ5kILUNnJo538Ui0oJCYnJ4iZVDoPNevyU=; b=HVRZ7SEgM2WVSd+Q5R2QYH7dQeBMF0TdAeokYiLbPqnPPWz+4EAC4/E0ZtZeNUHjq7 j12gg3Gylk84eCTzrim/gDjlW/7N3YgNbMy80sc/stBzdSAWi3HxOptfhg4laSxPOAhH XK8+oysveKwNotuVpVR7LiPe8lOEgbbDKipwfwvBmb5X+SXMnQgO0B78BRBAc2bm41Kl 4JthQlTgXzcti3ijUbKZFyoC+oNCQ9GjFam1NwDcxh66f/GFOKaf+1U1TAXUjKTOmyZm SEZ+BoRrpwng7gqfh6fPpXxLKFmsWFzVEgVI0CKog2ZqbU9n+1HoZKFWnqAD6q38Dm2a 3BnA== X-Gm-Message-State: ALoCoQlDMXDQp5VhE4PCTPXB7DqOj4tTSYG1TRUB67lt9AH+ujngX8QeT8hvdiwjxFUlcOpLPsmD MIME-Version: 1.0 X-Received: by 10.180.223.102 with SMTP id qt6mr4360132wic.11.1444314963996; Thu, 08 Oct 2015 07:36:03 -0700 (PDT) Received: by 10.27.205.134 with HTTP; Thu, 8 Oct 2015 07:36:03 -0700 (PDT) Date: Thu, 8 Oct 2015 08:36:03 -0600 Message-ID: From: Eric Fazendin To: scim@ietf.org Content-Type: multipart/alternative; boundary=001a1135f0b25fa0b3052198c8ac Archived-At: Subject: [scim] Referencing individual subattributes in multivalued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 14:36:07 -0000 --001a1135f0b25fa0b3052198c8ac Content-Type: text/plain; charset=UTF-8 I'm wondering what is the best practice for extracting individual subattribute values in a multivalued attribute. Say you had the below SCIM object and you wanted a system to extract the region value of the home address. Barring any specific business requirements, would the right thing be to return a multivalued list of [CA, KA, KA]? Related, how problematic would it be to enforce one time use of type for any given multivalued attribute? With the below data, the types would need to be changed to something like home, secondary home, tertiary home. { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id": "2819c223-7f76-453a-919d-413861904646", "userName": "bjensen@example.com", "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" }, { "type": "home", "streetAddress": "123 Oak St", "locality": "Topeka", "region": "KA", "postalCode": "55555", "country": "USA", "formatted": "123 Oak St\nTopeka, KA 55555 USA" }, { "type": "home", "streetAddress": "987 Spruce St", "locality": "Witchita", "region": "KA", "postalCode": "55556", "country": "USA", "formatted": "987 Spruce St\nWitchita, KA 55556 USA" } ], "meta": { "resourceType": "User", "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"a330bc54f0671c9\"", "location": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" } } --001a1135f0b25fa0b3052198c8ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm wondering what is the best practice for extracting= individual subattribute values in a multivalued attribute.

<= div>Say you had the below SCIM object and you wanted a system to extract th= e region value of the home address.=C2=A0 Barring any specific business req= uirements, would the right thing be to return a multivalued list of [CA, KA= , KA]?

Related, how problematic would it be to enf= orce one time use of type for any given multivalued attribute?=C2=A0 With t= he below data, the types would need to be changed to something like home, s= econdary home, tertiary home.


=
{
=C2=A0 "schemas": ["= ;urn:ietf:params:scim:schemas:core:2.0:User"],
= =C2=A0 "id": "2819c223-7f76-453a-919d-413861904646",
=C2=A0 "userName": "bjensen@example.com",
=C2= =A0 "addresses": [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "type": "work",
=C2=A0 =C2=A0 =C2=A0 "streetAddress": "100= Universal City Plaza",
=C2=A0 =C2=A0 =C2=A0 &qu= ot;locality": "Hollywood",
=C2=A0 =C2= =A0 =C2=A0 "region": "CA",
=C2=A0= =C2=A0 =C2=A0 "postalCode": "91608",
=C2=A0 =C2=A0 =C2=A0 "country": "USA",
=C2=A0 =C2=A0 =C2=A0 "formatted": "100 Universal = City Plaza\nHollywood, CA 91608 USA",
=C2=A0 =C2= =A0 =C2=A0 "primary": true
=C2=A0 =C2=A0 },=
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 = =C2=A0 "type": "home",
=C2=A0 =C2= =A0 =C2=A0 "streetAddress": "456 Hollywood Blvd",
=
=C2=A0 =C2=A0 =C2=A0 "locality": "Hollywood= ",
=C2=A0 =C2=A0 =C2=A0 "region": &quo= t;CA",
=C2=A0 =C2=A0 =C2=A0 "postalCode&quo= t;: "91608",
=C2=A0 =C2=A0 =C2=A0 "cou= ntry": "USA",
=C2=A0 =C2=A0 =C2=A0 &qu= ot;formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA"=
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0= {
=C2=A0 =C2=A0 =C2=A0 "type": "home&= quot;,
=C2=A0 =C2=A0 =C2=A0 "streetAddress"= : "123 Oak St",
=C2=A0 =C2=A0 =C2=A0 "= locality": "Topeka",
=C2=A0 =C2=A0 =C2= =A0 "region": "KA",
=C2=A0 =C2=A0= =C2=A0 "postalCode": "55555",
= =C2=A0 =C2=A0 =C2=A0 "country": "USA",
=C2=A0 =C2=A0 =C2=A0 "formatted": "123 Oak St\nTopeka,= KA 55555 USA"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "type= ": "home",
=C2=A0 =C2=A0 =C2=A0 "= streetAddress": "987 Spruce St",
=C2= =A0 =C2=A0 =C2=A0 "locality": "Witchita",
=C2=A0 =C2=A0 =C2=A0 "region": "KA",
=C2=A0 =C2=A0 =C2=A0 "postalCode": "55556"= ,
=C2=A0 =C2=A0 =C2=A0 "country": "USA= ",
=C2=A0 =C2=A0 =C2=A0 "formatted": &= quot;987 Spruce St\nWitchita, KA 55556 USA"
=C2= =A0 =C2=A0 }
=C2=A0 ],
=C2=A0 &= quot;meta": {
=C2=A0 =C2=A0 "resourceType&q= uot;: "User",
=C2=A0 =C2=A0 "created&q= uot;: "2010-01-23T04:56:22Z",
=C2=A0 =C2=A0= "lastModified": "2011-05-13T04:42:34Z",
=C2=A0 =C2=A0 "version": "W\/\"a330bc54f0671c9= \"",
--001a1135f0b25fa0b3052198c8ac-- From nobody Thu Oct 8 09:04:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD05F1A90D9 for ; Thu, 8 Oct 2015 09:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wkCjbycbpfXa for ; Thu, 8 Oct 2015 09:04:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3A5CD1A90F6 for ; Thu, 8 Oct 2015 09:04:28 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t98G4Qgi013510 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Oct 2015 16:04:27 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t98G4Qfd027741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2015 16:04:26 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t98G4QJ8027230; Thu, 8 Oct 2015 16:04:26 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Oct 2015 09:04:25 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-C14C40C0-6013-4651-85B9-1F9FFB19EC54 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13A452) In-Reply-To: Date: Thu, 8 Oct 2015 09:04:24 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3CA99430-C3DD-4F97-9C4F-32AB810C2A52@oracle.com> References: To: Eric Fazendin X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Referencing individual subattributes in multivalued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:04:49 -0000 --Apple-Mail-C14C40C0-6013-4651-85B9-1F9FFB19EC54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Eric, It depends on your service providers needs.=20 If you allow repeat types then the client would have to use a filter like th= e following to return or patch a specific value since type is not unique: filter=3Daddresses[type eq "work" and region eq "KA"] The server is free to decide on if it wants to enforce uniqueness. It should= set uniqueness for type sub- attribute in schema if it does.=20 Phil > On Oct 8, 2015, at 07:36, Eric Fazendin wrote= : >=20 > I'm wondering what is the best practice for extracting individual subattri= bute values in a multivalued attribute. >=20 > Say you had the below SCIM object and you wanted a system to extract the r= egion value of the home address. Barring any specific business requirements= , would the right thing be to return a multivalued list of [CA, KA, KA]? >=20 > Related, how problematic would it be to enforce one time use of type for a= ny given multivalued attribute? With the below data, the types would need t= o be changed to something like home, secondary home, tertiary home. >=20 >=20 > { > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], > "id": "2819c223-7f76-453a-919d-413861904646", > "userName": "bjensen@example.com", > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > }, > { > "type": "home", > "streetAddress": "123 Oak St", > "locality": "Topeka", > "region": "KA", > "postalCode": "55555", > "country": "USA", > "formatted": "123 Oak St\nTopeka, KA 55555 USA" > }, > { > "type": "home", > "streetAddress": "987 Spruce St", > "locality": "Witchita", > "region": "KA", > "postalCode": "55556", > "country": "USA", > "formatted": "987 Spruce St\nWitchita, KA 55556 USA" > } > ], > "meta": { > "resourceType": "User", > "created": "2010-01-23T04:56:22Z", > "lastModified": "2011-05-13T04:42:34Z", > "version": "W\/\"a330bc54f0671c9\"", > "location": > "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" > } > } > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-C14C40C0-6013-4651-85B9-1F9FFB19EC54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eric,

It depends on your service prov= iders needs. 

If you allow repeat types then the client would have to u= se a filter like the following to return or patch a specific value since typ= e is not unique:

filter=3Daddresses[type eq "work" and region eq "KA"]

The= server is free to decide on if it wants to enforce uniqueness. It should se= t uniqueness for type sub- attribute in schema if it does. 

Phil=

On Oct 8, 2015, at 07:36, Eric Fazendin <efazendin@pingidentity.com> wrote:
I'm wondering what i= s the best practice for extracting individual subattribute values in a multi= valued attribute.

Say you had the below SCIM object and y= ou wanted a system to extract the region value of the home address.  Ba= rring any specific business requirements, would the right thing be to return= a multivalued list of [CA, KA, KA]?

Related, how p= roblematic would it be to enforce one time use of type for any given multiva= lued attribute?  With the below data, the types would need to be change= d to something like home, secondary home, tertiary home.

<= div>
{
  "sc= hemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "userName": "bjensen@example.= com",
  "addresses": [
=     {
      "type": "work",
      "streetAddress": "100 Universal Ci= ty Plaza",
      "locality": "Hollywood= ",
      "region": "CA",
      "postalCode": "91608",
&nbs= p;     "country": "USA",
     = ; "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
      "primary": true
&nb= sp;   },
    {
&n= bsp;     "type": "home",
     = ; "streetAddress": "456 Hollywood Blvd",
   =   "locality": "Hollywood",
      "= region": "CA",
      "postalCode": "916= 08",
      "country": "USA",
      "formatted": "456 Hollywood Blvd\nHollywood,= CA 91608 USA"
    },
=     {
      "type": "home",
      "streetAddress": "123 Oak St",
      "locality": "Topeka",
      "region": "KA",
  &nbs= p;   "postalCode": "55555",
      "= country": "USA",
      "formatted": "12= 3 Oak St\nTopeka, KA 55555 USA"
    },
=
    {
      "= type": "home",
      "streetAddress": "= 987 Spruce St",
      "locality": "Witc= hita",
      "region": "KA",
      "postalCode": "55556",
      "country": "USA",
    &= nbsp; "formatted": "987 Spruce St\nWitchita, KA 55556 USA"
    }
  ],
&= nbsp; "meta": {
    "resourceType": "User",<= /div>
    "created": "2010-01-23T04:56:22Z",
=
    "lastModified": "2011-05-13T04:42:34Z",
=
    "version": "W\/\"a330bc54f0671c9\"",
    "location":
  }
}
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-C14C40C0-6013-4651-85B9-1F9FFB19EC54-- From nobody Tue Oct 13 13:00:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46481A8A0E for ; Tue, 13 Oct 2015 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TFTxiYsHGlIq for ; Tue, 13 Oct 2015 13:00:31 -0700 (PDT) Received: from exch-chub03.exchange.upenn.edu (exch-chub03.exchange.upenn.edu [128.91.3.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726EA1A8A0D for ; Tue, 13 Oct 2015 13:00:31 -0700 (PDT) Received: from exch-mbx01.exchange.upenn.edu ([fe80::10fd:fb9c:1d0c:81a6]) by exch-chub03.exchange.upenn.edu ([fe80::65a2:dd84:9750:16a6%11]) with mapi id 14.03.0235.001; Tue, 13 Oct 2015 16:00:28 -0400 From: Chris Hyzer To: "scim@ietf.org" Thread-Topic: scim over messaging Thread-Index: AdEF8c3fBlbEgTnzTZCHJHgvVQL+yg== Date: Tue, 13 Oct 2015 20:00:27 +0000 Message-ID: <04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4@exch-mbx01.exchange.upenn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.91.219.176] Content-Type: multipart/alternative; boundary="_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4exchmbx01exchan_" MIME-Version: 1.0 Archived-At: Subject: [scim] scim over messaging X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:00:33 -0000 --_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4exchmbx01exchan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has there been discussion about SCIM over messaging? Ie. If sending SCIM through a messaging system (e.g. AWS SQS, activeMQ, etc= ) where it is not HTTP. Basically this means there is no response, and th= e request would need whatever would normally be in HTTP be in the message o= bject. E.g. { "method": "PATCH", "resource": "/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce" "body": { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "pennperson:12345678", "operation": "delete" } ] } } Is something like this something that could be added to a future roadmap if= not there already? Thanks, Chris Ps. tried to send this earlier, sorry if this is a dupe --_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4exchmbx01exchan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has there been discussio= n about SCIM over messaging?

 =

Ie. If sending SCIM thro= ugh a messaging system (e.g. AWS SQS, activeMQ, etc)  where it is not = HTTP.  Basically this means there is no response, and the request woul= d need whatever would normally be in HTTP be in the message object.  E.g.

 =

{

  "method&q= uot;: "PATCH",

  "resource= ": "/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce"=

  "body&quo= t;: {

    &q= uot;schemas": ["urn:scim:schemas:core:1.0"],

    &q= uot;members": [

   &nb= sp;  {

   &nb= sp;    "display": "Babs Jensen",

   &nb= sp;    "value": "pennperson:12345678",

   &nb= sp;    "operation": "delete"<= /span>

   &nb= sp;  }

    ]<= o:p>

  }

}

 =

Is something like this s= omething that could be added to a future roadmap if not there already?=

 =

Thanks,

Chris<= /p>

 

Ps. tried to send this earlier, sorry if this is a d= upe

--_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4exchmbx01exchan_-- From nobody Tue Oct 13 13:16:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3571A8A80 for ; Tue, 13 Oct 2015 13:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TAQVaMbbOHoF for ; Tue, 13 Oct 2015 13:15:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4C60E1A8A84 for ; Tue, 13 Oct 2015 13:15:49 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9DKFlfq031541 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Oct 2015 20:15:48 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t9DKFkiq020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2015 20:15:47 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t9DKFjn5025774; Tue, 13 Oct 2015 20:15:46 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2015 13:15:45 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E9BF6D31-96FD-473F-AF84-1D42BE95C3AF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: <04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4@exch-mbx01.exchange.upenn.edu> Date: Tue, 13 Oct 2015 13:15:47 -0700 Message-Id: <8121CE8E-9574-4D3E-B757-BC3CA0676D33@oracle.com> References: <04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4@exch-mbx01.exchange.upenn.edu> To: Chris Hyzer X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] scim over messaging X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:15:54 -0000 --Apple-Mail=_E9BF6D31-96FD-473F-AF84-1D42BE95C3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chris, Good question. Yes. There has been some discussion. However it might not be quite the = same use case. Take a look at this: https://tools.ietf.org/html/draft-hunt-scim-notify-00 (the draft has = expired) Some of us are still interested. The current proposal is an = asynchronous notification method to let one domain provider notify one = or more subscribers of a changes they may be interested in. It could be = tenancy to tenancy (domain wide), or it may be changes about a single = resource to a subscribing mobile application.=20 When there are multiple domains, there are many cases where a change = (e.g. a specific PATCH) might not work well in another domain - because = each domain likely has a different set of information and thus slightly = different information =E2=80=9Cstate=E2=80=9D. Instead of pushing = commands (as in the normal SCIM approach), the notify approach lets the = receiver decide the correct action. Eg. Domain A provider notifies a = mobile app of a change (Resource /Users/{id} had its name attribute = change). The subscriber calls back to the publishing domain provider = and does a GET and decides what to do. When the subscriber calls back, = the subscribers right to see all of the information is then reviewed. =20= A couple of benefits: * Makes differences in state between systems less problematic * Allows normal SCIM access control to decide who should see what - this = makes the definition of feeds and subscribers much simpler * Dramatically reduces the information content (and privacy risk) in = messages The draft uses JWTs/JOSE to send notifications securely and makes it = easy then to deliver via an alternate protocol. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Oct 13, 2015, at 1:00 PM, Chris Hyzer = wrote: >=20 > Has there been discussion about SCIM over messaging? > =20 > Ie. If sending SCIM through a messaging system (e.g. AWS SQS, = activeMQ, etc) where it is not HTTP. Basically this means there is no = response, and the request would need whatever would normally be in HTTP = be in the message object. E.g. > =20 > { > "method": "PATCH", > "resource": "/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce" > "body": { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "pennperson:12345678", > "operation": "delete" > } > ] > } > } > =20 > Is something like this something that could be added to a future = roadmap if not there already? > =20 > Thanks, > Chris > =20 > Ps. tried to send this earlier, sorry if this is a dupe > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_E9BF6D31-96FD-473F-AF84-1D42BE95C3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Chris,

Good question.

Yes. There has been some discussion. However it might = not be quite the same use case.

Take a look at this:
https://tools.ietf.org/html/draft-hunt-scim-notify-00 = (the draft has expired)

Some of us are still interested.  The current proposal = is an asynchronous notification method to let one domain provider notify = one or more subscribers of a changes they may be interested in. It could = be tenancy to tenancy (domain wide), or it may be changes about a single = resource to a subscribing mobile application. 

When there are multiple = domains, there are many cases where a change (e.g. a specific PATCH) = might not work well in another domain - because each domain likely has a = different set of information and thus slightly different information = =E2=80=9Cstate=E2=80=9D.  Instead of pushing commands (as in the = normal SCIM approach), the notify approach lets the receiver decide the = correct action.  Eg.  Domain A provider notifies a mobile app = of a change (Resource /Users/{id} had its name attribute change). =  The subscriber calls back to the publishing domain provider and = does a GET and decides what to do.  When the subscriber calls back, = the subscribers right to see all of the information is then reviewed. =  

A = couple of benefits:
* Makes differences in state = between systems less problematic
* Allows normal = SCIM access control to decide who should see what - this makes the = definition of feeds and subscribers much simpler
* = Dramatically reduces the information content (and privacy risk) in = messages

The = draft uses JWTs/JOSE to send notifications securely and makes it easy = then to deliver via an alternate protocol.


On Oct 13, 2015, at 1:00 PM, Chris Hyzer <mchyzer@isc.upenn.edu> wrote:

Has there been discussion about SCIM over messaging?

 

Ie. If sending SCIM = through a messaging system (e.g. AWS SQS, activeMQ, etc)  where it = is not HTTP.  Basically this means there is no response, and the = request would need whatever would normally be in HTTP be in the message object.  E.g.

 

{

  "method": = "PATCH",

  "resource": = "/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce"

  "body": {

    = "schemas": ["urn:scim:schemas:core:1.0"],

    "members": [

      {

        "display": "Babs = Jensen",

        = "value": "pennperson:12345678",

        "operation": = "delete"

      }

    ]

  }

}

 

Is something like this = something that could be added to a future roadmap if not there = already?

 

Thanks,

Chris

 

Ps. tried to send this earlier, sorry if this is a = dupe

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_E9BF6D31-96FD-473F-AF84-1D42BE95C3AF-- From nobody Wed Oct 14 06:46:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677F51A802D for ; Wed, 14 Oct 2015 06:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ao1ZGKQsIBXz for ; Wed, 14 Oct 2015 06:45:57 -0700 (PDT) Received: from exch-chub01.exchange.upenn.edu (exch-chub01.exchange.upenn.edu [128.91.3.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86AC1A702A for ; Wed, 14 Oct 2015 06:45:56 -0700 (PDT) Received: from exch-mbx01.exchange.upenn.edu ([fe80::10fd:fb9c:1d0c:81a6]) by exch-chub01.exchange.upenn.edu ([fe80::821:cd33:1a58:3fdd%11]) with mapi id 14.03.0235.001; Wed, 14 Oct 2015 09:45:52 -0400 From: Chris Hyzer To: Phil Hunt Thread-Topic: [scim] scim over messaging Thread-Index: AdEF8c3fBlbEgTnzTZCHJHgvVQL+ygAI6tyAABw3/OA= Date: Wed, 14 Oct 2015 13:45:52 +0000 Message-ID: <04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37@exch-mbx01.exchange.upenn.edu> References: <04BE669BEE19E54BBDC2A9A2585BB688A7A3B3D4@exch-mbx01.exchange.upenn.edu> <8121CE8E-9574-4D3E-B757-BC3CA0676D33@oracle.com> In-Reply-To: <8121CE8E-9574-4D3E-B757-BC3CA0676D33@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.91.219.176] Content-Type: multipart/alternative; boundary="_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37exchmbx01exchan_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] scim over messaging X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 13:46:01 -0000 --_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37exchmbx01exchan_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbG9va2luZyBmb3IgZXZlbnRzIHRoYXQgYXJlIHRoZSBzYW1lIGFzIGN1cnJlbnQgU0NJ TSB0byBnbyBvdmVyIG1lc3NhZ2luZywgdGhlIHNlY3VyaXR5IHdvdWxkIGJlIGtub3duIGFuZCBh IGNhbGxiYWNrIHdvdWxkbuKAmXQgYmUgbmVlZGVkLiAgQnV0IHRoZSB3YXkgeW91IHNwZWNpZnkg d291bGQgd29yayB0b28sIEkgaG9wZSBzb21ldGhpbmcgbGlrZSB0aGlzIGNhbiBiZSBhZG9wdGVk IHNvb24uICBUaGFua3MsIENocmlzDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAxNSA0OjE2IFBNDQpU bzogQ2hyaXMgSHl6ZXINCkNjOiBzY2ltQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NjaW1dIHNj aW0gb3ZlciBtZXNzYWdpbmcNCg0KQ2hyaXMsDQoNCkdvb2QgcXVlc3Rpb24uDQoNClllcy4gVGhl cmUgaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uLiBIb3dldmVyIGl0IG1pZ2h0IG5vdCBiZSBxdWl0 ZSB0aGUgc2FtZSB1c2UgY2FzZS4NCg0KVGFrZSBhIGxvb2sgYXQgdGhpczoNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tbm90aWZ5LTAwICh0aGUgZHJhZnQgaGFz IGV4cGlyZWQpDQoNClNvbWUgb2YgdXMgYXJlIHN0aWxsIGludGVyZXN0ZWQuICBUaGUgY3VycmVu dCBwcm9wb3NhbCBpcyBhbiBhc3luY2hyb25vdXMgbm90aWZpY2F0aW9uIG1ldGhvZCB0byBsZXQg b25lIGRvbWFpbiBwcm92aWRlciBub3RpZnkgb25lIG9yIG1vcmUgc3Vic2NyaWJlcnMgb2YgYSBj aGFuZ2VzIHRoZXkgbWF5IGJlIGludGVyZXN0ZWQgaW4uIEl0IGNvdWxkIGJlIHRlbmFuY3kgdG8g dGVuYW5jeSAoZG9tYWluIHdpZGUpLCBvciBpdCBtYXkgYmUgY2hhbmdlcyBhYm91dCBhIHNpbmds ZSByZXNvdXJjZSB0byBhIHN1YnNjcmliaW5nIG1vYmlsZSBhcHBsaWNhdGlvbi4NCg0KV2hlbiB0 aGVyZSBhcmUgbXVsdGlwbGUgZG9tYWlucywgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgYSBj aGFuZ2UgKGUuZy4gYSBzcGVjaWZpYyBQQVRDSCkgbWlnaHQgbm90IHdvcmsgd2VsbCBpbiBhbm90 aGVyIGRvbWFpbiAtIGJlY2F1c2UgZWFjaCBkb21haW4gbGlrZWx5IGhhcyBhIGRpZmZlcmVudCBz ZXQgb2YgaW5mb3JtYXRpb24gYW5kIHRodXMgc2xpZ2h0bHkgZGlmZmVyZW50IGluZm9ybWF0aW9u IOKAnHN0YXRl4oCdLiAgSW5zdGVhZCBvZiBwdXNoaW5nIGNvbW1hbmRzIChhcyBpbiB0aGUgbm9y bWFsIFNDSU0gYXBwcm9hY2gpLCB0aGUgbm90aWZ5IGFwcHJvYWNoIGxldHMgdGhlIHJlY2VpdmVy IGRlY2lkZSB0aGUgY29ycmVjdCBhY3Rpb24uICBFZy4gIERvbWFpbiBBIHByb3ZpZGVyIG5vdGlm aWVzIGEgbW9iaWxlIGFwcCBvZiBhIGNoYW5nZSAoUmVzb3VyY2UgL1VzZXJzL3tpZH0gaGFkIGl0 cyBuYW1lIGF0dHJpYnV0ZSBjaGFuZ2UpLiAgVGhlIHN1YnNjcmliZXIgY2FsbHMgYmFjayB0byB0 aGUgcHVibGlzaGluZyBkb21haW4gcHJvdmlkZXIgYW5kIGRvZXMgYSBHRVQgYW5kIGRlY2lkZXMg d2hhdCB0byBkby4gIFdoZW4gdGhlIHN1YnNjcmliZXIgY2FsbHMgYmFjaywgdGhlIHN1YnNjcmli ZXJzIHJpZ2h0IHRvIHNlZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIGlzIHRoZW4gcmV2aWV3ZWQu DQoNCkEgY291cGxlIG9mIGJlbmVmaXRzOg0KKiBNYWtlcyBkaWZmZXJlbmNlcyBpbiBzdGF0ZSBi ZXR3ZWVuIHN5c3RlbXMgbGVzcyBwcm9ibGVtYXRpYw0KKiBBbGxvd3Mgbm9ybWFsIFNDSU0gYWNj ZXNzIGNvbnRyb2wgdG8gZGVjaWRlIHdobyBzaG91bGQgc2VlIHdoYXQgLSB0aGlzIG1ha2VzIHRo ZSBkZWZpbml0aW9uIG9mIGZlZWRzIGFuZCBzdWJzY3JpYmVycyBtdWNoIHNpbXBsZXINCiogRHJh bWF0aWNhbGx5IHJlZHVjZXMgdGhlIGluZm9ybWF0aW9uIGNvbnRlbnQgKGFuZCBwcml2YWN5IHJp c2spIGluIG1lc3NhZ2VzDQoNClRoZSBkcmFmdCB1c2VzIEpXVHMvSk9TRSB0byBzZW5kIG5vdGlm aWNhdGlvbnMgc2VjdXJlbHkgYW5kIG1ha2VzIGl0IGVhc3kgdGhlbiB0byBkZWxpdmVyIHZpYSBh biBhbHRlcm5hdGUgcHJvdG9jb2wuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBPY3QgMTMsIDIwMTUs IGF0IDE6MDAgUE0sIENocmlzIEh5emVyIDxtY2h5emVyQGlzYy51cGVubi5lZHU8bWFpbHRvOm1j aHl6ZXJAaXNjLnVwZW5uLmVkdT4+IHdyb3RlOg0KDQpIYXMgdGhlcmUgYmVlbiBkaXNjdXNzaW9u IGFib3V0IFNDSU0gb3ZlciBtZXNzYWdpbmc/DQoNCkllLiBJZiBzZW5kaW5nIFNDSU0gdGhyb3Vn aCBhIG1lc3NhZ2luZyBzeXN0ZW0gKGUuZy4gQVdTIFNRUywgYWN0aXZlTVEsIGV0YykgIHdoZXJl IGl0IGlzIG5vdCBIVFRQLiAgQmFzaWNhbGx5IHRoaXMgbWVhbnMgdGhlcmUgaXMgbm8gcmVzcG9u c2UsIGFuZCB0aGUgcmVxdWVzdCB3b3VsZCBuZWVkIHdoYXRldmVyIHdvdWxkIG5vcm1hbGx5IGJl IGluIEhUVFAgYmUgaW4gdGhlIG1lc3NhZ2Ugb2JqZWN0LiAgRS5nLg0KDQoNCnsNCg0KICAibWV0 aG9kIjogIlBBVENIIiwNCg0KICAicmVzb3VyY2UiOiAiL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2 OTItYjRmZC05YjRkYTNmOTA4Y2UiDQoNCiAgImJvZHkiOiB7DQoNCiAgICAic2NoZW1hcyI6IFsi dXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLA0KDQogICAgIm1lbWJlcnMiOiBbDQoNCiAgICAg IHsNCg0KICAgICAgICAiZGlzcGxheSI6ICJCYWJzIEplbnNlbiIsDQoNCiAgICAgICAgInZhbHVl IjogInBlbm5wZXJzb246MTIzNDU2NzgiLA0KDQogICAgICAgICJvcGVyYXRpb24iOiAiZGVsZXRl Ig0KDQogICAgICB9DQoNCiAgICBdDQoNCiAgfQ0KDQp9DQoNCklzIHNvbWV0aGluZyBsaWtlIHRo aXMgc29tZXRoaW5nIHRoYXQgY291bGQgYmUgYWRkZWQgdG8gYSBmdXR1cmUgcm9hZG1hcCBpZiBu b3QgdGhlcmUgYWxyZWFkeT8NCg0KVGhhbmtzLA0KQ2hyaXMNCg0KUHMuIHRyaWVkIHRvIHNlbmQg dGhpcyBlYXJsaWVyLCBzb3JyeSBpZiB0aGlzIGlzIGEgZHVwZQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGll dGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zY2ltDQoNCg== --_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37exchmbx01exchan_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2 Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLlBs YWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gbG9va2luZyBm b3IgZXZlbnRzIHRoYXQgYXJlIHRoZSBzYW1lIGFzIGN1cnJlbnQgU0NJTSB0byBnbyBvdmVyIG1l c3NhZ2luZywgdGhlIHNlY3VyaXR5IHdvdWxkIGJlIGtub3duIGFuZCBhIGNhbGxiYWNrIHdvdWxk buKAmXQgYmUgbmVlZGVkLiZuYnNwOyBCdXQgdGhlIHdheSB5b3Ugc3BlY2lmeSB3b3VsZCB3b3Jr IHRvbywgSSBob3BlIHNvbWV0aGluZyBsaWtlIHRoaXMNCiBjYW4gYmUgYWRvcHRlZCBzb29uLiZu YnNwOyBUaGFua3MsIENocmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxMywgMjAxNSA0OjE2 IFBNPGJyPg0KPGI+VG86PC9iPiBDaHJpcyBIeXplcjxicj4NCjxiPkNjOjwvYj4gc2NpbUBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIHNjaW0gb3ZlciBtZXNzYWdpbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hy aXMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkdvb2QgcXVlc3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WWVzLiBUaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24uIEhvd2V2ZXIgaXQgbWln aHQgbm90IGJlIHF1aXRlIHRoZSBzYW1lIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZSBhIGxvb2sgYXQgdGhpczo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tbm90aWZ5LTAwIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1zY2ltLW5vdGlmeS0wMDwvYT4gKHRoZSBkcmFm dCBoYXMgZXhwaXJlZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U29tZSBvZiB1cyBhcmUgc3RpbGwgaW50ZXJlc3RlZC4gJm5ic3A7VGhlIGN1 cnJlbnQgcHJvcG9zYWwgaXMgYW4gYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbiBtZXRob2QgdG8g bGV0IG9uZSBkb21haW4gcHJvdmlkZXIgbm90aWZ5IG9uZSBvciBtb3JlIHN1YnNjcmliZXJzIG9m IGEgY2hhbmdlcyB0aGV5IG1heSBiZSBpbnRlcmVzdGVkIGluLiBJdCBjb3VsZCBiZSB0ZW5hbmN5 IHRvIHRlbmFuY3kgKGRvbWFpbiB3aWRlKSwNCiBvciBpdCBtYXkgYmUgY2hhbmdlcyBhYm91dCBh IHNpbmdsZSByZXNvdXJjZSB0byBhIHN1YnNjcmliaW5nIG1vYmlsZSBhcHBsaWNhdGlvbi4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgZG9tYWlucywgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hl cmUgYSBjaGFuZ2UgKGUuZy4gYSBzcGVjaWZpYyBQQVRDSCkgbWlnaHQgbm90IHdvcmsgd2VsbCBp biBhbm90aGVyIGRvbWFpbiAtIGJlY2F1c2UgZWFjaCBkb21haW4gbGlrZWx5IGhhcyBhIGRpZmZl cmVudCBzZXQgb2YgaW5mb3JtYXRpb24gYW5kIHRodXMgc2xpZ2h0bHkgZGlmZmVyZW50IGluZm9y bWF0aW9uIOKAnHN0YXRl4oCdLg0KICZuYnNwO0luc3RlYWQgb2YgcHVzaGluZyBjb21tYW5kcyAo YXMgaW4gdGhlIG5vcm1hbCBTQ0lNIGFwcHJvYWNoKSwgdGhlIG5vdGlmeSBhcHByb2FjaCBsZXRz IHRoZSByZWNlaXZlciBkZWNpZGUgdGhlIGNvcnJlY3QgYWN0aW9uLiAmbmJzcDtFZy4gJm5ic3A7 RG9tYWluIEEgcHJvdmlkZXIgbm90aWZpZXMgYSBtb2JpbGUgYXBwIG9mIGEgY2hhbmdlIChSZXNv dXJjZSAvVXNlcnMve2lkfSBoYWQgaXRzIG5hbWUgYXR0cmlidXRlIGNoYW5nZSkuICZuYnNwO1Ro ZSBzdWJzY3JpYmVyDQogY2FsbHMgYmFjayB0byB0aGUgcHVibGlzaGluZyBkb21haW4gcHJvdmlk ZXIgYW5kIGRvZXMgYSBHRVQgYW5kIGRlY2lkZXMgd2hhdCB0byBkby4gJm5ic3A7V2hlbiB0aGUg c3Vic2NyaWJlciBjYWxscyBiYWNrLCB0aGUgc3Vic2NyaWJlcnMgcmlnaHQgdG8gc2VlIGFsbCBv ZiB0aGUgaW5mb3JtYXRpb24gaXMgdGhlbiByZXZpZXdlZC4gJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY291cGxlIG9mIGJlbmVm aXRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KiBNYWtlcyBkaWZmZXJlbmNlcyBpbiBzdGF0ZSBiZXR3ZWVuIHN5c3RlbXMgbGVzcyBwcm9ibGVt YXRpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KiBBbGxvd3Mgbm9ybWFsIFNDSU0gYWNjZXNzIGNvbnRyb2wgdG8gZGVjaWRlIHdobyBzaG91bGQg c2VlIHdoYXQgLSB0aGlzIG1ha2VzIHRoZSBkZWZpbml0aW9uIG9mIGZlZWRzIGFuZCBzdWJzY3Jp YmVycyBtdWNoIHNpbXBsZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiogRHJhbWF0aWNhbGx5IHJlZHVjZXMgdGhlIGluZm9ybWF0aW9uIGNvbnRl bnQgKGFuZCBwcml2YWN5IHJpc2spIGluIG1lc3NhZ2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCB1c2VzIEpXVHMvSk9TRSB0 byBzZW5kIG5vdGlmaWNhdGlvbnMgc2VjdXJlbHkgYW5kIG1ha2VzIGl0IGVhc3kgdGhlbiB0byBk ZWxpdmVyIHZpYSBhbiBhbHRlcm5hdGUgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVw ZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gT2N0IDEzLCAyMDE1LCBhdCAxOjAwIFBNLCBDaHJpcyBIeXplciAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1jaHl6ZXJAaXNjLnVwZW5uLmVkdSI+bWNoeXplckBpc2MudXBl bm4uZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IYXMgdGhlcmUgYmVlbiBkaXNjdXNzaW9uIGFib3V0IFNDSU0gb3ZlciBtZXNz YWdpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkllLiBJZiBzZW5kaW5nIFNDSU0gdGhyb3Vn aCBhIG1lc3NhZ2luZyBzeXN0ZW0gKGUuZy4gQVdTIFNRUywgYWN0aXZlTVEsIGV0YykmbmJzcDsg d2hlcmUgaXQgaXMgbm90IEhUVFAuJm5ic3A7IEJhc2ljYWxseSB0aGlzIG1lYW5zIHRoZXJlIGlz IG5vIHJlc3BvbnNlLCBhbmQgdGhlIHJlcXVlc3Qgd291bGQgbmVlZCB3aGF0ZXZlciB3b3VsZCBu b3JtYWxseSBiZSBpbiBIVFRQIGJlIGluIHRoZSBtZXNzYWdlIG9iamVjdC4mbmJzcDsgRS5nLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPns8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyAmcXVvdDttZXRob2QmcXVvdDs6ICZxdW90O1BBVENIJnF1b3Q7 LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZxdW90O3Jl c291cmNlJnF1b3Q7OiAmcXVvdDsvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1iNGZkLTliNGRh M2Y5MDhjZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7ICZxdW90O2JvZHkmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtzY2hlbWFzJnF1b3Q7OiBbJnF1b3Q7dXJu OnNjaW06c2NoZW1hczpjb3JlOjEuMCZxdW90O10sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bWVtYmVycyZxdW90OzogWzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtkaXNwbGF5JnF1 b3Q7OiAmcXVvdDtCYWJzIEplbnNlbiZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDt2YWx1ZSZxdW90OzogJnF1b3Q7cGVubnBlcnNvbjoxMjM0NTY3OCZxdW90Oyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtvcGVyYXRpb24mcXVvdDs6ICZxdW90O2RlbGV0ZSZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBzb21ldGhpbmcgbGlrZSB0aGlzIHNvbWV0aGlu ZyB0aGF0IGNvdWxkIGJlIGFkZGVkIHRvIGEgZnV0dXJlIHJvYWRtYXAgaWYgbm90IHRoZXJlIGFs cmVhZHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBzLiB0cmll ZCB0byBzZW5kIHRoaXMgZWFybGllciwgc29ycnkgaWYgdGhpcyBpcyBhIGR1cGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5v cmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NjaW08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_04BE669BEE19E54BBDC2A9A2585BB688A7A3BB37exchmbx01exchan_-- From nobody Mon Oct 26 15:32:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFD91A888A for ; Mon, 26 Oct 2015 15:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 BiBIL-ZaaOLl for ; Mon, 26 Oct 2015 15:31:58 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 071961A8835 for ; Mon, 26 Oct 2015 15:31:58 -0700 (PDT) Received: by igbni9 with SMTP id ni9so83652569igb.1 for ; Mon, 26 Oct 2015 15:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=U5cInbhcoYlx6d2ZC3hGULDZUv3A7+q8jROxDATbEP0=; b=L0ldtecC7/YW9ZT3S6sozc6g61K7E6bx4rRuD5tHe9qaTrF5eUXnatTLV8RD9O0hUg 4RjVzpshS1shgnxmkkmhEmtEGYE90KSQxAmd28YVOn8Ass4xzXme9g0G2iMUd+Xx12uZ S6TMN4McUWu/Bw40pj1GhfHZdLAhs8B88r3/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=U5cInbhcoYlx6d2ZC3hGULDZUv3A7+q8jROxDATbEP0=; b=hWz97+PyJ/wm+VDTlP+vlDWbyQLcAf2ehU5FbA+JM1vTgtsY6DEgQyF5NXM6It3obs SQ9lY5BDDoPQWriEnznlVJkr88tZw2/4E7bm7D4SJCG4j/nxYPXb7MJTd5qI3hzaOtxT 5c1I2s7lMxGQam63cJd+RyDJii1W98MLccRh4bzzgKa5+35gxKqGEnxQRmgnBPWzWDah i07JODznfALbebB5NA535dFVmpuBaiG1HIxisvAlmhmYMhg2y27SARq6jaPaw8ltbxDG 7enN24MFiyCe2g59tcarK/zcBUSDaJcGS7/6TSTWrGebE6fBPGntQ7foex+XGVoY05FU QRGQ== X-Gm-Message-State: ALoCoQkwRTBpo+SbMBPCYKd6EASd5p+Y30ecJseZdU1ms1SGnC5XCFu9fx1q8/NARtaWN3ztyz+p X-Received: by 10.50.79.232 with SMTP id m8mr21538005igx.79.1445898717315; Mon, 26 Oct 2015 15:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.43.18 with HTTP; Mon, 26 Oct 2015 15:31:37 -0700 (PDT) From: Ian Glazer Date: Mon, 26 Oct 2015 18:31:37 -0400 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=089e013a06066d7ad90523098766 Archived-At: Subject: [scim] $ref best practice X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 22:32:00 -0000 --089e013a06066d7ad90523098766 Content-Type: text/plain; charset=UTF-8 All - In looking at Core Schema's non-normative examples is see to patterns for $ref: 1) With complete URI such as " https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" 2) With local reference URI such as "../Users 2819c223-7f76-453a-919d-413861904646" I don't think we provide any guidance on when two use one pattern or the other. So what is the best practice? i -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --089e013a06066d7ad90523098766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All -

In looking at Core Schema's n= on-normative examples is see to patterns for $ref:

1) With complete URI such as "https://example.com/v2/Users/2819c223-7f76-453a-919d-41386= 1904646"

2) With local reference URI such as "= ;../Users2819c223-7f76-453a-919d-413861904646"

= I don't thi= nk we provide any guidance on when two use one pattern or the other. So wha= t is the best practice?

i
=

--
=
Ian Glazer
Senior Director, Identity
+1 202 25= 5 3166
--089e013a06066d7ad90523098766--