idnits 2.17.1 draft-johansson-areg-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 5, 2014) is 3551 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Johansson, Ed. 3 Internet-Draft NORDUnet 4 Intended status: Informational H. Flanagan 5 Expires: February 6, 2015 Spherical Cow Consulting 6 August 5, 2014 8 Requirements on an Attribute Registry 9 draft-johansson-areg-reqs-02 11 Abstract 13 This document establishes requirements for a registry of attribute- 14 type definitions. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 6, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 69 2. Core Concerns . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.3. Data Locality . . . . . . . . . . . . . . . . . . . . . . 4 73 2.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.5. Lookup and Search . . . . . . . . . . . . . . . . . . . . 5 75 3. Requrements . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Data Locality . . . . . . . . . . . . . . . . . . . . . . 6 78 3.3. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.5. Lookup and Search . . . . . . . . . . . . . . . . . . . . 7 81 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 82 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction and Motivation 90 An attribute is a representation of a single datum of information 91 associated with an entity. The type of the attribute (the 'attribute 92 type') is defined by semantics and syntax that allow it to be used in 93 a variety of protocols and representations. 95 This document lists requrements for a registry of such attribute-type 96 definitions. For a long time, protocols that rely on the transfer of 97 attributes (like OpenID Connect, OAUTH, WS-Federation or SAML) often 98 rely on, at least in the case of attributes associated with accounts 99 and persons, attribute-type definitions that are borrowed from LDAP 100 or X.509 schema even though those particular protocols no longer 101 represent the common method to transfer and consume attributes. 103 Claims-based protocols (for instance SAML or OpenID Connect) are 104 widely used on the Internet today. A common use-case for such 105 protocols is to establish identity federations that rely on the 106 transfer of attribute-values as a means to communicate subject 107 information. Identity federations are often purposed to specific 108 communities. Increasingly such communities need to engage in 109 transactions across federation boundaries (e.g., when sharing 110 services with other communities). This practice is called inter- 111 federation. Inter-federation raises the need for a way to discover 112 information about the attributes used in the protocols employed 113 inside and between federations. 115 This document attempts to address these problems by establishing a 116 set of requirements for an Internet-wide registry of attribute-type 117 definitions. This document does not attempt to establish the 118 registry, that will be the work of future specifications. 120 2. Core Concerns 122 In order to set the stage for and properly frame the registry 123 requirements, the following section lists a set of core concerns that 124 MUST be address by the registry requirements proper: 126 2.1. Naming 128 It is implied that attribute types have names that uniquely identify 129 them. This requirement will be spelled out in detail below. A core 130 concern implied by the existence of names is one of name management. 131 A common way to implement name management is to structure the names 132 in such a way as to establish name-spaces - parts of the name that 133 can be allocated, delegated and used to stablish global uniqueness. 135 There are examples of attribute-type definitions that are in common 136 use today that employ a variety of name spaces including both OIDs, 137 http-based URIs and URNs. 139 Another aspect of naming is name agility. Depending on the protocol 140 use to represent the name it is sometimes necessary to have to create 141 an alias for a name within another namespace. Name agility has 142 implication for the structure and contents of an attribute registry. 144 Attribute names sometime need human-readable (aka "friendly") labels. 145 This leads to questions of internationalization and possibly security 146 considerations in analogy to how IDNs can result in new attack- 147 vectors when used in URIs. 149 2.2. Use 151 The core usage-question is this: will the attribute registry be used 152 in conjunction with individual transactions or as a tool for 153 configuration, discovery and information related to the task of 154 setting up federations and other relationships using claims-based 155 protocols. The former use-case requires a global service available 156 24x7 while the latter requires the availability typically found in a 157 website providing documentation. 159 This document is skewed towards the former use-case. The authors 160 believe that the operational issues involved in the latter type of 161 registry would be daunting to say the least; it is only presented 162 here for completeness. 164 2.3. Data Locality 166 There are two fundamental models for registries (as for any data 167 store): centralized and distributed. In a central registry all the 168 information is kept and maintained in one place, whereas a 169 distributed registry shares information in the registry over multiple 170 cooperative instances that together make up the full registry. It is 171 possible to concieve of hybrid models where for instance a central 172 index is used to store referrals to a set of distributed nodes. 174 The distributed model is most often used when the expected use of the 175 registry would imply a very high load on a single registry instance. 176 An example of a system with this property is the DNS. A distributed 177 registry model has implications for requirements on lookup (cf 178 below). Specifically the registry may need a central or well-known 179 entry-point unless there is a mechanism for performing lookups. 181 The central model by contrast is simpler in that no protocol needs to 182 be specified for communicating between registry instances and that 183 lookup can be handled to a single well-know instance. This model may 184 be preferred if the total amount of data in the registry is 185 relatively small (at least compared to the DNS or systems of similar 186 scale). The fact that the registry is operated in a single instance 187 does not necessarily imply lowered requirements on availability and 188 security. An example of this type of registry is the Time Zone 189 Database [RFC6557]. 191 One possible basis for a distributed registry is the Dynamic 192 Delegation Discovery System (DDDS) as described in [RFC3401], 193 [RFC3402], [RFC3403]and [RFC3404]. 195 2.4. Schema 197 As was stated in the introduction, an LDAP and X.509 attribute schema 198 is commonly used to describe attribute-types for claims-based 199 protocols. Recently however there is a trend towards defining "raw 200 attributes", i.e, attribute-types that are not supported by a 201 corresponding directory schema. Thus there may be a need to define a 202 "directory-neutral" attribute-type schema langue. In either case 203 there will probably be a need to support multiple schema in the 204 registry. 206 Note that LDAP and X.509 schema have a property that is not currently 207 used in claims-based protocols: objectClass definitions. These are 208 schema elements that often list a set of mandatory and/or optional 209 associated attributes. 211 Depending on the intended use of the registry, a native attribute 212 schema may need to exist for the registry that may or may not need to 213 represent the complete set of properties of each attribute type. For 214 instance, if the intended use of the registry is to support 215 configuration and setup of federation, rather than in-transaction 216 discovery of attribute properties, the registry native schema may not 217 have to include all information of each attribute. Instead it would 218 be possible to maintain a minimal set of core properties in the 219 registry and provide references to external information sources that 220 could be chaised for additional information. 222 2.5. Lookup and Search 224 Lookup and Search may appear to be very similar operations but they 225 are in fact quite dissimilar in that they place very different 226 requirements on the representation and schema of the data to be 227 searched. To draw an example from the DNS again: The DNS supports 228 lookup but not search. In other words it is possible to, given a 229 domain name, lookup the corresponding records in the DNS but it is 230 not in generally possible to search for records given knowledge of 231 only part of a domain name. 233 3. Requrements 235 The following terminology is used in this section: 237 registry An instance of an attribute registry fulfilling these 238 requirements. 240 consumer A user, device, process, or other entity that consumes 241 information from the registry. 243 attribute type An element of the registry. 245 attribute name Synonymous with attribute-type name 247 3.1. Use 249 o A consumer MUST NOT directly use the registry for in-transaction 250 lookup. 252 The registry is primarily intended for use as a tool to help discover 253 attribute-type information related to setup and configuration of 254 federations. While services that directly tie in to authentication 255 events (for instance, in order to provide for the 256 internationalization of attribute-friendly names) may be needed, such 257 services can always be developed as commercial spin-offs from the 258 basic registry. 260 3.2. Data Locality 262 o The registry SHOULD be established as a central, non-distributed 263 registry. 265 Since the primary use of the registry is not for in-transaction 266 lookups, the registry does not need to be distributed. This reduces 267 the complexity of the registry. 269 3.3. Naming 271 o The registry MUST support multiple name spaces for naming 272 attribute types. 274 o The registry MUST support attribute-type name aliases. 276 o The registry MAY support aliases that are namespace-free short 277 names. 279 o The registry SHOULD (if such names are supported) impose 280 restrictions on registering short names. 282 3.4. Schema 284 o The registry SHOULD support a native attribute type schema. 286 o The native attribute-type schema MUST map cleanly (in)to X.520/ 287 LDAP schema for attribute types 289 o The native attribute-type schema MAY only represent a subset of 290 the features of X.520/LDAP schema 292 o The native attribute-type schema SHOULD support multiple 293 serializations (XML,JSON,etc) 295 3.5. Lookup and Search 297 o The registry MUST support lookup based on attribute-type name. 299 o The registry MUST support lookup based on attribute-type aliases 300 if they are provided. 302 o The registry MAY support search but registry consumers MUST NOT 303 assume support for search. 305 4. Acknowledgements 307 This work was inspired by discussions at the ISOC identity ecosystem 308 workshops held in Amsterdam and Gathersburgh MD in 2011 and 2012. 310 5. Contributors 312 Main contributors for this work has been 314 o Heather Flanagan (ISOC/Internet2) 316 o James Bryce Clark (OASIS) 318 6. IANA Considerations 320 This memo includes no request to IANA. 322 7. Security Considerations 324 Attributes are often used to carry sensitive information as part of 325 claims-based protocols. It is common for claims to contain attribute 326 values that are used to allow or deny access to a protected resource. 327 Some attributes carry identifiers as values. A discussion of the 328 security implications of handling identifiers can be found in "Issues 329 in Identifier Comparison for Security Purposes" [RFC6943]. 331 8. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 337 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 339 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 340 Part Two: The Algorithm", RFC 3402, October 2002. 342 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 343 Part Three: The Domain Name System (DNS) Database", RFC 344 3403, October 2002. 346 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 347 Part Four: The Uniform Resource Identifiers (URI)", RFC 348 3404, October 2002. 350 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 351 Time Zone Database", BCP 175, RFC 6557, February 2012. 353 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 354 Purposes", RFC 6943, May 2013. 356 Authors' Addresses 358 Leif Johansson (editor) 359 NORDUnet 361 Email: leifj@nordu.net 363 Heather Flanagan 364 Spherical Cow Consulting 366 Email: hlf@sphericalcowconsulting.com