Re: [scim] Common Attribute "schemas" Characteristics

Phillip Hunt <phil.hunt@independentid.com> Sat, 12 September 2020 00:26 UTC

Return-Path: <phil.hunt@independentid.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 61F103A08CF for <scim@ietfa.amsl.com>; Fri, 11 Sep 2020 17:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.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 VNqz49IO88PK for <scim@ietfa.amsl.com>; Fri, 11 Sep 2020 17:26:25 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 764373A08C4 for <scim@ietf.org>; Fri, 11 Sep 2020 17:26:25 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id a9so2501777pjg.1 for <scim@ietf.org>; Fri, 11 Sep 2020 17:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=rwvS5ay8xfAgeehrpWeSi52ktxHMHzCBQCBfqaa3b7U=; b=J5rvjxt+EGeVk6tDhirE9n4nIEvmN1hHhFGitYULUXt+SkysM1oVSWEMiDSCeokg09 +VyO9CrUNRwxVBnhr4ClYJATjaxEOMfO5FmpyXlBb3bvgwOYUOs8IdKCCIvIeaMJlN2k f3ZuVq+0NTQI98WMBBYa9NGtj24p2jq1yOKAUCCqSFkg8n++b+RHoN4syt6wsKSUpjI8 +e9WriHbGCBhZic2rmqTnin+9PzZ6el+n0zngdmJBCV8fQd0dvSO58IrK3RPL2cC48Wb sHUIHM4C4Eyvso8rR/+w11IqdW+dDMd771hT5ATlz61qs2zka32/K75h/E4L4Y3QnCk8 aJAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=rwvS5ay8xfAgeehrpWeSi52ktxHMHzCBQCBfqaa3b7U=; b=auYgz1U8pl7aYrWG+A7kHLOiV1+SmpttfGfvSy+oWLFvZi4p2q1hScdsHd8Zzx2yvL 8ZsJzUNtChEHhwsLw0ZqydqOJEfk0D+6TPJEGGKPE18PiiAmoGoFLm01Kq7ce7+Pg3WZ QhMImNCXUaxDLUvXb7ZkD5Pxz0xzfFW8dR1+7OBpTX3AKPKtQTe+X85SnZluE1cF7GMJ fxoEQrqL0MxcECwszoPGx96upCUbewrhEuEsDsG7QWB011f5QcEA99tPOba9A/NLFJQE a08x0Xda64s6XKUcutO/MpEh5R/7tOnGmv68JW9A70tCZWIm9xSIKbY23IGLYj3v7tZf oy+w==
X-Gm-Message-State: AOAM533psI+nA/b+gg3hQElWw7cP1wThKyXx4uX6KqxifzDVP7xhFh3b AkNKs+81WPG8H5LWkGHWuR4UpvRbe7NwvQ==
X-Google-Smtp-Source: ABdhPJzyqIaDrxZP8q8DY36sYBqvAgEVbxgQy1NsXDBecm4OzU/mHPFSCBY44PXEMyhH3UHSIoOt+g==
X-Received: by 2002:a17:90a:fb53:: with SMTP id iq19mr4456082pjb.122.1599870383347; Fri, 11 Sep 2020 17:26:23 -0700 (PDT)
Received: from ?IPv6:2001:569:7a71:1d00:dc82:ecce:ece5:5d02? (node-1w7jr9qrfoxxavly22j0q8vsy.ipv6.telus.net. [2001:569:7a71:1d00:dc82:ecce:ece5:5d02]) by smtp.gmail.com with ESMTPSA id t15sm3354487pfl.175.2020.09.11.17.26.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2020 17:26:22 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A42E4795-F7CD-4CA3-931C-1679E2802475
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 11 Sep 2020 17:26:22 -0700
Message-Id: <1D8182AD-BF23-460B-BFF4-90587FE97667@independentid.com>
References: <CAGUsYPzKO4f7gXdKdomMk7txUp91e-u=itfV0RoHeixpOSWzTA@mail.gmail.com>
Cc: scim@ietf.org
In-Reply-To: <CAGUsYPzKO4f7gXdKdomMk7txUp91e-u=itfV0RoHeixpOSWzTA@mail.gmail.com>
To: Shelley <randomshelley@gmail.com>
X-Mailer: iPhone Mail (17G80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Ncb3v3UlsOm14D8V6OD7BcdyV_g>
Subject: Re: [scim] Common Attribute "schemas" Characteristics
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 12 Sep 2020 00:26:27 -0000

AFAIK, Schemas has to always be returned so that parsers know the claims/contents of the json object.

I’d have to check but I think all common attributes are returned (eg schemas, id, meta).  

Phil

> On Sep 11, 2020, at 8:13 AM, Shelley <randomshelley@gmail.com> wrote:
> 
> 
> Regarding the "returned" characteristic for the "schemas" attribute... RFC 7644 includes examples with conflicting behavior for the "schemas" returned characteristic.
> 
> In section 3.4.2 [1], the example query which specifies "attributes" does not return the "schemas" by default:
> 
> GET /Users?attributes=userName
> {
>  "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
>  "totalResults":2,
>  "Resources":[
>    {
>      "id":"2819c223-7f76-453a-919d-413861904646",
>      "userName":"bjensen"
>    },
>    {
>      "id":"c75ad752-64ae-4823-840d-ffa80929976c",
>      "userName":"jsmith"
>    }
>  ]
> }
> 
> However, in section 3.9 [2], "schemas" is returned by default in the response, despite the "attributes" parameter not specifying this attribute:
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
> {
>  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
>  "id":"2819c223-7f76-453a-919d-413861904646",
>  "userName":"bjensen"
> }
> 
> RFC 7643 generally indicates throughout that "schemas" MUST be specified; however, it is not clear as to whether the requirement is referring to requests and/or responses. Unlike the "id" attribute, which clearly specifies that it is expected to have a returned characteristic of "always", the other common attributes don't clearly specify this characteristic. Is "default" the correct attribute, such that the example in RFC 7644 Section 3.9 is not correct?
> 
> [1] https://tools.ietf.org/html/rfc7644#section-3.4.2
> [2] https://tools.ietf.org/html/rfc7644#section-3.9
> 
>> On Fri, Mar 13, 2020 at 12:10 PM Phillip Hunt <phil.hunt@independentid.com> wrote:
>> Shelley
>> 
>> In practical/pragmatic terms...case insensitive. 
>> 
>> I treat as case insensitive since it is unlikely and unwise if two separate schemas only differentiated by case. 
>> 
>> I would also expect iana process to reject “overlapping” registrations differentiated only by case. 
>> 
>> Phil
>> 
>>>> On Mar 13, 2020, at 9:16 AM, Shelley <randomshelley@gmail.com> wrote:
>>>> 
>>> 
>>> What are the characteristics for the "schemas" [1] attribute?
>>> 
>>> Here is my attempt at defining these characteristics using the Schema definitions:
>>> "type" is "reference"
>>> "referenceTypes" is ["uri"]
>>> "required" is "true"
>>> "multiValued" is "true"
>>> "uniqueness" is "none"
>>> "caseExact" as "true" (since this is a "reference" type)
>>> "mutability" of "immutable" (although none of the mutability values seems like a perfect fit)
>>> "returned" characteristic of "default"
>>> Although "schemas" and the "Common Attributes" don't define their own schemas, it would be nice to have all of these attributes' characteristics clearly defined in the spec using the Schema definition to help provide a clear/common definition, particularly, since these characteristics are not intended to be modified/defined by SPs..
>>> 
>>> In particular, in my SCIM implementation, I have been considering whether to evaluate "schemas" in resource representations case-sensitively (exact case as defined in the ResourceType), case-insensitively (any case allowed), or using lexical equivalence (e.g. for URNs, case-insensitive schema and NID, case-sensitive NSS, and some components ignored). The RFC doesn't seem to clearly prescribe this, but based on the fact that the implied type is "reference" which (debatably [2]) has "caseExact" as "true" and the fact that the attribute "MUST only contain values defined as "schema" and "schemaExtensions"", I'm under the assumption that this attribute is case-sensitive.
>>> 
>>> Please confirm. Thanks!
>>> 
>>> [1] https://tools.ietf.org/html/rfc7643#section-3
>>> [2] https://mailarchive.ietf.org/arch/msg/scim/05_K_y-V26EOfN2F7fuSO3DXoLw/
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim