From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3622.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3622.txt (limited to 'doc/rfc/rfc3622.txt') diff --git a/doc/rfc/rfc3622.txt b/doc/rfc/rfc3622.txt new file mode 100644 index 0000000..b0f8c3b --- /dev/null +++ b/doc/rfc/rfc3622.txt @@ -0,0 +1,395 @@ + + + + + + +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, + . + +7. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + + + + +Mealling Informational [Page 5] + +RFC 3622 The Liberty URN Namespace February 2004 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mealling Informational [Page 6] + +RFC 3622 The Liberty URN Namespace February 2004 + + +9. Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Mealling Informational [Page 7] + -- cgit v1.2.3