Re: [scim] Groups Member Type
Shelley <randomshelley@gmail.com> Wed, 09 August 2017 21:59 UTC
Return-Path: <randomshelley@gmail.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 56C7213228D for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 14:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZUWkhlT4MGG for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 14:59:33 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 223A4132195 for <scim@ietf.org>; Wed, 9 Aug 2017 14:59:33 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id w45so34027178uac.5 for <scim@ietf.org>; Wed, 09 Aug 2017 14:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=jBvU0fmtvdTj0xkgjCrscMGW9siJ5BeQHsu1Z6azwIi4z3av82hpWBZyP3+BT6pRGi cNpEscdHaLrDACEktGAOn71/WC9oAG9dMt56HHICZzbwl4eE3FBu0giwzr3xtnfJQ6C5 gk8IUdTVKGE+OgdGD20Q4cY4/f3buOiyN7appH0k/+KO58UlIsTTmPz+ItE3HCwV2I3b FXgf5IOPt8QFRKX7VBH9elrtU/NRT3aUGyzDmAEHUD5Rpy5VfrKyGw/E1KrpYI17Bjtl YU1foWsd8lguOHhnf4wrN6OW/dTTFBe4oMH2ivO2kFtFpDSYMOuPRAkw4N6pTYHzdbRy Co3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=OQjyhHIZGo8DMVHP5gRPZR+93cPhl0uOCk89JF5J8//1T1OUmIafWuR4e8QE3WZAdr ew7LDOD/C9HhQD3k0u4DHjg8aeo6aXX5CMhAF1AZ2PT7JJBeAZGtJ5hQEm+AWJnD2VnO YXxgzB6lwsbp21JIqXWGOt1JbQ37o1Tc+e1rgz2HbhVUYDeYTWp+lAoXxPLOIZPetRsE zb4zavf46fc1oISneQtEfQOBbfA/m3jrXlYusVaDY4UbnBXYp+hhmH66AX2FqKSnWCMJ ZDwtZV76/eTUBD/JSos7A4Ttn4JacB/Yg+18qKwuKuMG0zjWQjeaP4WMxR9dYKb5dRT3 exoA==
X-Gm-Message-State: AHYfb5hpb+cGmcAhumnRkLwatk/8foVYiQYV6g+BFhR5YfkNVUl8k+3o QwUFK7gYPG/2pn6MBXiLP1vy0Iqg5w==
X-Received: by 10.159.53.36 with SMTP id o33mr7212980uao.95.1502315972205; Wed, 09 Aug 2017 14:59:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 14:59:31 -0700 (PDT)
In-Reply-To: <CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0@CY1PR04MB2363.namprd04.prod.outlook.com>
References: <CAGUsYPz7_9Tat93aC2t=YAQcHG6dmboYDYij_8sRpKA6CZoWEA@mail.gmail.com> <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <CAGUsYPwUt997zV9sxC4p93Jz=9j+bWeqygyMSkssM1gMZfxhpQ@mail.gmail.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> <CAGUsYPyV7RjdmbUMcQ5N8NdwGjPzt2xHSANyNJon_uceNjhUgA@mail.gmail.com> <CAGUsYPzYh0zqpEedtAx2rwTKzPYRiURY3DTzJi8jyDUxrifUiw@mail.gmail.com> <CY1PR04MB2363D61AB4E1F0C5843904F5E28B0@CY1PR04MB2363.namprd04.prod.outlook.com> <BC21670B-1A93-430C-BBF7-0E1B5BE4B570@oracle.com> <CAGUsYPxTc-2Z0ifMNc2iY9xoyRXYLW46nrOtdJFw2VHUboXmcQ@mail.gmail.com> <CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0@CY1PR04MB2363.namprd04.prod.outlook.com>
From: Shelley <randomshelley@gmail.com>
Date: Wed, 09 Aug 2017 16:59:31 -0500
Message-ID: <CAGUsYPz+0DS9SZkzfPQFZaCeJU==AnGf4O2O-0h3UCCQZgvV-g@mail.gmail.com>
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c03ce80dd2006055659313e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/MDNLyLWWLd9BzOX5TETpw3ow8To>
Subject: Re: [scim] Groups Member Type
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, 09 Aug 2017 21:59:37 -0000
Thanks for the feedback. *Now that it is being used as directory, closing some unspecified / loose > areas might be better for interop IMO. * > Is it possible to fold some of these clarifications into the next SCIM RFC? On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote: > Your plan sounds good to me, Shelly. That’s how I would implement it. > > > > *From:* Shelley [mailto:randomshelley@gmail.com] > *Sent:* Wednesday, August 9, 2017 1:42 PM > *To:* Phil Hunt (IDM) <phil.hunt@oracle.com> > *Cc:* Kelly Grizzle <kelly.grizzle@sailpoint.com>; scim@ietf.org > > *Subject:* Re: [scim] Groups Member Type > > > > *You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). * > > > - Is the id now required to be globally unique across all resource > types? If not, there is no *guarantee *that an SP can determine the > resource type from the id. > - The $ref is also optional, so this cannot be consistently used to > determine the type. Further, I was under the impression that the $ref > is primarily used for SPs to communicate the resource location to > consumers, rather than vice versa (i.e. it's essentially a *read-only* > attribute). > > Here is my tentative plan for our SP implementation for evaluating *group > members*: > > - Treat *value* as *REQUIRED*. While the example SCIM schema > <https://tools.ietf.org/html/rfc7643#page-69> does not actually > require the group member value sub-attribute, this is the most > consistent identifier for referring to members. > - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when > processing requests). Using a $ref provided by consumers seems a bit > fragile (aside from eliminating the complexity of URI comparison, it's > possible that a single resource may have multiple DNS names, which further > complicates absolute URI comparisons and integrity), and introduces > redundancy (and potential ambiguity) with value/type. > - Treat *type *as *OPTIONAL*. My *preference *would be to treat this > as REQUIRED in order to eliminate any ambiguity, but given that the SCIM > specs don't require it, doing this would limit interoperability for > consumers that may not be sending it. > - If *type *is not provided, assume the *default value is **"User"*. > - Perform *referential integrity *to ensure that any provided group > member resources exist, based on value and type. > > *Examples* > > Given the existence of the following resources, here are some example > requests/responses based on this proposal: > > - ../Users/abc > - ../Groups/xyz > > > > *Group Members* > > *Response* > > "members": [ > > { > "value": "abc", > > "type": "User" > > }, > > { > > "value": "xyz", > > "type": "Group" > > } > > ] > > *2xx* - Success > > "members": [ > > { > > "value": "abc" > > }, > > { > > "value": "xyz", > > "type": "Group" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "$ref": "anything at all" > > }, > > { > > "value": "xyz", > > "type": "Group", > > "$ref": "anything at all" > > } > > ] > > "members": [ > > { > > "value": "xyz" > > } > > ] > > *400 *- Missing “Group” "type" on nested group member definition > > "members": [ > > { > > "value": "xyz" > > "$ref": "../Groups/xyz" > > } > > ] > > "members": [ > > { > > "$ref": "../Users/abc" > > } > > ] > > *400 *- Missing "value" on group member definition > > "members": [ > > { > > "$ref": "../Groups/xyz" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "type": "Group" > > } > > ] > > *400 *- Wrong "type" provided > > "members": [ > > { > > "value": "xyz", > > "type": "User" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "type": "UnsupportedType" > > } > > ] > > *400 *- Unsupported "type" provided > > "members": [ > > { > > "value": "no such resource with or without type" > > } > > ] > > *400 *- Member does not exist > > > > > > On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> > wrote: > > I agree the server can decide. > > > > IMO the server should check referential integrity. By doing so it would > likely know the type. The spec is silent (as far as i recall) on whether it > expresses it. > > > > You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). > > From my recollection some of these items were not that important given > scim was provisioning api for apps - apps implementing server side are free > to do what they can/want. Now that it is being used as directory, closing > some unspecified / loose areas might be better for interop IMO. > > > Phil > > > On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> > wrote: > > Given the general desire for SCIM to allow loose reading but strict > writing, I would vote for option 1. If type is not specified in a > PUT/POST/PATCH then the server can assume “User”. > > > > --Kelly > > > > *From:* Shelley [mailto:randomshelley@gmail.com <randomshelley@gmail.com>] > > *Sent:* Wednesday, August 9, 2017 9:02 AM > *To:* Kelly Grizzle <kelly.grizzle@sailpoint.com> > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > *Resurrecting this old thread, as this question has recently come up > during some of our interoperability testing, and there still appears to be > some ambiguity in the spec...* > > > The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected > behavior if the type sub-attribute is not provided on a Group resource > member. Neither spec seems to explicitly require this attribute, so what > is the expected behavior if no type is provided? Is there a default (e.g. > "User" or "Group"), must Service Providers search for the member across *all > *resource types, or should it be treated as REQUIRED (e.g. returning a 400 > error)? > > > > > > On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.com> wrote: > > Thanks, Kelly. Given that the ID may represent either a User or Group and > only the combination of "type" and "value" uniquely identify the reference, > should the canonical "type" attribute for group members be REQUIRED as > well? (Further, the majority of examples throughout the Protocol > specification only include a "value" and not "type", so it's ambiguous as > to whether these "values" represent Users or Groups.) > > > > On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > > I opened ticket #35 to change this. > > > > http://trac.tools.ietf.org/wg/scim/trac/ticket/35 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_scim_trac_ticket_35&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=azLSrYlOBRiSWZ3BiA7nEnSujz0OPCep2bx8PeAdobE&e=> > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Monday, February 11, 2013 11:36 AM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > +1 to mark it as "immutable". > > On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> > wrote: > > Good point. It seems like this should say “immutable” rather than > “read-only”, since it can be set initially but not updated. Thoughts from > anyone else? If this seems reasonable I’ll open an issue to get this fixed. > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Friday, February 01, 2013 1:37 PM > *To:* scim@ietf.org > *Subject:* [scim] Groups Member Type > > > > As indicated in Section 8, the canonical types for Group members are > READ-ONLY. As such, how can consumers provide the type (i.e. "User" or > "Group")? Is it implied that IDs are unique across both users and groups in > order for service providers to fulfill this requirement? > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y > TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m= > nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_ > ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e= > > >
- [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Kelly Grizzle
- Re: [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Kelly Grizzle
- Re: [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Kelly Grizzle
- Re: [scim] Groups Member Type Phil Hunt (IDM)
- Re: [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Phil Hunt (IDM)
- Re: [scim] Groups Member Type Kelly Grizzle
- Re: [scim] Groups Member Type Shelley
- Re: [scim] Groups Member Type Phil Hunt (IDM)