Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

INFORMATIONAL
Network Working Group                                        M. MeallingRequest for Comments: 3622                                VeriSign, Inc.Category: Informational                                    February 2004A Uniform Resource Name (URN) Namespace forthe Liberty Alliance ProjectStatus 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 20042.  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 ofRFC2141 [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 theRFC 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 validRFC 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 subordinateMealling                     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:      Global3.  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 20046.  References6.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,        <http://www.projectliberty.org/specs/liberty-architecture-overview-v1.1.pdf>.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 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 inBCP-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.comMealling                     Informational                      [Page 6]

RFC 3622               The Liberty URN Namespace           February 20049.  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]

[8]ページ先頭

©2009-2025 Movatter.jp