A URN Namespace for Globus
A namespace for Globus to give persistent names to its resources.
Martin, S., Tuecke, S., McCollam, B., and M. Lidman, "A URN Namespace for Globus", RFC 7853, DOI 10.17487/RFC7853, May 2016, <https://www.rfc-editor.org/info/rfc7853>.
@misc{rfc7853,
series = {Request for Comments},
number = 7853,
howpublished = {RFC 7853},
publisher = {RFC Editor},
doi = {10.17487/RFC7853},
url = {https://www.rfc-editor.org/info/rfc7853},
author = {S. Martin and S. Tuecke and B. McCollam and M. Lidman},
title = {{A URN Namespace for Globus}},
pagetotal = 7,
year = 2016,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Martin
Request for Comments: 7853 S. Tuecke
Category: Informational B. McCollam
ISSN: 2070-1721 M. Lidman
University of Chicago
May 2016
A URN Namespace for Globus
Abstract
This document describes a URN (Uniform Resource Name) namespace to be
used by Globus for naming persistent resources.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7853.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction .................................................. 2
2. Specification Template ........................................ 3
3. Examples (Informative) ........................................ 5
4. Namespace Considerations ...................................... 5
5. Community Considerations ...................................... 6
6. Security Considerations ....................................... 6
7. IANA Considerations ........................................... 6
8. Normative References .......................................... 6
Acknowledgments .................................................. 7
Authors' Addresses ............................................... 7
1. Introduction
Globus (https://www.globus.org) is a software-as-a-service provider
that develops and operates services and tools for the global research
and education community.
Globus provides multiple services for users across many institutions,
primarily for research driven by high-performance computing. Globus
creates unique identifiers that will persist in external systems and
must be identifiable as references to Globus entities.
To address this need, this document requests that a formal URN space
type be assigned as described in Section 4.3 of [RFC3406].
2. Specification Template
Namespace ID:
globus
Registration Information:
Version 1
Date: 2016-03-18
Declared Registrant of the Namespace:
Globus Project Lead
401 N Michigan Ave
Suite 900
Chicago, Illinois 60611
USA
Email: tuecke@globus.org
The position of Globus Project Lead is currently filled by Steve
Tuecke.
Declaration of Syntactic Structure:
The Namespace Specific String (NSS) of all URNs that use the
"globus" NID shall have the following structure:
<URN> ::= "urn:" "globus" ":" <NSS>
<NSS> ::= <SNID> | <SNID> ":" <subnamespace-specific-string>
<SNID> ::= 1*<non-colon-chars>
<subnamespace-specific-string> ::= 1*<URN chars>
<non-colon-chars> ::= <non-colon-trans> | "%" <hex> <hex>
<non-colon-trans> ::= <upper> | <lower> | <number> |
<non-colon-other>
<non-colon-other> ::= "(" | ")" | "+" | "," | "-" | "." | "=" |
"@" | ";" | "$" | "_" | "!" | "*" | "'"
The "SNID" is the top-level segment of the NSS. It is a required
US-ASCII string, subject to the above syntax, that conforms to the
URN syntax requirements (see [RFC2141]). It identifies a category
of Globus entities, often associated with a particular Globus
service. For example "auth" could be used as an SNID for
identifiers generated by the Globus authentication and
authorization service (Globus Auth).
The "subnamespace-specific-string" is an optional US-ASCII string
and second-level segment of the NSS, belonging to the "SNID"
context, subject to the above syntax and conformant to the URN
syntax requirements (see [RFC2141]). "subnamespace-specific-
string" identifies a category of thing within that Globus service,
such as "scope:transfer.api.globus.org:all"
Relevant Ancillary Documentation:
None.
Identifier Uniqueness Considerations:
Identifier uniqueness will be enforced by the Globus Project Lead.
The Globus Project Lead may sub-delegate part of the namespace to
third parties. It will not be permissible, neither by the Globus
Project Lead nor any third party, to reassign previously assigned
URNs. A practical consequence is that a previously assigned
subnamespace cannot be reassigned, unless additional arrangements
are made to prevent identifier reassignments.
Identifier Persistence Considerations:
Identifiers will never be reassigned, but in some circumstances
they may be invalidated by the Globus Project Lead or by a third
party.
Process of Identifier Assignment:
Assignment of subnamespace identifiers is limited to the Globus
Project Lead and those authorities that are specifically
designated by the Globus Project Lead. The Globus Project Lead
may assign portions of the globus namespace (specifically, those
under designated subnamespace identifiers) for assignment by third
parties.
Process of Identifier Resolution:
None currently.
Future versions of this document may define resources that can be
used to resolve Globus identifiers.
Rules for Lexical Equivalence:
No additional rules beyond those specified in RFC 2141.
Conformance with URN Syntax:
No special considerations.
Validation Mechanism:
None currently.
Future versions of this document may define resources that can be
used to validate Globus identifiers.
Scope:
Global.
3. Examples (Informative)
The following examples are based on plans for the Globus URN. They
are therefore not guaranteed to be valid.
The Globus Auth service defines the "auth" SNID and contains the
following URNs:
o urn:globus:auth:scope:transfer.api.globus.org:all
o urn:globus:auth:grants:dependent_token
A hypothetical service, the Globus Groups service, would have a
distinct SNID. If that SNID were "groups", it might have URNs such
as the following:
o urn:globus:groups:group:669b572e-9de4-11e5-966e-3c970e0c9cc4
o urn:globus:groups:memberships:72e1c6c6-9de4-11e5-966e-3c970e0c9cc4
4. Namespace Considerations
The current set of existing IANA namespaces are insufficient because
Globus will be creating unique identifiers that will persist in the
external system; these identifiers must be identifiable as references
to Globus entities.
The use of the Globus namespace is expected to be broad, including
but not limited to usage for:
o OAuth2 scopes (see [RFC6749])
o OAuth2 custom extension grants
o Entity identification for Globus Services
5. Community Considerations
Members of the Globus community will benefit from persistent and
globally unique identifiers for use in software and in conformance
with protocols developed and used by Globus and third-party
collaborators.
6. Security Considerations
There are no special meanings for characters in the NSS. Thus, there
are no additional security considerations other than those normally
associated with the use and resolution of URNs in general, which are
described in [RFC1737] and [RFC2141].
7. IANA Considerations
IANA has registered the "globus" namespace identifier (NID) in the
"Formal URN Namespaces" registry located at
<http://www.iana.org/assignments/urn-namespaces>.
8. Normative References
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737,
December 1994, <http://www.rfc-editor.org/info/rfc1737>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406,
October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>.
Acknowledgments
The authors would like to thank Stephen Rosen and Vas Vasiliadis for
proofreading this document and providing valuable feedback.
Authors' Addresses
Stuart Martin
University of Chicago
401 N Michigan Ave
Suite 900
Chicago, Illinois 60611
United States
Email: sjmartin@uchicago.edu
Steve Tuecke
University of Chicago
401 N Michigan Ave
Suite 900
Chicago, Illinois 60611
United States
Email: tuecke@globus.org
Brendan McCollam
University of Chicago
401 N Michigan Ave
Suite 900
Chicago, Illinois 60611
United States
Email: bmccollam@uchicago.edu
Mattias Lidman
University of Chicago
401 N Michigan Ave
Suite 900
Chicago, Illinois 60611
United States
Email: mattias@uchicago.edu
AI ELI5
On this page
§1Globus and Persistent Identifiers
Globus is a software-as-a-service provider that develops tools for the global research and education community, especially those using high-performance computing. As Globus operates multiple services for users across many institutions, it creates unique identifiers for resources that must persist and be identifiable as belonging to Globus. For example, when other systems reference a Globus entity, they need a way to be sure the identifier will not be reused for a different thing later.
Existing public naming systems (like the general IANA URN namespaces) were not sufficient, because Globus needed its own namespace to guarantee persistence and clarity.
Globus runs systems that create long-lasting names for things. It needed a system where those names would stay the same forever and everyone would know they came from Globus.
§2The Globus URN Structure
A URN (Uniform Resource Name) is a persistent, location-independent name for a resource. The RFC defines how Globus URNs are structured: they start with the prefix urn:globus: followed by two parts. The first part is called the SNID (Subnamespace ID), a required category identifier like auth for authentication or groups for a groups service. The second part is optional and can contain more specific details, such as scope:transfer.api.globus.org:all.
This two-level hierarchy allows Globus to delegate parts of the namespace to different services while keeping the overall structure consistent. For instance, the Globus Auth service controls everything under urn:globus:auth:, while the Groups service could manage urn:globus:groups:.
Globus URNs follow a pattern: urn:globus:[service]:[details]. Each Globus service gets its own area (like 'auth' or 'groups'), and then can create as many specific names as it needs under that area.
§3Example Globus URNs
The RFC provides concrete examples showing how Globus services use the namespace. The Globus Auth service creates URNs for OAuth2 scopes and authorization grants, such as urn:globus:auth:scope:transfer.api.globus.org:all (a scope for the transfer API) and urn:globus:auth:grants:dependent_token (a type of authorization grant). A hypothetical Globus Groups service might create identifiers like urn:globus:groups:group:669b572e-9de4-11e5-966e-3c970e0c9cc4 for individual groups and urn:globus:groups:memberships:72e1c6c6-9de4-11e5-966e-3c970e0c9cc4 for membership records.
A Globus Auth URN might name a permission: 'use the transfer API'. A Globus Groups URN might name a specific group or list of members.
§4Persistence and Governance
Once a URN is assigned, it can never be reassigned to a different resource, ensuring that any system relying on that identifier will always resolve to the same thing. The Globus Project Lead is responsible for enforcing this and managing the namespace. Globus can delegate authority over sub-parts of the namespace (specific SNIDs or subnamespace branches) to third parties, allowing partner services or organizations to safely create their own identifiers within Globus's overall structure.
Currently, there is no resolution mechanism defined (no way to look up what a URN refers to), but the RFC notes that future versions may define such resources for resolving and validating Globus identifiers.
Once a Globus name is assigned, it is locked in forever. Globus can let other organizations use parts of the namespace, and they are responsible for their own names.
§5Security and IANA Registration
The RFC notes that Globus URNs have no special character meanings or encoding tricks, so there are no additional security considerations beyond those of URNs in general. There are no restrictions on the characters in the namespace-specific string beyond the standard URN syntax rules. IANA has registered globus as a formal URN namespace identifier, meaning it is officially recognized in the global registry of URN namespaces.
Globus URNs are straightforward and follow standard naming rules. IANA keeps an official list of URN namespaces, and 'globus' is now on it.