draft-johansson-areg-reqs-00.txt

Internet Engineering Task Force                        L. Johansson, Ed.
Internet-Draft                                                  NORDUnet
Intended status: Informational                               H. Flanagan
Expires: January 31, 2013                                      Internet2
                                                           July 30, 2012


                 Requirements on an Attribute Registry
                      draft-johansson-areg-reqs-00

Abstract

   This document establishes requirements for a registry of attributes
   type 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 January 31, 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 January 31, 2013                [Page 1]

Internet-Draft       Attribute Registry Requirements           July 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 January 31, 2013                [Page 2]

Internet-Draft       Attribute Registry Requirements           July 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
   3.  Requrements . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     3.1.  Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     3.2.  Data Locality . . . . . . . . . . . . . . . . . . . . . . . 7
     3.3.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     3.4.  Schema  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     3.5.  Lookup and Search . . . . . . . . . . . . . . . . . . . . . 8
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Johansson & Flanagan    Expires January 31, 2013                [Page 3]

Internet-Draft       Attribute Registry Requirements           July 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
   type') is defined by semantics and syntax that allow it to be used in
   a variety of protocols and representations.

   This document lists requrements for a registry of such attribute type
   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 type definitions that are borrowed from LDAP
   or X.509 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 boundries (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 types 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 stablish global uniqueness.




Johansson & Flanagan    Expires January 31, 2013                [Page 4]

Internet-Draft       Attribute Registry Requirements           July 2012


   There are examples of attribute type 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
   use to represent the name it is sometimes necessary to have to create
   an alias for a name within another namespace.  Name agility has
   implication 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.  The former use-case requires a global service available
   247 while the latter requires the availability typically found in a
   website providing documentation.

   This document is skewed towards the former use-case.  The authors
   believe that the operational issues involved in the latter type of
   registry would be daunting to say the least and it is only presented
   here for 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
   concieve 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 there 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 entry-point unless there is a mechanism for performing
   lookups.

   The central model by contrast is simpler in that no protocol needs to



Johansson & Flanagan    Expires January 31, 2013                [Page 5]

Internet-Draft       Attribute Registry Requirements           July 2012


   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.509 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 attribute types 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 he 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 type.
   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 chaised 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
   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



Johansson & Flanagan    Expires January 31, 2013                [Page 6]

Internet-Draft       Attribute Registry Requirements           July 2012


   of a domain name.


3.  Requrements

   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 type 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 type 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
   the complexity of the registry.

3.3.  Naming

   o  The registry MUST support multiple name spaces for naming
      attribute types.

   o  The registry MUST support attribute type name aliases.

   o  The registry MAY support aliases that are namespace-free short
      names.




Johansson & Flanagan    Expires January 31, 2013                [Page 7]

Internet-Draft       Attribute Registry Requirements           July 2012


   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 type schema.

   o  The native attribute type schema MUST map cleanly (in)to X.520/
      LDAP schema for attribute types

   o  The native attribute type schema MAY only represent a subset of
      the features of X.520/LDAP schema

   o  The native attribute type schema SHOULD support multiple
      serializations (XML,JSON,etc)

3.5.  Lookup and Search

   o  The registry MUST support lookup based on attribute type name.

   o  The registry MUST support lookup based on attribute type aliases
      if they are provided.

   o  The registry MAY support search but registry consumers MUST NOT
      assume support for search.


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.






Johansson & Flanagan    Expires January 31, 2013                [Page 8]

Internet-Draft       Attribute Registry Requirements           July 2012


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-01 (work in
              progress), March 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",
              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







Johansson & Flanagan    Expires January 31, 2013                [Page 9]

Internet-Draft       Attribute Registry Requirements           July 2012


   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 January 31, 2013               [Page 10]