Re: [scim] [EXTERNAL] Clarification on SCIM schema extension URN naming rules

Phillip Hunt <phil.hunt@independentid.com> Tue, 04 October 2022 22:08 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 2D093C14CE2B for <scim@ietfa.amsl.com>; Tue, 4 Oct 2022 15:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.803
X-Spam-Level:
X-Spam-Status: No, score=-6.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoCA3n0CCnbc for <scim@ietfa.amsl.com>; Tue, 4 Oct 2022 15:08:41 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4D7C14F73B for <scim@ietf.org>; Tue, 4 Oct 2022 15:08:41 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id l1so1004608pld.13 for <scim@ietf.org>; Tue, 04 Oct 2022 15:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=PE9Noy+HeAsOvP25BnAxESTVFI+3dnjN4FuWE1QBAzY=; b=wxcNlVzrApjxln/uW7SHwZShjajM75u/01e79nfV1culnZUU4d/ywk5w5NHH+BUPIo zgt5cgDajwWdObN9rFshYKwpshaOveemyg3HuDhh9UUfb7N9SO+alpFJas9Y+PozQnu1 TvuWefjL+bbNU+e9cbWXNfOVzJYWA5bIxa04vQxAPgEq54lQ052rmUu8X9UEgbVogihu vTbLmoBaFYr3gk4s7k7v33VC0twUvwdAM8SNzV4L94C/YpxC5GE+4RnZbo2SG0QgN47p PwKBxQXOrX3eIVUzL5HF6y5xZ5y0tmDfx+A+GolWuyTw3Fm4ndtcCarf5zyAkIJOlJCb rOQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=PE9Noy+HeAsOvP25BnAxESTVFI+3dnjN4FuWE1QBAzY=; b=FARIBxf/1PEBS09DE/ih2rm68hp94lohY4X/KWZyxv1PQtYnJoyyOR+HbWQjRKFCQh yUgqNOkwz1y/te91cFC+2pBv2z56IMfy0a6TV+lk/nRze7M34I7j2inpvHZ0X8Zh4t4F UFXnpmy3tRJhzNs427mx6P33kbmBQ6/h2XzlGmbIeomYpo4L07SBaRrqw6tuJCbWOpD7 V0ZV8I1yUAkD70T3Y5csQSaXhmgxZ2w6rNl8OSdaU59mmd8qmRWEvWMyGkd0miUBYBtA KHJgJCoUzYxmBKpejFcTkpYhS+ofgt+HJyzfLtKJS2f5FTla1Z3ak0QIhMUyyxsV1HnM 5LPQ==
X-Gm-Message-State: ACrzQf0/gRsOS+F/N8Z5svajtUpB80MeTxgxSzFvl60uuXlRusL7YZk2 u4qYb0EB6R7dqkuekoB+SxQ65Xcd0HqEaeSp
X-Google-Smtp-Source: AMsMyM5jQ4GurHyyBQehH9YQ063KQkYHXXaVgpi3/9/O6EHINtPwxqYn42gYvAeHrbH2ukhRpz4DPg==
X-Received: by 2002:a17:90b:3b47:b0:202:a81f:4059 with SMTP id ot7-20020a17090b3b4700b00202a81f4059mr1839076pjb.150.1664921319664; Tue, 04 Oct 2022 15:08:39 -0700 (PDT)
Received: from smtpclient.apple (d207-6-202-204.bchsia.telus.net. [207.6.202.204]) by smtp.gmail.com with ESMTPSA id y67-20020a623246000000b00545f5046372sm9679489pfy.208.2022.10.04.15.08.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2022 15:08:39 -0700 (PDT)
From: Phillip Hunt <phil.hunt@independentid.com>
Message-Id: <15BBCB8E-E47E-46CF-AEC7-21F4AFC02E06@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4155FE24-DCC9-419A-A762-D66D7EA6D283"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 04 Oct 2022 15:08:37 -0700
In-Reply-To: <MN2PR00MB071839A6E8C7E307CDF974DEFF5A9@MN2PR00MB0718.namprd00.prod.outlook.com>
Cc: Brian Demers <brian.demers@gmail.com>, SCIM WG <scim@ietf.org>, Stanimir Bozhilov <stanimir@audriga.com>
To: Danny Zollner <Danny.Zollner@microsoft.com>
References: <3250F090-BCCB-4999-9D90-4D428D3100B6@gmail.com> <3E25E547-C68D-45A1-8C51-B4676B7164B8@independentid.com> <CAH9eYVpfLofyHUu1iT=sxg2vXpKnzfLj-1W5RxKHxFUPJ3pdgg@mail.gmail.com> <0F316F63-F163-431F-8C3B-65D996D09DBB@independentid.com> <MN2PR00MB071839A6E8C7E307CDF974DEFF5A9@MN2PR00MB0718.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/jfYz7cCO7u_72oIwHnfZ423KsRk>
Subject: Re: [scim] [EXTERNAL] Clarification on SCIM schema extension URN naming rules
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 04 Oct 2022 22:08:46 -0000

I think people may be over-thinking this.  URNs are a namespace managed by IANA and are not specific to SCIM.  

URNs are just a namespce (like domains in reverse with colons).  :-)

Anything related to SCIM that is to appear in the SCIM “registry” must start:

urn:ietf:params:scim: …

This link describes the urn:ietf:params namespace: 
https://www.iana.org/assignments/params/params.xml#params-1


Only the URN urn:ietf:params:scim:{type}:core:{…} is reserved for the SCIM WG itself.

Other “name” values are wide-open for anyone to apply per the process described for the SCIM registry (which ends up being first come first served like DNS).

For example, for a hypothetical SCIM schema for an Azure azure account, you *could* register under a namespace:
urn:ietf:params:scim:msazure:account.  

The WG might also choose to establish a new name for stuff it deems not really “core”.  For example the “hr” participants might want to define a name “scimhr” or “hr”. 

SCIM itself has no enforcement mechanism. The IANA registry is intended to avoid naming conflicts and to enable lookups.  For example you can click this link to look at registered SCIM schemas:

* https://www.iana.org/assignments/scim/scim.xhtml

Note: currently there are no third-party schemas registered. But the process is there to do so.

Phillip Hunt
@independentid
phil.hunt@independentid.com




> On Oct 4, 2022, at 2:31 PM, Danny Zollner <Danny.Zollner@microsoft.com> wrote:
> 
> As of the last time I attempted to look this up, the only SCIM IANA registrations that exist are the ones defined in the SCIM 2.0 RFCs (7643/44). Registration with IANA is fairly clear, but for unregistered use it isn’t. Phil, you’re saying that anyone, without registering with IANA, can freely use urn:ietf:params:scim:schemas:… for a schema URN without breaking any rules? If so, I believe that answers all of my original questions, and at best adds some minor to-do item for clarification on this in a future update.
>  
> Thanks,
>  
> Danny Zollner (He/Him)
> 
> From: Phillip Hunt <phil.hunt@independentid.com> 
> Sent: Tuesday, October 4, 2022 4:26 PM
> To: Brian Demers <brian.demers@gmail.com>
> Cc: SCIM WG <scim@ietf.org>; Danny Zollner <Danny.Zollner@microsoft.com>; Stanimir Bozhilov <stanimir@audriga.com>
> Subject: [EXTERNAL] Re: [scim] Clarification on SCIM schema extension URN naming rules
>  
> Section 10.2.1 of RFC7643 describes the structure:
>  
>  urn:ietf:params:scim:{type}:{name}{:other}
>  
>       The keywords have the following meaning:
>  
>       type
>          The entity type, which is either "schemas" or "api".
>  
>       name
>          A required US-ASCII string that conforms to the URN syntax
>          requirements (see [RFC2141 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc2141&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784609810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EEnHr6F3Ci9sQTZSdByVrgob%2F33UugbLoUxiZqZfSrQ%3D&reserved=0>]) and defines a major namespace of a
>          schema used within SCIM (e.g., "core", which is reserved for
>          SCIM specifications).  The value MAY also be an industry name
>          or organization name.
>  
>       other
>          Any US-ASCII string that conforms to the URN syntax
>          requirements (see [RFC2141 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc2141&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784609810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EEnHr6F3Ci9sQTZSdByVrgob%2F33UugbLoUxiZqZfSrQ%3D&reserved=0>]) and defines the sub-namespace
>          (which MAY be further broken down in namespaces delimited by
>          colons) as needed to uniquely identify a schema.
>  
> So this process is about managing the URN namespace and avoiding conflicts. IANA is in charge of this.
>  
> Any URI starting urn:ietf:params:scim is in the SCIM namespace. The next level “type” is used to dsitinguish between protocol schemas (eg.”api") vs. resource schemas (“schemas”).  For example “api” is used to describe the JSON schemas for a SCIM PATCH request, a SCIM SEARCH request via (POST), and List Response.
>  
> The next level is the “name” which can be any major name you want (like a company).  “core” is the one that indicates a SCIM WG specification.
>  
> So as an example a third party (e.g.  “hralliance”) might want to publish there own specification and register with IANA per the process described. They might choose a namespace like:
>  
> urn:ietf:params:scim:schemas:hralliance:employee
>  
> Section 10.3 describes how to do formal registration. The main reason for registration is to:
> a) reserve a URN namespace for schemas
> b) advertise the availability of the specification to others.
>  
> This is not unlike how IANA is used to register mime types (e.g. application/scim+json).
>  
> Phillip Hunt
> @independentid
> phil.hunt@independentid.com <mailto:phil.hunt@independentid.com>
>  
>  
> 
> 
> 
> On Oct 4, 2022, at 2:09 PM, Brian Demers <brian.demers@gmail.com <mailto:brian.demers@gmail.com>> wrote:
>  
> Sorry, my last message wasn't clear.
>  
> This line:
> > The spec states the URN prefix for the IANA registered schema.
> probably should have read:
> > RFC7643 states the URN prefix for the IANA registered schema.
> 
> Because of this, I'm assuming URN's starting with the prefix `urn:ietf:params:scim:` _should_ be avoided unless the schema is being developed through or reviewed by the working group (per 10.3.1)?
> 
>  
> On Tue, Oct 4, 2022 at 10:24 AM Phillip Hunt <phil.hunt@independentid.com <mailto:phil.hunt@independentid.com>> wrote:
> I would take a look at the IANA section of RFC7643. It details the namespace and registration process for SCIM urns. 
> 
> Phil
> 
> > On Oct 4, 2022, at 7:33 AM, Brian Demers <brian.demers@gmail.com <mailto:brian.demers@gmail.com>> wrote:
> > 
> > Same question here!
> > 
> > I gave a SCIM talk yesterday, and Iglossed over this topic, because it was not clear to me.
> > The spec states the URN prefix for the IANA registered schema.
> > But that may suggest that non-registered schema should avoid that prefix? 🤷
> > 
> > -Brian
> > 
> >>> On Oct 4, 2022, at 9:13 AM, Stanimir Bozhilov <stanimir@audriga.com <mailto:stanimir@audriga.com>> wrote:
> >>> 
> >>> On 2022-09-30 07:37, Danny Zollner wrote:
> >>> Hi SCIM-ers,
> >>> In RFC 7643, as best I can tell, all of the examples of schemas for
> >>> SCIM resources begin with the prefix of
> >>> urn:ietf:params:scim:schemas:…, with the sole exception of the text
> >>> on page 29 that refers to the schema for the ResourceType resource.
> >>> This text describing the schema for the ResourceType resource contains
> >>> the following:
> >>> schemaExtensions
> >>>     A list of URIs of the resource type's schema extensions.
> >>>     OPTIONAL.
> >>>     schema  The URI of an extended schema, e.g.,
> >>> "urn:edu:2.0:Staff".
> >>>        This MUST be equal to the "id" attribute of a "Schema"
> >>>        resource.  REQUIRED.
> >>> This example uses urn:edu:2.0:Staff as the example for an extension
> >>> schema, but all other examples of schemas in RFC 7643 that I could
> >>> find use the ietf namespace. In a discussion I was having with a
> >>> colleague of mine a few months ago, it was stated that the only schema
> >>> URNs that should be using the urn:ietf:.. namespace are ones contained
> >>> in IETF-managed drafts or RFCs. I've worked with dozens of SCIM
> >>> service provider implementers in the past few years, and possibly
> >>> without exception all implementers that have custom schema extensions
> >>> do something equivalent to
> >>> urn:ietf:params:scim:schemas:extension:CompanyName:2.0:User.
> >>> I'd like to get input from others in the working group - is it correct
> >>> that for non-IETF managed schemas - such as those that are custom to a
> >>> single SCIM implementation - that a schema extension URN should not
> >>> begin with urn:ietf:… but instead virtually anything else - i.e.:
> >>> urn:foo:bar, or the example above of urn:edu:2.0:Staff?
> >>> If it is the case, then I've got the following questions:
> >>>   * Does improper schema URN naming(improper usage of urn:ietf:.. )
> >>> have any negative impact?
> >>>   * For future guidance on this topic as part of the SCIM 2.0 standard,
> >>> should any consideration be given to the fact that the overwhelming
> >>> majority of SCIM 2.0 implementers have implemented their extensions
> >>> starting with urn:ietf:..?
> >>>   * If a future version increase of SCIM happens - 2.1, 3.0, etc -
> >>> should clearer guidance on proper versus improper schema URN naming be
> >>> given, including explicit guidance that urn:ietf:… is reserved?
> >>> Thanks,
> >>> Danny Zollner
> >>> _______________________________________________
> >>> scim mailing list
> >>> scim@ietf.org <mailto:scim@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/scim <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784609810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S8mZ%2F0cu0fhToMAgJtiGdVUeMcC8%2F33YdRcS2KVCqy4%3D&reserved=0>
> >> 
> >> 
> >> Hi Danny,
> >> 
> >> We're currently facing the same issue where it's not completely clear how one is supposed to define the URN of new resources or extensions in SCIM.
> >> 
> >> For the time being, we took the approach where we have the "urn:ietf:..." prefix and at the end of the URN we have "CompanyName:2.0:SomeResourceType". However, we weren't really sure whether this was actually proper naming and so we could easily change the URN naming in case it turns out that this is not the right way to go about naming new resources and/or schema extensions.
> >> Regarding this matter, we'd also be particularly interested in feedback and official guidance on how such naming should be done in general.
> >> 
> >> Best regards,
> >> Stanimir Bozhilov
> >> 
> >> -- 
> >> Stanimir Bozhilov
> >> Tel: +49 721 170293 16
> >> Fax: +49 721 170293 179
> >> 
> >> http://www.audriga.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.audriga.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784766021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LgRO6%2FiIcWSWo8EZDxjV2hb%2BHfJmS%2FpDffEQMmjgwtA%3D&reserved=0> | http://www.twitter.com/audriga <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Faudriga&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784766021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vgSUJ094o2Aj%2FVF0paV%2BAzNfAF7hjYjVaEdM4C1ex%2BU%3D&reserved=0>
> >> 
> >> --------------------------------------------------------------------------
> >> audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
> >> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> >> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
> >> --------------------------------------------------------------------------
> >> 
> >> _______________________________________________
> >> scim mailing list
> >> scim@ietf.org <mailto:scim@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/scim <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784766021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pyHNXHr9CNBGOkWQyCAmCgRcIj1EOoYWnBJtrZtDrRE%3D&reserved=0>
> > 
> > _______________________________________________
> > scim mailing list
> > scim@ietf.org <mailto:scim@ietf.org>
> > https://www.ietf.org/mailman/listinfo/scim <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C34be65f95ea848137f1908daa64f1107%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005155784766021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pyHNXHr9CNBGOkWQyCAmCgRcIj1EOoYWnBJtrZtDrRE%3D&reserved=0>