Network Working Group M. Mealling
Request for Comments: 3622 VeriSign, Inc.
Category: Informational February 2004
A Uniform Resource Name (URN) Namespace for
the Liberty Alliance Project
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 Notice
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 seeks to provide federated network identity
in such a way that enhances security, privacy and trust; thus
creating a networked world across which individuals and businesses
can engage in virtually any transaction without compromising the
privacy and security of vital identity information.
One fundamental component of this architecture is its use of XML [5],
and specifically, XML Schema [7] and Namespaces [6]. These
components require identifiers that will live far beyond the lifetime
of the organization that produced them. As such, a URN namespace for
those components that adheres to the assumptions and policies of the
Liberty specification is required.
This namespace specification is for a formal namespace.
Mealling Informational [Page 1]
RFC 3622 The Liberty URN Namespace February 2004
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:
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]. In addition, all Liberty URN NSSs will consist of a
left-to-right series of tokens delimited by colons. The left-to-
right sequence of colon-delimited tokens corresponds to descending
nodes in 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
terminating in a rightmost leaf node. See the section entitled
"Identifier assignment" below for more on the semantics of NSSs.
This syntax convention 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 = "%" / "/" / "?" / "#"
Mealling Informational [Page 2]
RFC 3622 The Liberty URN Namespace February 2004
The exclusion of the colon from the list of "other" characters
means that the colon can only occur as a delimiter between string
tokens. Note that this ABNF rule set guarantees that any valid
Liberty NSS is also a valid RFC 2141 NSS.
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:
Identifiers are assigned by the Liberty Project within its various
standards. In the process of publishing a specification all newly
minted names are checked against the record of previously assigned
names.
Identifier persistence considerations:
The assignment process guarantees that names are not reassigned
and that the binding between the name and its resource is
permanent, regardless of any standards or organizational changes.
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:
Lexical equivalence of two Liberty namespace specific strings
(NSSs) is defined as an exact, case-sensitive string match. The
Liberty Alliance will assign names of immediately subordinate
Mealling Informational [Page 3]
RFC 3622 The Liberty URN Namespace February 2004
naming authorities in a case-insensitive fashion, so that there
will not 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
While there is no resolution mechanism for this namespace, the names
themselves are used in public implementations of the Liberty
specifications. There are circumstances where objects from the
Liberty system will become exposed to the general Internet. In these
cases, the use of the Liberty namespace will provide general
interoperability benefits to the Internet at large. Additionally,
there may be subcomponents of the Liberty specifications that may be
adopted by other standards, in which case the URNs used to identify
those components and specifications can be easily used to enhance
other, non-Liberty based, systems.
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, thus applications should be careful to not
take some unverified sources assertion that what it is sending
adheres to what the actual URN is assigned to.
Mealling Informational [Page 4]
RFC 3622 The Liberty URN Namespace February 2004
6. References
6.1. Normative References
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[3] Hodges, J. and T. Watson, "Liberty Architecture Overview",
Liberty 1.1, January 2003,
.
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, .
[6] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
REC-xml-names, January 1999, .
[7] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
RFC, FYI, BCP