Internet Engineering Task Force L. Johansson, Ed. Internet-Draft NORDUnet Intended status: Informational H. Flanagan Expires: May 18, 2013 Internet2 November 14, 2012 Requirements on an Attribute Registry draft-johansson-areg-reqs-01 Abstract This document establishes requirements for a registry of attributes definitions. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 18, 2013. Copyright Notice Copyright (c) 2012 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 Johansson & Flanagan Expires May 18, 2013 [Page 1] Internet-Draft Attribute Registry Requirements November 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Johansson & Flanagan Expires May 18, 2013 [Page 2] Internet-Draft Attribute Registry Requirements November 2012 Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 2. Core Concerns . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Data Locality . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Lookup and Search . . . . . . . . . . . . . . . . . . . . 6 2.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Data Locality . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Lookup and Search . . . . . . . . . . . . . . . . . . . . 8 3.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Johansson & Flanagan Expires May 18, 2013 [Page 3] Internet-Draft Attribute Registry Requirements November 2012 1. Introduction and Motivation An attribute is a representation of a single datum of information associated with an entity. The type of the attribute (the 'attribute') is defined by semantics and syntax that allow it to be used in a variety of protocols and representations. This document lists requirements for a registry of such attribute definitions. For a long time, protocols that rely on the transfer of attributes (like OpenID Connect, OAUTH, WS-Federation or SAML) often rely on, at least in the case of attributes associated with accounts and persons, attribute definitions that are borrowed from LDAP or X.520 schema even though those particular protocols no longer represent the common method to transfer and consume attributes. Claims-based protocols (for instance SAML or OpenID Connect) are widely used on the Internet today. A common use-case for such protocols is to establish identity federations that rely on the transfer of attribute-values as a means to communicate subject information. Identity federations are often purposed to specific communities. Increasingly such communities need to engage in transactions across federation boundaries (eg when sharing services with other communities). This practice is called inter-federation. Inter-federation raises the need for a way to discover information about the attributes used in the protocols employed inside and between federations. This document attempts to address these problems by establishing a set of requirements for an Internet-wide registry of attribute-type definitions. This document does not attempt to establish the registry, that will be the work of future specifications. 2. Core Concerns In order to set the stage for, and properly frame the registry requirements the following section lists a set of core concerns that MUST be address by the registry requirements proper: 2.1. Naming It is implied that attribute have names that uniquely identify them. This requirement will be spelled out in detail below. A core concern implied by the existence of names is one of name management. A common way to implement name management is to structure the names in such a way as to establish name-spaces - parts of the name that can be allocated, delegated and used to establish global uniqueness. Johansson & Flanagan Expires May 18, 2013 [Page 4] Internet-Draft Attribute Registry Requirements November 2012 There are examples of attribute definitions that are in common use today that employ a variety of name spaces including both OIDs, http- based URIs and URNs. Another aspect of naming is name agility. Depending on the protocol used to represent the name it is sometimes necessary to create an alias for a name within another namespace. Name agility has implications for the structure and contents of an attribute registry. Attribute names sometime need human-readable (aka "friendly") labels. This leads to questions of internationalization and possibly security considerations in analogy to how IDNs can result in new attack- vectors when used in URIs. 2.2. Use The core usage-question is this: will the attribute registry be used in conjunction with individual transactions or as a tool for configuration, discovery and information related to the task of setting up federations and other relationships using claims-based protocols, A registry that would be used by individual transactions requires a global service available 247 while a registry used only at configuration-time requires the availability typically found in a website providing documentation. This document is skewed towards the configuration-time use-case. The authors believe that the operational issues involved in running a transaction-oriented type of registry would be daunting to say the least and this alternative is only presented here for the sake of completeness. 2.3. Data Locality There are two fundamental models for registries (as for any data store): centralized and distributed. In a central registry all the information is kept and maintained in one place whereas a distributed registry shares information in the registry over multiple cooperative instances that together make up the full registry. It is possible to conceiive of hybrid models where for instance a central index is used to store referrals to a set of distributed nodes. The distributed model is most often used when the expected use of the registry would imply a very high load on a single registry instance. An example of a system with this property is the DNS. A distributed registry model has implications for requirements on lookup (cf below). Specifically the registry may need a central or well-known Johansson & Flanagan Expires May 18, 2013 [Page 5] Internet-Draft Attribute Registry Requirements November 2012 entry-point unless there is a mechanism for performing lookups. The central model by contrast is simpler in that no protocol needs to be specified for communicating between registry instances and that lookup can be handled to a single well know instance. This model may be preferred if the total amount of data in the registry is relatively small (at least compared to the DNS or systems of similar scale). The fact that the registry is operated in a single instance does not necessarily imply lowered requirements on availability and security. An example of this type of registry is the Time Zone Database [RFC6557]. One possible basis for a distributed registry is the Dynamic Delegation Discovery System (DDDS) as described in [RFC3401], [RFC3402], [RFC3403]and [RFC3404]. 2.4. Schema As was stated in the introduction LDAP and X.520 attribute schema is commonly used to describe attribute-types for claims-based protocols. Recently however there is a trend towards defining "raw attributes", i.e attributes that are not supported by a corresponding directory schema. Thus there may be a need to define a "directory-neutral" attribute-type schema langue. In either case there will probably be a need to support multiple schema in the registry. Note that LDAP and X.509 schema have a property that is not currently used in claims-based protocols: objectClass definitions. These are schema elements that often list a set of mandatory and/or optional associated attributes. Depending on the intended use of the registry there may need to exist a native attribute schema for the registry which may or may not need to represent the complete set of properties of each attribute. For instance if the intended use of the registry is to support configuration and setup of federation, rather than in-transaction discovery of attribute properties, the registry native schema may not have to include all information of each attribute. Instead it would be possible to maintain a minimal set of core properties in the registry and provide references to external information sources that could be chained for additional information. 2.5. Lookup and Search Lookup and Search may appear to be very similar operations but they are in fact quite dissimilar in that they place very different requirements on the representation and schema of the data to be searched. To draw an example from the DNS again: The DNS supports Johansson & Flanagan Expires May 18, 2013 [Page 6] Internet-Draft Attribute Registry Requirements November 2012 lookup but not search. In other words it is possible to, given a domain name, lookup the corresponding records in the DNS but it is not in general possible to search for records given knowledge of part of a domain name. 2.6. Updates The core concern is weather updates to the registry (i.e publishing new attributes in the registry) is in scope for the registry specification or not. In other words an attribute registry could be specified based on a read-write protocol that allows dynamic updates to the set of attributes or it could focus on read-only (i.e consume- only) access to the registry. 3. Requirements The following terminology is used in this section: registry An instance of an attribute registry fulfilling these requirements. consumer A user, device, process or other entity that consumes information from the registry. attribute type An element of the registry. attribute name Synonymous with attribute name 3.1. Use o A consumer MUST NOT directly use the registry for in-transaction lookup. The registry is primarily intended for use as a tool to help discover attribute information related to setup and configuration of federations. While services that directly tie in to authentication events (for instance in order to provide i18n of attribute friendly names) may be needed, such services can always be developed as commercial spin-offs from the basic registry. 3.2. Data Locality o The registry SHOULD be established as a central, non-distributed registry. Since the primary use of the registry is not for in-transaction lookups the registry does not need to be distributed which reduces Johansson & Flanagan Expires May 18, 2013 [Page 7] Internet-Draft Attribute Registry Requirements November 2012 the complexity of the registry. 3.3. Naming o The registry MUST support multiple name spaces for naming attributes. o The registry MUST support attribute name aliases. o The registry MAY support aliases that are namespace-free short names. o The registry SHOULD (if such names are supported) impose restrictions on registering short names. 3.4. Schema o The registry SHOULD support a native attribute schema. o The native attribute schema MAY only represent a subset of the features of X.520/LDAP schema and may not end up being a proper sub or superset of LDAP capability. o The native attribute schema SHOULD support multiple serializations (XML,JSON,etc) o The native attribute schema MUST include definition of attribute values serialization. o The native attribute schema MUST include definition of attribute value data types. 3.5. Lookup and Search o The registry MUST support lookup based on attribute name. o The registry MUST support lookup based on attribute aliases if they are provided. o The registry MAY support search but registry consumers MUST NOT assume support for search. 3.6. Updates o The registry MUST support consumers o The registry MUST NOT require support for updates. Johansson & Flanagan Expires May 18, 2013 [Page 8] Internet-Draft Attribute Registry Requirements November 2012 4. Acknowledgements This work was inspired by discussions at the ISOC identity ecosystem workshops held in Amsterdam and Gathersburgh MD in 2011 and 2012. 5. Contributors Main contributors for this work has been o Heather Flanagan (ISOC/Internet2) o James Bryce Clark (OASIS) 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations Attributes are often used to carry sensitive information as part of claims-based protocols. It is common for claims to contain attribute values that are used to allow or deny access to a protected resource. Some attributes carry identifiers as values. A discussion of the security implications of handling identifiers can be found in draft-iab-identifier-comparison [I-D.iab-identifier-comparison]. 8. Normative References [I-D.iab-identifier-comparison] Thaler, D., "Issues in Identifier Comparison for Security Purposes", draft-iab-identifier-comparison-03 (work in progress), July 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", Johansson & Flanagan Expires May 18, 2013 [Page 9] Internet-Draft Attribute Registry Requirements November 2012 RFC 3403, October 2002. [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, February 2012. Authors' Addresses Leif Johansson (editor) NORDUnet Email: leifj@nordu.net Heather Flanagan Internet2 1000 Oakbrook Drive Suite 300 Ann Arbor, MI 48104 US Phone: +1-360-562-0319 Email: hlflanagan@internet2.edu Johansson & Flanagan Expires May 18, 2013 [Page 10]