RFC 3622

A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project

📅 published February 2004, from ietf

RFC 3622 💖 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project

Okay bestie, this is RFC 3622 🦋 Written by Michael Mealling at VeriSign, Inc. in February 2004. It's filed as Informational, which means it's sharing info and not setting an Internet standard. The header doesn't list any Obsoletes or Updates, so it isn't replacing or changing any other RFC 🌸

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 💜

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

1. Introduction 🌈

The Liberty Architecture is all about federated network identity that enhances security, privacy and trust 🔥 The goal is a networked world where people and businesses can do pretty much any transaction without giving up the privacy and security of their vital identity info. Iconic, honestly 👑

Liberty uses XML [5] as a core piece, specifically XML Schema [7] and Namespaces [6]. These pieces need identifiers that will outlive the organization that made them, so a URN namespace for them that follows the assumptions and policies of the Liberty specification is required 💅

This namespace spec is for a formal namespace ✨

2. Specification Template 🧚

Namespace ID

  • "liberty" requested.

Registration Information

  • Registration Version Number: 1
  • Registration Date: 2003-04-01

Declared registrant of the namespace

Liberty Alliance Project
c/o IEEE-ISTO
445 Hoes Lane
Piscataway, NJ 08855-1331, USA
info@projectliberty.org

Declaration of structure

Okay so the Namespace Specific Strings (NSS) of all URNs assigned by Liberty will conform to the syntax defined in section 2.2 of RFC 2141 [1]. On top of that, every Liberty URN NSS is a left-to-right series of tokens separated by colons. That sequence of colon-separated tokens lines up with going down the nodes of a tree 🌳 To the right of the lowest naming authority node, there may be zero, one or more levels of hierarchical (although not in the RFC 2396 [2] sense of 'hierarchy') naming nodes, ending in a rightmost leaf node. Check the section called "Identifier assignment" below for more on what NSSs mean. This syntax is captured in the following normative ABNF [4] rules for Liberty NSSs:

Liberty-NSS        =   1*(subStChar) 0*(":" 1*(subStChar))
subStChar       =   trans / "%" HEXDIG HEXDIG
trans           =   ALPHA / DIGIT / other / reserved
other           =   "(" / ")" / "+" / "," / "-" / "." /
                    "=" / "@" / ";" / "$" /
                    "_" / "!" / "*" / "'"
reserved        =   "%" / "/" / "?" / "#"

Leaving the colon out of the "other" characters means the colon can only show up as a delimiter between string tokens 🎀 This ABNF guarantees that any valid Liberty NSS is also a valid RFC 2141 NSS, which is so clean 🙌

For example:

urn:liberty:schemas:authctx:2002:05
urn:liberty:schemas:core:2002:12

Relevant ancillary documentation

  • Liberty Architecture Overview [3]
  • Version 1.1
  • Liberty Alliance Project
  • January 15, 2003

Identifier uniqueness considerations

Liberty assigns identifiers within its various standards. When a spec gets published, all the newly minted names get checked against the record of names that were already assigned 🔍

Identifier persistence considerations

The assignment process makes sure names are never reassigned, and that the binding between a name and its resource is permanent, no matter what happens with standards or organizational changes. Permanent, iykyk 💖

Process of identifier assignment

Names are assigned by the Liberty standards publication process.

Process of identifier resolution

At this time no resolution mechanism is specified.

Rules for Lexical Equivalence

Two Liberty namespace specific strings (NSSs) are lexically equivalent if they're an exact, case-sensitive string match. The Liberty Alliance assigns names of immediately subordinate naming authorities case-insensitively, so there won't be two Liberty-subordinate naming authorities whose names differ only in case 🫶

Conformance with URN Syntax

There are no additional characters reserved.

Validation mechanism

None other than verifying with the correct Liberty specifications.

Scope

Global

3. IANA Considerations 📋

This document includes a URN Namespace registration that has been entered into the IANA registry for URN NIDs.

4. Community Considerations 🌸

There's no resolution mechanism for this namespace, but the names themselves are used in public implementations of the Liberty specifications. Sometimes Liberty objects end up exposed to the general Internet, and in those cases the Liberty namespace gives general interoperability benefits to the Internet at large ✨ Some Liberty subcomponents might also get adopted by other standards, and then the URNs that identify those components and specs can easily help other, non-Liberty systems too 🦋

5. Security Considerations ⚠️

Since there is no defined resolution mechanism for Liberty URNs, it is difficult to authenticate the fact that a given namespace actually adheres to the standard. Applications should be careful not to take some unverified source's assertion that what it is sending adheres to what the actual URN is assigned to. Bestie, this is serious 🙈

6. References 📚

6.1. Normative References

6.2. Informative References

  • [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
  • [6] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
  • [7] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.

7. Intellectual Property Statement 🔐

The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights might be available. It also doesn't say it has tried to find any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents can be found in BCP-11. Copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights, can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practice this standard. Send that info to the IETF Executive Director 📮

8. Author's Address 🎀

Michael Mealling
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166
USA

Phone: +1 678 581 9656
EMail: michael@neonym.net
URI:   http://www.verisignlabs.com

Copyright (C) The Internet Society (2004). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💖

📦 where this page comes from