draft-johansson-areg-reqs.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-johansson-areg-reqs-00"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="Attribute Registry Requirements">Requirements on an
    Attribute Registry</title>

    <author fullname="Leif Johansson" initials="L." role="editor"
            surname="Johansson">
      <organization>NORDUnet</organization>

      <address>
        <email>leifj@nordu.net</email>
      </address>
    </author>
 
    <author fullname="Heather Flanagan" initials="H" surname="Flanagan">
      <organization>Internet2</organization>

      <address>
        <postal>
          <street>1000 Oakbrook Drive Suite 300</street>

          <city>Ann Arbor</city>

          <region>MI</region>

          <code>48104 </code>

          <country>US</country>
        </postal>

        <phone>+1-360-562-0319</phone>

        <email>hlflanagan@internet2.edu</email>

      </address>
    </author>

    <date day="30" month="July" year="2012" />

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>
      <t>This document establishes requirements for a registry of attributes
      type definitions.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction and Motivation">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Core Concerns">
      <t>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:</t>

      <section title="Naming">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Use">
        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Data Locality">
        <t>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.</t>

        <t>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.</t>

        <t>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 <xref
        target="RFC6557"></xref>.</t>

        <t>One possible basis for a distributed registry is the Dynamic
        Delegation Discovery System (DDDS) as described in <xref
        target="RFC3401"></xref><xref target="RFC3402">,</xref><xref
        target="RFC3403">,</xref><xref target="RFC3404"> and</xref>.</t>
      </section>

      <section title="Schema">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Lookup and Search">
        <t>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 of a
        domain name.</t>
      </section>
    </section>

    <section title="Requrements">
      <t>The following terminology is used in this section:</t>

      <t><list style="hanging">
          <t hangText="registry">An instance of an attribute registry
          fulfilling these requirements.</t>

          <t hangText="consumer">A user, device, process or other entity that
          consumes information from the registry.</t>

          <t hangText="attribute type">An element of the registry.</t>

          <t hangText="attribute name">Synonymous with attribute type name</t>
        </list></t>

      <section title="Use">
        <t><list style="symbols">
            <t>A consumer MUST NOT directly use the registry for
            in-transaction lookup.</t>
          </list>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.</t>
      </section>

      <section title="Data Locality">
        <t><list style="symbols">
            <t>The registry SHOULD be established as a central,
            non-distributed registry.</t>
          </list>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.</t>
      </section>

      <section title="Naming">
        <t><list style="symbols">
            <t>The registry MUST support multiple name spaces for naming
            attribute types.</t>

            <t>The registry MUST support attribute type name aliases.</t>

            <t>The registry MAY support aliases that are namespace-free short
            names.</t>

            <t>The registry SHOULD (if such names are supported) impose
            restrictions on registering short names.</t>
          </list></t>

        <t></t>
      </section>

      <section title="Schema">
        <t><list style="symbols">
            <t>The registry SHOULD support a native attribute type schema.</t>

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

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

            <t>The native attribute type schema SHOULD support multiple
            serializations (XML,JSON,etc)</t>
          </list></t>
      </section>

      <section title="Lookup and Search">
        <t><list style="symbols">
            <t>The registry MUST support lookup based on attribute type
            name.</t>

            <t>The registry MUST support lookup based on attribute type
            aliases if they are provided.</t>

            <t>The registry MAY support search but registry consumers MUST NOT
            assume support for search.</t>
          </list></t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This work was inspired by discussions at the ISOC identity ecosystem
      workshops held in Amsterdam and Gathersburgh MD in 2011 and 2012.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <t>Main contributors for this work has been<list style="symbols">
          <t>Heather Flanagan (ISOC/Internet2)</t>

          <t>James Bryce Clark (OASIS)</t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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 <xref
      target="I-D.iab-identifier-comparison">draft-iab-identifier-comparison</xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.3401"?>

      <?rfc include="reference.RFC.3402"?>

      <?rfc include="reference.RFC.3403"?>

      <?rfc include="reference.RFC.3404"?>

      <?rfc include="reference.RFC.6557"?>

      <?rfc include="reference.I-D.iab-identifier-comparison"?>
    </references>
  </back>
</rfc>