From nobody Wed Apr 18 06:08:52 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398771275F4 for ; Wed, 18 Apr 2018 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zstrbdg6wch for ; Wed, 18 Apr 2018 06:08:43 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B66831267BB for ; Wed, 18 Apr 2018 06:08:43 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 188-v6so1494466oih.8 for ; Wed, 18 Apr 2018 06:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=mQS8guQl620SM96/aMDxXKbWq8kJHDQVzhtwpCUeXFU=; b=baHseQDtaZ/S0DJ83xNZe6cdZd+xAS4dZqcsfrRv92S0urit9Y06UVj3Pr42sxbRrj lWatWDoJwcVDmg3ncJ41KxfVMQHiDVO0hvVRDeN8JoyguxXtlLq5wV00bTRq+ib2BQy7 3f1iAZpmJNt0YgCohyeTSLeADiU9yICpL0qI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mQS8guQl620SM96/aMDxXKbWq8kJHDQVzhtwpCUeXFU=; b=mHFF+6SLrEgmkGfDc/+5TP1Wh3v3w5UX8RYoH5Q5flB3lvGn+ts/9D3XYGIoiLEdoq QcBFUIi10sxc1d9zTW2cpTWYu5OO+4AU5gkPvkf4JpST6lTolUYBbb3JFLNslIXr0jBr 3nPEGC8RTeC5yTK8jG+Gk2lW4Gr7uv9ce4BSMmPxb52XpVeGOQrMxA8VgIe6UYQfhA6k 4gQwuz8zcugKtJnHvGbV8VnEYnPseUpopBeeXDyEBsgAJpAgVijo4S6xgf8nbgGbYWB8 biUFMvj6Q/+WFcy1PywXmDoiAfVSSf6ytyLuCHEK6pqkc/t9NdHT+/aYDJhcvG5ukpym I7Vw== X-Gm-Message-State: ALQs6tCKaX6H1BPlma9h+uCZMlBC6N2qgQtflsXH+PyPfYbkO1d2w04K qCCmmrkpxGBthCca9ji5fdq6dyMWesSUrjXm0ieNp7Y2 X-Google-Smtp-Source: AB8JxZqIwp6s9dG0lcR+1nFChKVQN1Pizxx8O2cS+y9y+GmMI1UOv0WvIBaDGSOA75R+940CUAKddw/q11NgpMd07yI= X-Received: by 2002:aca:3946:: with SMTP id g67-v6mr1033093oia.292.1524056922759; Wed, 18 Apr 2018 06:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.91 with HTTP; Wed, 18 Apr 2018 06:08:41 -0700 (PDT) From: Sathya Bandara Date: Wed, 18 Apr 2018 18:38:41 +0530 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="0000000000007fc9c5056a1f2720" Archived-At: Subject: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 13:08:50 -0000 --0000000000007fc9c5056a1f2720 Content-Type: text/plain; charset="UTF-8" Hi, As per the SCIM core schema specification [1], addresses claim definition is as follows. addresses > A physical mailing address for this user. Canonical type values > of "work", "home", and "other". This attribute is a complex type > with the following sub-attributes. All sub-attributes are > OPTIONAL. > > In a scenario where all the sub-attributes can be empty as per above definition, can we use primitive attribute types (string values) as the claim-values for this claim. E.g. - *addresses: ["address1", "address2"]* Would be grateful if you could clarify whether this is possible. [1] https://tools.ietf.org/html/rfc7643#section-4.1.2 Best regards, Sathya -- Sathya Bandara Software Engineer WSO2 Inc. http://wso2.com Mobile: (+94) 715 360 421 <+94%2071%20411%205032> <+94%2071%20411%205032> --0000000000007fc9c5056a1f2720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As per the SCIM core = schema specification [1], addresses claim definition is as follows.

= 
addresses
      A physical mailing address for this user.  Canonical type values
      of "work", "home", and "other".  This a=
ttribute is a complex type
      with the following sub-attributes.  All sub-attributes are
      OPTIONAL.
In a scenario where all the sub-attribute= s can be empty as per above definition, can we use primitive attribute type= s (string values) as the claim-values for this claim. E.g. -=C2=A0 addre= sses: ["address1", "address2"]

Would b= e grateful if you could clarify whether this is possible.

[1] https://tools.ietf.= org/html/rfc7643#section-4.1.2

Best regards,
Sath= ya

--
Sathya Bandara
Software Engineer
WSO= 2 Inc. http://wso2.com
Mobile: (+94) 715 360 421<= /a>

--0000000000007fc9c5056a1f2720-- From nobody Wed Apr 18 06:47:44 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C612D86E for ; Wed, 18 Apr 2018 06:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sailpoint.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9g8UMQJVal3 for ; Wed, 18 Apr 2018 06:47:40 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D42312D80E for ; Wed, 18 Apr 2018 06:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sailpoint.onmicrosoft.com; s=selector1-sailpoint-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8q/AFDa3FGOeKXYoMAyNe02otjy2pxe1Zt1GE1YK58c=; b=jU85nngwXrit8pcuNa1rpieehxAN7eTXbQQAP9k7r9ekH/EXOWdQL/wy4Mg4sWSbWBrjjX9lxgmih7hYu1gnjncuvwCItAtURKsPJL+ctycYJQaFstEA+3WSIa/GMH7e8Tc2TgYqftXSxauNVSxUolsnRZN4xTVgdswXaV9GtPM= Received: from BN7PR04MB3889.namprd04.prod.outlook.com (20.176.17.13) by BN7PR04MB3873.namprd04.prod.outlook.com (20.176.16.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Wed, 18 Apr 2018 13:47:38 +0000 Received: from BN7PR04MB3889.namprd04.prod.outlook.com ([fe80::c427:64d3:746c:ba32]) by BN7PR04MB3889.namprd04.prod.outlook.com ([fe80::c427:64d3:746c:ba32%13]) with mapi id 15.20.0675.015; Wed, 18 Apr 2018 13:47:38 +0000 From: Kelly Grizzle To: Sathya Bandara , "scim@ietf.org" Thread-Topic: [scim] Is it possible to use primitive types with SCIM addresses claim? Thread-Index: AQHT1xZrjuG7NaULDkqo/Kb9yw6AqaQGiOAA Date: Wed, 18 Apr 2018 13:47:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: wso2.com; dkim=none (message not signed) header.d=none;wso2.com; dmarc=none action=none header.from=sailpoint.com; x-originating-ip: [70.114.154.180] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR04MB3873; 7:BrnM6sDusgXEsOstzJrGGeHjSdAvR8I4i+aqHpCw5YmyNIy8zEG459/htza+YVNZXot4DiAdr6gOsTagRvpSE3gB0Gluye5p3m7GVe1+Ic4MXqml4kXGtmXNAO95F7fwSQRSlhEPzrR1AnbosGOfp1+imuQk6Z1X5JKZSle7s5dABlw9eFz8KropQZm22z/44f/KOsXT5AOIuAZmeYfUZs3C5Lxi3rfnmpZ1I7EGFla3HtnFsefW/UtBHPZnND6U x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN7PR04MB3873; x-ms-traffictypediagnostic: BN7PR04MB3873: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(139090996175007)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501368)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN7PR04MB3873; BCL:0; PCL:0; RULEID:; SRVR:BN7PR04MB3873; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39850400004)(39380400002)(346002)(14454004)(25786009)(6506007)(8936002)(7696005)(76176011)(5660300001)(8676002)(81166006)(7736002)(53936002)(53546011)(186003)(6246003)(66066001)(53386004)(33656002)(26005)(236005)(9686003)(110136005)(478600001)(86362001)(99286004)(966005)(6306002)(2906002)(54896002)(19609705001)(6116002)(102836004)(55016002)(6436002)(446003)(606006)(790700001)(2501003)(5250100002)(476003)(44832011)(733005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR04MB3873; H:BN7PR04MB3889.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: 1hLftkxvFD7riXT3yg0nKPsLPrFkYyCsiXnz5PJTZ6yZbtW8lSurtMxyNlcJLQvR1WyoztM3t4h/L9yAhILGjJxus1V03EJs4/TOaW0Wutoy4MXOtmBtDPzI3hh3qdXPVSJDKxNdcwFqy8Rbg3RCiVz9IGhsECoPQRU+Axqd/J3Gn2YG3mlFsxHQ9jMlmSR0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN7PR04MB38899330C8CE63EDF2EA5DF5E2B60BN7PR04MB3889namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c8a53df2-bd83-48f5-30c9-08d5a532f2f1 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8a53df2-bd83-48f5-30c9-08d5a532f2f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 13:47:38.4696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR04MB3873 Archived-At: Subject: Re: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 13:47:43 -0000 --_000_BN7PR04MB38899330C8CE63EDF2EA5DF5E2B60BN7PR04MB3889namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBsaWtlbHkgdG8gYnJlYWsgb3RoZXIgY2xpZW50cy9zZXJ2ZXJzIHRoYXQgZXhwZWN0 IGEgbXVsdGktdmFsdWVkIGNvbXBsZXggb2JqZWN0LiAgSSB3b3VsZCBzdWdnZXN0IHVzaW5nIGEg c2NoZW1hIGV4dGVuc2lvbiB0aGF0IGhhcyBhIGxpc3Qgb2YgcHJpbWl0aXZlcy4gIEFub3RoZXIg b3B0aW9uIHdvdWxkIGJlIHRvIHVzZSB0aGUgc3RhbmRhcmQgYWRkcmVzc2VzIGZpZWxkLCBidXQg b25seSBpbmNsdWRlIHRoZSDigJxmb3JtYXR0ZWTigJ0gc3ViLWF0dHJpYnV0ZS4NCg0KDQpGcm9t OiBzY2ltIDxzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTYXRoeWEgQmFuZGFy YQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxOCA4OjA5IEFNDQpUbzogc2NpbUBpZXRm Lm9yZw0KU3ViamVjdDogW3NjaW1dIElzIGl0IHBvc3NpYmxlIHRvIHVzZSBwcmltaXRpdmUgdHlw ZXMgd2l0aCBTQ0lNIGFkZHJlc3NlcyBjbGFpbT8NCg0KSGksDQpBcyBwZXIgdGhlIFNDSU0gY29y ZSBzY2hlbWEgc3BlY2lmaWNhdGlvbiBbMV0sIGFkZHJlc3NlcyBjbGFpbSBkZWZpbml0aW9uIGlz IGFzIGZvbGxvd3MuDQoNCmFkZHJlc3Nlcw0KDQogICAgICBBIHBoeXNpY2FsIG1haWxpbmcgYWRk cmVzcyBmb3IgdGhpcyB1c2VyLiAgQ2Fub25pY2FsIHR5cGUgdmFsdWVzDQoNCiAgICAgIG9mICJ3 b3JrIiwgImhvbWUiLCBhbmQgIm90aGVyIi4gIFRoaXMgYXR0cmlidXRlIGlzIGEgY29tcGxleCB0 eXBlDQoNCiAgICAgIHdpdGggdGhlIGZvbGxvd2luZyBzdWItYXR0cmlidXRlcy4gIEFsbCBzdWIt YXR0cmlidXRlcyBhcmUNCg0KICAgICAgT1BUSU9OQUwuDQpJbiBhIHNjZW5hcmlvIHdoZXJlIGFs bCB0aGUgc3ViLWF0dHJpYnV0ZXMgY2FuIGJlIGVtcHR5IGFzIHBlciBhYm92ZSBkZWZpbml0aW9u LCBjYW4gd2UgdXNlIHByaW1pdGl2ZSBhdHRyaWJ1dGUgdHlwZXMgKHN0cmluZyB2YWx1ZXMpIGFz IHRoZSBjbGFpbS12YWx1ZXMgZm9yIHRoaXMgY2xhaW0uIEUuZy4gLSAgYWRkcmVzc2VzOiBbImFk ZHJlc3MxIiwgImFkZHJlc3MyIl0NCldvdWxkIGJlIGdyYXRlZnVsIGlmIHlvdSBjb3VsZCBjbGFy aWZ5IHdoZXRoZXIgdGhpcyBpcyBwb3NzaWJsZS4NCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM3NjQzI3NlY3Rpb24tNC4xLjINCkJlc3QgcmVnYXJkcywNClNhdGh5YQ0KDQot LQ0KU2F0aHlhIEJhbmRhcmENClNvZnR3YXJlIEVuZ2luZWVyDQpXU08yIEluYy4gaHR0cDovL3dz bzIuY29tDQpNb2JpbGU6ICgrOTQpIDcxNSAzNjAgNDIxPHRlbDorOTQlMjA3MSUyMDQxMSUyMDUw MzI+DQpbaHR0cDovL2MuY29udGVudC53c28yLmNvbS9zaWduYXR1cmVzL3dzbzItc2lnbmF0dXJl LWdlbmVyYWwucG5nXQ0KDQo= --_000_BN7PR04MB38899330C8CE63EDF2EA5DF5E2B60BN7PR04MB3889namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBpcyBsaWtlbHkgdG8gYnJlYWsgb3RoZXIgY2xpZW50cy9zZXJ2ZXJzIHRo YXQgZXhwZWN0IGEgbXVsdGktdmFsdWVkIGNvbXBsZXggb2JqZWN0LiZuYnNwOyBJIHdvdWxkIHN1 Z2dlc3QgdXNpbmcgYSBzY2hlbWEgZXh0ZW5zaW9uIHRoYXQgaGFzIGEgbGlzdCBvZiBwcmltaXRp dmVzLiZuYnNwOyBBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSB0byB1c2UgdGhlIHN0YW5kYXJkIGFk ZHJlc3NlcyBmaWVsZCwgYnV0IG9ubHkgaW5jbHVkZQ0KIHRoZSDigJxmb3JtYXR0ZWTigJ0gc3Vi LWF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gc2NpbSAmbHQ7c2NpbS1ib3VuY2Vz QGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KU2F0aHlhIEJhbmRhcmE8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxOCA4OjA5IEFNPGJyPg0KPGI+VG86 PC9iPiBzY2ltQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzY2ltXSBJcyBpdCBwb3Nz aWJsZSB0byB1c2UgcHJpbWl0aXZlIHR5cGVzIHdpdGggU0NJTSBhZGRyZXNzZXMgY2xhaW0/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyBwZXIg dGhlIFNDSU0gY29yZSBzY2hlbWEgc3BlY2lmaWNhdGlvbiBbMV0sIGFkZHJlc3NlcyBjbGFpbSBk ZWZpbml0aW9uIGlzIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHBy ZT5hZGRyZXNzZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgQSBwaHlzaWNhbCBtYWlsaW5nIGFkZHJlc3MgZm9yIHRoaXMgdXNlci4mbmJzcDsg Q2Fub25pY2FsIHR5cGUgdmFsdWVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mICZxdW90O3dvcmsmcXVvdDssICZxdW90O2hvbWUmcXVvdDss IGFuZCAmcXVvdDtvdGhlciZxdW90Oy4mbmJzcDsgVGhpcyBhdHRyaWJ1dGUgaXMgYSBjb21wbGV4 IHR5cGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgd2l0aCB0aGUgZm9sbG93aW5nIHN1Yi1hdHRyaWJ1dGVzLiZuYnNwOyBBbGwgc3ViLWF0dHJp YnV0ZXMgYXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9QVElPTkFMLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluIGEgc2NlbmFyaW8g d2hlcmUgYWxsIHRoZSBzdWItYXR0cmlidXRlcyBjYW4gYmUgZW1wdHkgYXMgcGVyIGFib3ZlIGRl ZmluaXRpb24sIGNhbiB3ZSB1c2UgcHJpbWl0aXZlIGF0dHJpYnV0ZSB0eXBlcyAoc3RyaW5nIHZh bHVlcykgYXMgdGhlIGNsYWltLXZhbHVlcyBmb3IgdGhpcyBjbGFpbS4gRS5nLiAtJm5ic3A7DQo8 aT5hZGRyZXNzZXM6IFsmcXVvdDthZGRyZXNzMSZxdW90OywgJnF1b3Q7YWRkcmVzczImcXVvdDtd PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCBi ZSBncmF0ZWZ1bCBpZiB5b3UgY291bGQgY2xhcmlmeSB3aGV0aGVyIHRoaXMgaXMgcG9zc2libGUu PGJyPg0KPGJyPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 NjQzI3NlY3Rpb24tNC4xLjIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjQzI3Nl Y3Rpb24tNC4xLjI8YnI+DQo8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2F0aHlhPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij5TYXRoeWEgQmFuZGFyYTxicj4NClNvZnR3YXJlIEVuZ2luZWVyPGJyPg0KV1NPMiBJbmMu IDxhIGhyZWY9Imh0dHA6Ly93c28yLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93c28yLmNv bTwvYT4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TW9iaWxlOiA8YSBocmVmPSJ0ZWw6JiM0Mzs5 NCUyMDcxJTIwNDExJTIwNTAzMiIgdGFyZ2V0PSJfYmxhbmsiPg0KKCYjNDM7OTQpIDcxNSAzNjAg NDIxPC9hPjxicj4NCjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHA6 Ly9jLmNvbnRlbnQud3NvMi5jb20vc2lnbmF0dXJlcy93c28yLXNpZ25hdHVyZS1nZW5lcmFsLnBu ZyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN7PR04MB38899330C8CE63EDF2EA5DF5E2B60BN7PR04MB3889namp_-- From nobody Wed Apr 18 08:45:00 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C31243F3 for ; Wed, 18 Apr 2018 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWqnh9JpNJJu for ; Wed, 18 Apr 2018 08:44:57 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 DD27A120727 for ; Wed, 18 Apr 2018 08:44:56 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id v64-v6so2412941otb.13 for ; Wed, 18 Apr 2018 08:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=woAMyHLUDPgGR/XyctFHIX5NOsajM9oD4t+C+fTwUFE=; b=Kk2ar7pU08qszIHdBOYmh5LiRtnJapNbKO6FMWGyGH1rWPoIXF+S7qYiv7rEYbry1a PYLOF2p/ypSH6fBgLyIIvCFlzqkLq9kdPj5eaV9+KYgR5UZTYQL7awtDZnYEVD8S4k4j 5NhIlxTkNwhkwbtbsCHPLuCN96mxCD4WLm+cA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=woAMyHLUDPgGR/XyctFHIX5NOsajM9oD4t+C+fTwUFE=; b=rfWfF5k0NQpKECk61cxuwhQIocE0BTcrdWQe5hdw1hWrPGCqY1aSAvX3hgMVYTIS2s lVfumkbD0auvUOqMtUJnJqPgRhL7CzfGJW5i2wM0GEmuAuelFqI3HgDfMNMOkPKyDUR+ Vvi7psNKavZEOxg/SdknsU6LirhtaEtPS9J/+YV5mqPQOmZVDII1GJZA4gSrJthv4u0n R7/6uyuJWuuu8uj71ggurNn1CcVBwTuTvSLHvTKHgTi8P+4S5I5CyMIJoQOMlwn1Q+nb dYHbBoOo4wjP1R12g4SXxR9rEQrhtzLCzXek23a44Aa7xI4hornVJC0MbrakoVrSuziv KXxw== X-Gm-Message-State: ALQs6tD3XeBX2jNIP5XtOcw5M7d+8pBagbAblK1UcEyZWJlT4R4srAbT dSRUF2z++czVdYiOiTJvksUhdRY0x/QeIjM29G7Fyg== X-Google-Smtp-Source: AIpwx49/HrQsRyHaV5Wuf62fN+HlX+kEiyLpBU6TxP0eJIhpwShKM9cGo6OQTjPf/oekiGsUN6+ViI1UH7eaZHKmXzA= X-Received: by 2002:a9d:509:: with SMTP id 9-v6mr1715539otw.342.1524066296237; Wed, 18 Apr 2018 08:44:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sathya Bandara Date: Wed, 18 Apr 2018 15:44:45 +0000 Message-ID: To: Kelly Grizzle Cc: scim@ietf.org Content-Type: multipart/alternative; boundary="00000000000033a85a056a21566f" Archived-At: Subject: Re: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:44:59 -0000 --00000000000033a85a056a21566f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kelly, Thanks for the quick response. So if we allow primitive types as well, in addition to complex types for the addresses claim from server side, would it violate the schema? On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle wrote: > This is likely to break other clients/servers that expect a multi-valued > complex object. I would suggest using a schema extension that has a list > of primitives. Another option would be to use the standard addresses > field, but only include the =E2=80=9Cformatted=E2=80=9D sub-attribute. > > > > > > *From:* scim *On Behalf Of * Sathya Bandara > *Sent:* Wednesday, April 18, 2018 8:09 AM > *To:* scim@ietf.org > *Subject:* [scim] Is it possible to use primitive types with SCIM > addresses claim? > > > > Hi, > > As per the SCIM core schema specification [1], addresses claim definition > is as follows. > > addresses > > A physical mailing address for this user. Canonical type values > > of "work", "home", and "other". This attribute is a complex type > > with the following sub-attributes. All sub-attributes are > > OPTIONAL. > > In a scenario where all the sub-attributes can be empty as per above > definition, can we use primitive attribute types (string values) as the > claim-values for this claim. E.g. - *addresses: ["address1", "address2"]= * > > Would be grateful if you could clarify whether this is possible. > > [1] https://tools.ietf.org/html/rfc7643#section-4.1.2 > > Best regards, > > Sathya > > > -- > > Sathya Bandara > Software Engineer > WSO2 Inc. http://wso2.com > > Mobile: (+94) 715 360 421 <+94%2071%20411%205032> > > > --00000000000033a85a056a21566f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kelly,

Thanks for the quick response.=C2=A0
So if we all= ow primitive types as well, in addition to complex types for the addresses = claim from server side, would it violate the schema?


On Wed, Apr 18, 2018, 7:17 PM Kelly Griz= zle <kelly.grizzle@sailpo= int.com> wrote:

This is likely to break other clients/servers that e= xpect a multi-valued complex object.=C2=A0 I would suggest using a schema e= xtension that has a list of primitives.=C2=A0 Another option would be to us= e the standard addresses field, but only include the =E2=80=9Cformatted=E2=80=9D sub-attribute.

=C2=A0

=C2=A0

From: scim <scim-bounces@ietf.org&g= t; On Behalf Of Sathya Bandara
Sent: Wednesday, April 18, 2018 8:09 AM
To: scim@ietf.org
Subject: [scim] Is it possible to use primitive types with SCIM addr= esses claim?

=C2=A0

Hi,

As per the SCIM core = schema specification [1], addresses claim definition is as follows.<= u>

addresses
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A physical mailing address for this use=
r.=C2=A0 Canonical type values
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of "work", "home", =
and "other".=C2=A0 This attribute is a complex type=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the following sub-attributes.=C2=
=A0 All sub-attributes are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.

In a scenario where a= ll the sub-attributes can be empty as per above definition, can we use prim= itive attribute types (string values) as the claim-values for this claim. E= .g. -=C2=A0 addresses: ["address1", "address2"]

Would be grateful if you could clarify whether this = is possible.

[1] https://tools.ietf.org/html/rfc7643#section-4.1= .2

Best regards,

Sathya


--

Sathya Bandara
Software Engineer
WSO2 Inc. = http://wso2.com

Mobile: (+94) 715 360 421


--00000000000033a85a056a21566f-- From nobody Wed Apr 18 09:36:26 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738912DA23 for ; Wed, 18 Apr 2018 09:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5r3TqEFKYwD for ; Wed, 18 Apr 2018 09:36:09 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 230C6127137 for ; Wed, 18 Apr 2018 09:36:09 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3IGVbHD174279; Wed, 18 Apr 2018 16:36:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=qfvx/mbtFVC/qT1wwO+mlTik7ixPisq24GXhmU1HPuQ=; b=CfEVzVhhp1qWhk5uBXzR8DmPg2Uz3GthsdBCe6na++5Ns6P5SQyMhVmX89d1pgZPjMds mBM8F88VPyCBs+xtyvHenei/lInnfRFX2PKSGTIrgkz9r/pTyBnAgbM0UyTJk8nHt7tL LVWyj7hqF0aqfBJqnJh3shvW4yWTe3AWluYsiI+UYvnRnK9bTz8Immh+yM5yTYRHllFx h7y1X+K8IxbSFnLP8UEUxI8uKXGfuKCiwE6Vcu9c2gcD7jo2I+o/8CdnkkryUucw5NG1 vB5AaP4ZWD22Fyaj2uBzsqfdtXCKxa1WvdhdvnzF+kJoFNBSRIeG6Y2URVLoRjAFa8Ul hA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2hdrxnbjvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Apr 2018 16:36:08 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3IGa7Ov002201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Apr 2018 16:36:07 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w3IGa6EE003664; Wed, 18 Apr 2018 16:36:06 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Apr 2018 09:36:06 -0700 From: Phil Hunt Message-Id: <42363E44-201A-4370-9E79-E1B38158C3B1@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2BFDED9-7126-4754-ACBD-C858AC531CA5" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 18 Apr 2018 09:36:17 -0700 In-Reply-To: Cc: Kelly Grizzle , scim@ietf.org To: Sathya Bandara References: X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8867 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804180149 Archived-At: Subject: Re: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 16:36:18 -0000 --Apple-Mail=_E2BFDED9-7126-4754-ACBD-C858AC531CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. The expectation is for some consistency in presentation across = implementations. So if you are mapping LDAP data, you have to parse the address value = into the sub-attributes for addresses in SCIM. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 18, 2018, at 8:44 AM, Sathya Bandara wrote: >=20 > Hi Kelly, >=20 > Thanks for the quick response.=20 > So if we allow primitive types as well, in addition to complex types = for the addresses claim from server side, would it violate the schema? >=20 >=20 > On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle = > = wrote: > This is likely to break other clients/servers that expect a = multi-valued complex object. I would suggest using a schema extension = that has a list of primitives. Another option would be to use the = standard addresses field, but only include the =E2=80=9Cformatted=E2=80=9D= sub-attribute. >=20 > =20 >=20 > =20 >=20 > From: scim > On = Behalf Of Sathya Bandara > Sent: Wednesday, April 18, 2018 8:09 AM > To: scim@ietf.org > Subject: [scim] Is it possible to use primitive types with SCIM = addresses claim? >=20 > =20 >=20 > Hi, >=20 > As per the SCIM core schema specification [1], addresses claim = definition is as follows. >=20 > addresses > A physical mailing address for this user. Canonical type values > of "work", "home", and "other". This attribute is a complex = type > with the following sub-attributes. All sub-attributes are > OPTIONAL. > In a scenario where all the sub-attributes can be empty as per above = definition, can we use primitive attribute types (string values) as the = claim-values for this claim. E..g. - addresses: ["address1", = "address2"] >=20 > Would be grateful if you could clarify whether this is possible. >=20 > [1] https://tools.ietf.org/html/rfc7643#section-4.1..2 > = > Best regards, >=20 > Sathya >=20 >=20 > --=20 >=20 > Sathya Bandara > Software Engineer > WSO2 Inc. http://wso2.com = > Mobile: (+94) 715 360 421 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DBiPVo8BLSRchQq0X5X8fT= O2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZvFAE&e=3D= = --Apple-Mail=_E2BFDED9-7126-4754-ACBD-C858AC531CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes. = The expectation is for some consistency in presentation across = implementations.

So = if you are mapping LDAP data, you have to parse the address value into = the sub-attributes for addresses in SCIM.

Phil

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

On Apr 18, 2018, at 8:44 AM, Sathya Bandara <sathya@wso2.com> = wrote:

Hi Kelly,

Thanks for = the quick response. 
So if we = allow primitive types as well, in addition to complex types for the = addresses claim from server side, would it violate the schema?


On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

This = is likely to break other clients/servers that expect a multi-valued = complex object.  I would suggest using a schema extension that has = a list of primitives.  Another option would be to use the standard = addresses field, but only include the =E2=80=9Cformatted=E2=80=9D = sub-attribute.

 

 

From: scim <scim-bounces@ietf.org> On Behalf = Of Sathya = Bandara
Sent: Wednesday, April 18, 2018 = 8:09 AM
To: scim@ietf.org
Subject: [scim] Is it possible to = use primitive types with SCIM addresses claim?

 

Hi,

As per the SCIM core = schema specification [1], addresses claim definition is as follows.

addresses
      A physical mailing address for =
this user.  Canonical type values
      of =
"work", "home", and "other".  This attribute is a complex type
      with the following =
sub-attributes.  All sub-attributes are
      =
OPTIONAL.

In a scenario where = all the sub-attributes can be empty as per above definition, can we use = primitive attribute types (string values) as the claim-values for this = claim. E..g. -  addresses: ["address1", "address2"]

Would be grateful if you = could clarify whether this is possible.

[1] https://tools.ietf.org/html/rfc7643#section-4.1..2

Best regards,

Sathya


-- 

Sathya Bandara
Software = Engineer
WSO2 Inc. http://wso2.com

Mobile: (+94) 715 360 421


<= /div>
_______________________________________________
scim mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DBiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2yN= Ne4Oge4LN28CoFDhjAa2pKZvFAE&e=3D

= --Apple-Mail=_E2BFDED9-7126-4754-ACBD-C858AC531CA5-- From nobody Wed Apr 18 09:44:39 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED185126C2F for ; Wed, 18 Apr 2018 09:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyjPrLsAjXHg for ; Wed, 18 Apr 2018 09:44:36 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 E47611242F7 for ; Wed, 18 Apr 2018 09:44:35 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3IGfMGk056456; Wed, 18 Apr 2018 16:44:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=xR9YGuUjIwqAsWinE2oxnfrV6xTH1Ui0K8HBe0om/2c=; b=N+DKDwEujllmpFjnDrNswhQSSJtnc/DYyvrEoC/OE7gAYx4I2Nd5rdj6mLfx+h4AF3Qu QgemhJn38szvuhaSMs6eQRauLbiB2zWfCf0jnzmZGvj9nRDBP0ph6nXLeR5oB8qjSwsL 2oAv8aPofaKsQHXLR2jnnze711Eo74T/9a3fWOC/22TGniyulQvdpBXOy9uVFu+F+/St U0yDv2YmusoEkRO3nrD2y7MWDaHmFAVO6yCQxvg+uUJXKSz/BiK+zxvNM+XrsH8I1cHa 7VthD0qFhq1Wg4QiyBgH39+6RK4rXT+3JkGiB44kcnAfTAIClrCNae1Czuzt5q3ewxyr eQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2hdrxp3mdr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Apr 2018 16:44:34 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3IGiX7e013260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Apr 2018 16:44:34 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w3IGiXlD011033; Wed, 18 Apr 2018 16:44:33 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Apr 2018 09:44:33 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EC2ACCAC-5126-46AB-8C99-0EC9CEC5D81F" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 18 Apr 2018 09:44:44 -0700 In-Reply-To: <42363E44-201A-4370-9E79-E1B38158C3B1@oracle.com> Cc: scim@ietf.org, Kelly Grizzle To: Sathya Bandara References: <42363E44-201A-4370-9E79-E1B38158C3B1@oracle.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8867 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804180150 Archived-At: Subject: Re: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 16:44:38 -0000 --Apple-Mail=_EC2ACCAC-5126-46AB-8C99-0EC9CEC5D81F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To clarify that was =E2=80=9Cyes=E2=80=9D as in it would violate the = schema. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 18, 2018, at 9:36 AM, Phil Hunt wrote: >=20 > Yes. The expectation is for some consistency in presentation across = implementations. >=20 > So if you are mapping LDAP data, you have to parse the address value = into the sub-attributes for addresses in SCIM. >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@o= racle.com >=20 >> On Apr 18, 2018, at 8:44 AM, Sathya Bandara > wrote: >>=20 >> Hi Kelly, >>=20 >> Thanks for the quick response.=20 >> So if we allow primitive types as well, in addition to complex types = for the addresses claim from server side, would it violate the schema? >>=20 >>=20 >> On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle = > = wrote: >> This is likely to break other clients/servers that expect a = multi-valued complex object. I would suggest using a schema extension = that has a list of primitives. Another option would be to use the = standard addresses field, but only include the =E2=80=9Cformatted=E2=80=9D= sub-attribute. >>=20 >> =20 >>=20 >> =20 >>=20 >> From: scim > On = Behalf Of Sathya Bandara >> Sent: Wednesday, April 18, 2018 8:09 AM >> To: scim@ietf.org >> Subject: [scim] Is it possible to use primitive types with SCIM = addresses claim? >>=20 >> =20 >>=20 >> Hi, >>=20 >> As per the SCIM core schema specification [1], addresses claim = definition is as follows. >>=20 >> addresses >> A physical mailing address for this user. Canonical type = values >> of "work", "home", and "other". This attribute is a complex = type >> with the following sub-attributes. All sub-attributes are >> OPTIONAL. >> In a scenario where all the sub-attributes can be empty as per above = definition, can we use primitive attribute types (string values) as the = claim-values for this claim. E..g. - addresses: ["address1", = "address2"] >>=20 >> Would be grateful if you could clarify whether this is possible. >>=20 >> [1] https://tools.ietf.org/html/rfc7643#section-4.1..2 >> = >> Best regards, >>=20 >> Sathya >>=20 >>=20 >> --=20 >>=20 >> Sathya Bandara >> Software Engineer >> WSO2 Inc. http://wso2.com = >> Mobile: (+94) 715 360 421 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf..org_mailm= an_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn= E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DBiPVo8BLSRchQq0X5X8f= TO2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZvFAE&e=3D= = > _______________________________________________ > scim mailing list > scim@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DK6UEQCIxf3e1RlkBwJAmc= 0so58P9Li0dZnNgGTcSUQ4&s=3DP7pirz7KGVgCVDLb0ds_tElr0yrM921L8jtIVtrue8k&e=3D= --Apple-Mail=_EC2ACCAC-5126-46AB-8C99-0EC9CEC5D81F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = clarify that was =E2=80=9Cyes=E2=80=9D as in it would violate the = schema.

Phil

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

On Apr 18, 2018, at 9:36 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Yes. The expectation = is for some consistency in presentation across implementations.

So if you are mapping = LDAP data, you have to parse the address value into the sub-attributes = for addresses in SCIM.

Phil

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

On Apr 18, 2018, at 8:44 AM, Sathya Bandara <sathya@wso2.com> = wrote:

Hi Kelly,

Thanks for = the quick response. 
So if we = allow primitive types as well, in addition to complex types for the = addresses claim from server side, would it violate the schema?


On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

This = is likely to break other clients/servers that expect a multi-valued = complex object.  I would suggest using a schema extension that has = a list of primitives.  Another option would be to use the standard = addresses field, but only include the =E2=80=9Cformatted=E2=80=9D = sub-attribute.

 

 

From: scim <scim-bounces@ietf.org> On Behalf = Of Sathya = Bandara
Sent: Wednesday, April 18, 2018 = 8:09 AM
To: scim@ietf.org
Subject: [scim] Is it possible to = use primitive types with SCIM addresses claim?

 

Hi,

As per the SCIM core = schema specification [1], addresses claim definition is as follows.

addresses
      A physical mailing address for =
this user.  Canonical type values
      of =
"work", "home", and "other".  This attribute is a complex type
      with the following =
sub-attributes.  All sub-attributes are
      =
OPTIONAL.

In a scenario where = all the sub-attributes can be empty as per above definition, can we use = primitive attribute types (string values) as the claim-values for this = claim. E..g. -  addresses: ["address1", "address2"]

Would be grateful if you = could clarify whether this is possible.

[1] https://tools.ietf.org/html/rfc7643#section-4.1..2

Best regards,

Sathya


-- 

Sathya Bandara
Software = Engineer
WSO2 Inc. http://wso2.com

Mobile: (+94) 715 360 421


<= /div>
_______________________________________________
scim mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= ..org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh= 8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&a= mp;m=3DBiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2y= NNe4Oge4LN28CoFDhjAa2pKZvFAE&e=3D

_______________________________________= ________
scim mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DK6UEQCIxf3e1RlkBwJAmc0so58P9Li0dZnNgGTcSUQ4&s=3DP7pirz7KGVgCVDLb= 0ds_tElr0yrM921L8jtIVtrue8k&e=3D

= --Apple-Mail=_EC2ACCAC-5126-46AB-8C99-0EC9CEC5D81F-- From nobody Wed Apr 18 10:24:58 2018 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8FA12D881 for ; Wed, 18 Apr 2018 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw-Qd3cjLcss for ; Wed, 18 Apr 2018 10:24:53 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 6884A126D85 for ; Wed, 18 Apr 2018 10:24:53 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id y46-v6so2796230otd.4 for ; Wed, 18 Apr 2018 10:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zwy9L6i+2oIM2GGF/5OadHOFaMAA60yJFdtAnrKwVF8=; b=T7JvuJ6gvO+XMKEQ2Vy94WO/soxVDrLIeurycSTJ5Zk7JRlMgsjcFgE6uHEbrjIGw2 9s6K/CzjpoXUEwEFLxgvu/NjFwdxhlxKftMsAXSAmpsOmrgZApkhPAsufJ8yHIsLGBTc erYWN12p32mXVtCIc513jroChH5qC88CM2+e0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zwy9L6i+2oIM2GGF/5OadHOFaMAA60yJFdtAnrKwVF8=; b=CFx/A+DYIZeOJJW3u4Mj3qFBEiiX/YQCOlIeEmAErADKr6qyGjOA40HpBsxJr8xLLn DJBCPD/CmWy56ZIGO0DsK3KBk5wH4HOcAgm+7/MEof791Pb0HNG1slVesAgLrXKYoLLK Mf7VLlmVRJQwyYSbQ4l8iM+ibNKXnZfcAGRFFm0U/s9kxRsfMgyr+1b2kow7bLicN9dm Z018/nJ8YUhKnwIQFzo8pMRKS59a4VdZZfSliIykYrnxKLFfToCgeqfiDIKgxOLtd+rd llPsGAs10wBHau9qtdl1IlNxnIDfUoQp/AJ+RAMAtepQoYMY+w5+wRTFke7taAytfc1M XSIw== X-Gm-Message-State: ALQs6tC0PRWDK8d6WZ5nMj4PBGh1Q6eBlGl/G8vDFPQRToD1tLntncaF u/yZ2y7WjQPHUDKvxmDNmxszoh4+Yd8psSY6Tmv2SA== X-Google-Smtp-Source: AIpwx4+uwQz1GS9TZkkbNtY1rCPuNhFSP9qfN4Ox7sKI5J95weLMvroFRhs/vtcCImWCQuV2SdLQDaR3D5EUpd+TpxE= X-Received: by 2002:a9d:4ee:: with SMTP id 101-v6mr1726356otm.122.1524072292761; Wed, 18 Apr 2018 10:24:52 -0700 (PDT) MIME-Version: 1.0 References: <42363E44-201A-4370-9E79-E1B38158C3B1@oracle.com> In-Reply-To: From: Sathya Bandara Date: Wed, 18 Apr 2018 17:24:42 +0000 Message-ID: To: Phil Hunt Cc: scim@ietf.org, Kelly Grizzle Content-Type: multipart/alternative; boundary="0000000000009f5d41056a22bb48" Archived-At: Subject: Re: [scim] Is it possible to use primitive types with SCIM addresses claim? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:24:57 -0000 --0000000000009f5d41056a22bb48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Phil, for the clarification. Best regards, Sathya On Wed, Apr 18, 2018, 10:14 PM Phil Hunt wrote: > To clarify that was =E2=80=9Cyes=E2=80=9D as in it would violate the sche= ma. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Apr 18, 2018, at 9:36 AM, Phil Hunt wrote: > > Yes. The expectation is for some consistency in presentation across > implementations. > > So if you are mapping LDAP data, you have to parse the address value into > the sub-attributes for addresses in SCIM. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > > phil.hunt@oracle.com > > On Apr 18, 2018, at 8:44 AM, Sathya Bandara wrote: > > Hi Kelly, > > Thanks for the quick response. > So if we allow primitive types as well, in addition to complex types for > the addresses claim from server side, would it violate the schema? > > > On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle > wrote: > >> This is likely to break other clients/servers that expect a multi-valued >> complex object. I would suggest using a schema extension that has a lis= t >> of primitives. Another option would be to use the standard addresses >> field, but only include the =E2=80=9Cformatted=E2=80=9D sub-attribute. >> >> >> >> >> >> *From:* scim *On Behalf Of *Sathya Bandara >> *Sent:* Wednesday, April 18, 2018 8:09 AM >> *To:* scim@ietf.org >> *Subject:* [scim] Is it possible to use primitive types with SCIM >> addresses claim? >> >> >> >> Hi, >> >> As per the SCIM core schema specification [1], addresses claim definitio= n >> is as follows. >> >> addresses >> >> A physical mailing address for this user. Canonical type values >> >> of "work", "home", and "other". This attribute is a complex type >> >> with the following sub-attributes. All sub-attributes are >> >> OPTIONAL. >> >> In a scenario where all the sub-attributes can be empty as per above >> definition, can we use primitive attribute types (string values) as the >> claim-values for this claim. E..g. - *addresses: ["address1", >> "address2"]* >> >> Would be grateful if you could clarify whether this is possible. >> >> [1] https://tools.ietf.org/html/rfc7643#section-4.1..2 >> >> >> >> Best regards, >> >> Sathya >> >> >> -- >> >> Sathya Bandara >> Software Engineer >> WSO2 Inc. http://wso2.com >> >> >> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >> >> >> _______________________________________________ > scim mailing list > scim@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf..org_mail= man_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn= E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DBiPVo8BLSRchQq0X5X8fT= O2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZvFAE&e=3D > > > > _______________________________________________ > scim mailing list > scim@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DK6UEQCIxf3e1RlkBwJAmc0= so58P9Li0dZnNgGTcSUQ4&s=3DP7pirz7KGVgCVDLb0ds_tElr0yrM921L8jtIVtrue8k&e=3D > > > --0000000000009f5d41056a22bb48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Phil, for the clarification.
<= br>
Best regards,
Sathya

On Wed, Apr 18, 2018= , 10:14 PM Phil Hunt <phil.hunt@= oracle.com> wrote:
To clarify that wa= s =E2=80=9Cyes=E2=80=9D as in it would violate the schema.

=
Phil

Oracle Corporation, Identity Cloud Services Architect
@inde= pendentid
phil.hunt@oracle.com

On Apr 18, 2018, at 9:36 AM, Phil H= unt <phil.hunt@oracle.com> wrote:

Yes. The expectation is for some consistenc= y in presentation across implementations.

So if you are = mapping LDAP data, you have to parse the address value into the sub-attribu= tes for addresses in SCIM.

Phil

= Oracle Corporation, Identity Cloud Services Architect
@independen= tid
phil.hunt@oracle.com<= /a>
=


Hi Kelly,

Thanks for the quic= k response.=C2=A0
So if we allow primitive types as = well, in addition to complex types for the addresses claim from server side= , would it violate the schema?


On Wed, Apr 18, 2018, 7:17 PM Kelly Grizzle <kelly= .grizzle@sailpoint.com> wrote:

This is likely = to break other clients/servers that expect a multi-valued complex object.= =C2=A0 I would suggest using a schema extension that has a list of primitiv= es.=C2=A0 Another option would be to use the standard addresses field, but = only include the =E2=80=9Cformatted=E2=80=9D sub-attribute.

=C2=A0

= =C2=A0

From:=C2=A0scim <scim-bounces@ietf.org>=C2=A0On Behalf Of=C2=A0Sathya Bandara
Sent:=C2=A0Wedne= sday, April 18, 2018 8:09 AM
To:=C2=A0scim@ietf.org
Subjec= t:=C2=A0[scim] Is it possible to use primitive types with SCIM addresses claim?<= u>

=C2=A0

<= div>

Hi,

As pe= r the SCIM core schema specification [1], addresses claim definition is as = follows.

addresses
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A physical mailing address for t=
his user.=C2=A0 Canonical type values
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 of "work", "home", and "other&q=
uot;.=C2=A0 This attribute is a complex type
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 with the following sub-attributes.=C2=A0 All sub-a=
ttributes are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTION=
AL.

In a scenario where all the sub-attributes can be empty as per= above definition, can we use primitive attribute types (string values) as = the claim-values for this claim. E..g. -=C2=A0=C2=A0addresses: ["address1&qu= ot;, "address2"]

Would be grateful if you could clarify whether this is possible.

[= 1]=C2=A0<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf= .org_html_rfc7643-23section-2D4.1.2&d=3DDwMFaQ&c=3DRoP1YumCXCgaWHvl= ZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4= KZNA&m=3DBiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=3D7e1irqMvgY= OZIoQ9yOV21JO5A5HG_dDXUI-Udjpo5NI&e=3D" rel=3D"noreferrer noreferrer" t= arget=3D"_blank">https://tools.ietf.org/html/rfc7643#section-4.1..2
=

Best regards,<= /p>

Sathya

<= div>


--=C2=A0=

Sathya Bandara
Software Engineer
WSO2 Inc.=C2=A0http://wso2.com<= u>

Mobile:=C2=A0= (+94) 715 360 421


<= /p>

=
_______________________________________________
scim mailing list
scim@ietf.org
= https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf..org_mailman_listinf= o_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&a= mp;r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DBiPVo8BLSRchQq0X= 5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=3DMGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZ= vFAE&e=3D

_____= __________________________________________
scim mailing list
scim@ietf.or= g
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU= B65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DK6U= EQCIxf3e1RlkBwJAmc0so58P9Li0dZnNgGTcSUQ4&s=3DP7pirz7KGVgCVDLb0ds_tElr0y= rM921L8jtIVtrue8k&e=3D

= --0000000000009f5d41056a22bb48--