Re: [scim] Groups Member Type
Shelley <randomshelley@gmail.com> Wed, 09 August 2017 14:02 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 798001321D2 for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 07:02:04 -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 VFxQLYWynb3w for <scim@ietfa.amsl.com>; Wed, 9 Aug 2017 07:02:02 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 D4A6A132360 for <scim@ietf.org>; Wed, 9 Aug 2017 07:01:43 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id q25so28866478uah.1 for <scim@ietf.org>; Wed, 09 Aug 2017 07:01:43 -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=sm+xzpaGbGt+56ZgchYbKtjQycRwuVdStAno/nhsN6g=; b=sgsOvKfWnanW9XzREwNCeVeZgCAXchPos4xiWtek41iwxGrb7ZUufpoguayABfd0hM bWv2K+TApLFihBxXh8ZYNXNDChD+jVj/+q7NzupgFMApvZnircMXRdyonW8L4LwZ/H78 QJOc++Lr94toHtfpzJfNYu1FMKWFPm3DvAhi9bzx3F92yLoCsEKPKcITdVEITHsQFpI0 dmaAJGzPiySdPL+h6fo2o0PfdD8V7FMJWkpN74CIJ5H+Y8WZnWPp3BEdHxoVykPfjtjp Brx0n41dHrVmJp20hCm/8Cy2NwUBHhSYRyON7es6rDMop0eN7NP+uQ7CkBb+RGk63xx4 L1CQ==
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=sm+xzpaGbGt+56ZgchYbKtjQycRwuVdStAno/nhsN6g=; b=EkznxTPwigKuhM3sQLdGUJw1r2vZ4relCTDbVZ+BG0ct5arXW/MZsJvrL8IFOrvxTV CLKKwFfLYBlxlDO2MkNUL0Ngy2h6taNMa0a6OaRCb2GRuxahyksftrnKLxRM1Ual1hDS V/FwNsB53F0+xncSfLe1roUU/uyh8m6zP6vX2jgbHu5sBxrazNoAnTeBV5zv9ddP43Qk CWzupPpk5m0KQxC/VRP8ZMeFA1z+M6woG4bayfh0g4EvfmhjhxkdaIJQheNGRR/sXOul nCwaga6UuF7YzNtS0h8quRlHJ4fBNGWaUtk9ZMSG/1Y590fAaTfEyV7EutEwmgsy8+qT +EHw==
X-Gm-Message-State: AHYfb5iXqm+rIfLQ/ugjxBI0pRr0FvBCLfV2zxZ1QVr7frUv8DM2nxjz HMOfCEVN3rmVClhUZfNoyo93UNvoOQ==
X-Received: by 10.176.88.66 with SMTP id p2mr5938346uac.181.1502287302804; Wed, 09 Aug 2017 07:01:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 07:01:42 -0700 (PDT)
In-Reply-To: <CAGUsYPyV7RjdmbUMcQ5N8NdwGjPzt2xHSANyNJon_uceNjhUgA@mail.gmail.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>
From: Shelley <randomshelley@gmail.com>
Date: Wed, 09 Aug 2017 09:01:42 -0500
Message-ID: <CAGUsYPzYh0zqpEedtAx2rwTKzPYRiURY3DTzJi8jyDUxrifUiw@mail.gmail.com>
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f38f208c842055652856a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Mari_DUB7IPrw1bUKXtQoTC0NQU>
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 14:02:04 -0000
*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 >> >> >> >> --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] 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)