Re: [scim] Is it possible to use primitive types with SCIM addresses claim?

Phil Hunt <phil.hunt@oracle.com> Wed, 18 April 2018 16:44 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED185126C2F for <scim@ietfa.amsl.com>; 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 <scim@ietfa.amsl.com>; 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 <scim@ietf.org>; 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 <phil.hunt@oracle.com>
Message-Id: <CD4E026C-5DF9-4AAD-B0F2-C34992CEDCD8@oracle.com>
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 <kelly.grizzle@sailpoint.com>
To: Sathya Bandara <sathya@wso2.com>
References: <CAAdTB9Ey5xGfb=xcn19=NTdtJg_Td_z3qXjUfg=F28F93BY7BQ@mail.gmail.com> <BN7PR04MB38899330C8CE63EDF2EA5DF5E2B60@BN7PR04MB3889.namprd04.prod.outlook.com> <CAAdTB9HqWZ_jP0s4hOY1kjEMMkf9gzaPEJfT-pCibmaa=R+02g@mail.gmail.com> <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: <https://mailarchive.ietf.org/arch/msg/scim/nopW0BiU2109PYDRtxjmwiuLkYs>
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 <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 16:44:38 -0000

To clarify that was “yes” as in it would violate the schema.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto: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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=K6UEQCIxf3e1RlkBwJAmc0so58P9Li0dZnNgGTcSUQ4&s=rScN-d7CjGqHWE0iYfsWh8-NKNBq5Lrm4ooaVr3DQU4&e=>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
>> On Apr 18, 2018, at 8:44 AM, Sathya Bandara <sathya@wso2.com <mailto: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 <mailto: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 “formatted” sub-attribute.
>> 
>>  
>> 
>>  
>> 
>> From: scim <scim-bounces@ietf.org <mailto:scim-bounces@ietf.org>> On Behalf Of Sathya Bandara
>> Sent: Wednesday, April 18, 2018 8:09 AM
>> To: scim@ietf.org <mailto: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
>>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7643-23section-2D4.1.2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=BiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=7e1irqMvgYOZIoQ9yOV21JO5A5HG_dDXUI-Udjpo5NI&e=>
>> Best regards,
>> 
>> Sathya
>> 
>> 
>> -- 
>> 
>> Sathya Bandara
>> Software Engineer
>> WSO2 Inc. http://wso2.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__wso2.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=BiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=IFRilCcF6Ve_ZSRufegaA_-VJ9NtyRqavRA7ymgOQjo&e=>
>> Mobile: (+94) 715 360 421 <tel:+94%2071%20411%205032>
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org <mailto:scim@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=BiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=MGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZvFAE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=BiPVo8BLSRchQq0X5X8fTO2Sc7XlO9d4vnvrMJ9immA&s=MGbT_IyCqPu-X2yNNe4Oge4LN28CoFDhjAa2pKZvFAE&e=>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=K6UEQCIxf3e1RlkBwJAmc0so58P9Li0dZnNgGTcSUQ4&s=P7pirz7KGVgCVDLb0ds_tElr0yrM921L8jtIVtrue8k&e=