Network Working Group
Independent Submission                                     I. Young, Ed.
Internet-Draft
Request for Comments: 8409                                   Independent
Intended status:
Category: Informational                                     L. Johansson
Expires: August 4, 2018
ISSN: 2070-1721                                                    SUNET
                                                               S. Cantor
                                                   Shibboleth Consortium
                                                        January 31,
                                                               June 2018

     The Entity Category SAML Security Assertion Markup Language (SAML)
                            Attribute Types
                     draft-young-entity-category-07

Abstract

   This document describes a SAML Security Assertion Markup Language (SAML)
   entity attribute which that can be used to assign category membership
   semantics to an entity, entity and a second attribute for use in claiming
   interoperation with or support for entities in such categories.

   This document is a product of the working group process of the
   Research and Education Federations
   (REFEDS) Working Group process. group (REFEDS).

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not candidates for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list Standard;
   see Section 2 of RFC 7841.

   Information about the current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 August 4, 2018.
   https://www.rfc-editor.org/info/rfc8409.

Copyright Notice

   Copyright (c) 2018 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
   (https://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
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  REFEDS Document Process . . . . . . . . . . . . . . . . .   3
   2.  Notation and Conventions  . . . . . . . . . . . . . . . . . .   3
   3.  Entity Category Attribute . . . . . . . . . . . . . . . . . .   4   3
     3.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4   3
     3.2.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Entity Category Example . . . . . . . . . . . . . . . . .   6   5
   4.  Entity Category Support Attribute . . . . . . . . . . . . . .   6
     4.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Entity Category Support Example . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.
   Acknowledgements  . . . . . . . . . . . . . . . . . .  11
   Appendix B.  Change Log (to be removed by RFC Editor before
                publication) . . . . . . . . . . . . . . . . . . . .  11
     B.1.  Since draft-young-entity-category-05  . . . . . . . . . .  11
     B.2.  Since draft-young-entity-category-04  . . . . . . . . . .  11
     B.3.  Since draft-young-entity-category-03  . . . . . . . . . .  11
     B.4.  Since draft-young-entity-category-02  . . . . . . . . . .  11
     B.5.  Since draft-young-entity-category-01  . . . . . . . . . .  12
     B.6.  Since draft-young-entity-category-00  . . . . . . . . . .  12
     B.7.  Since draft-macedir-entity-category . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13  11

1.  Introduction

   This document describes a SAML attribute, attribute referred to here as the
   "entity category attribute", values attribute".  Values of which this attribute represent
   entity types or categories.  When used with the SAML V2.0 Metadata
   Extension for Entity Attributes [SAML2MetadataAttr] [SAML2MetadataAttr], each such entity
   category attribute value represents a claim that the entity thus labelled
   labeled meets the requirements of, and is asserted to be a member of,
   the indicated category.

   These category membership claims MAY be used by a relying party to
   provision policy for release of attributes from an identity provider,
   to influence user interface decisions such as those related to
   identity provider discovery, or for any other purpose.  In general,
   the intended uses of any claim of membership in a given category will
   depend on the details of the category's definition, definition and will often be
   included as part of that definition.

   Entity category attribute values are URIs, and URIs; therefore, this document
   therefore
   does not specify a controlled vocabulary for assigning entity
   category values.  Category URIs may be defined by any appropriate
   authority without any requirement for central registration.  It is
   anticipated that other specifications may provide management and
   discovery mechanisms for entity category attribute values.

   A second

   This document also describes a SAML attribute, attribute referred to here as the
   "entity category support attribute", attribute".  This attribute contains URI
   values which that represent claims that an entity supports and/or
   interoperates with entities in a given category or categories.  These
   values, defined in conjunction with specific entity category values,
   provide entities in a category with the means to identify peer
   entities that wish to interact with them in a fashion described by
   the category specification.

   This document does not specify any values either for either the entity
   category attribute or for the entity category support attribute.

1.1.  REFEDS Document Process

   The Research and Education Federations group ([REFEDS]) [REFEDS] is the voice
   that articulates the mutual needs of research and education identity
   federations worldwide.  It aims to represent the requirements of
   research and education in the ever-growing space of access and
   identity management.

   From time to time time, REFEDS will wish to publish a document in the
   Internet RFC series. Series.
   Such documents will be published as part of the
   RFC Independent
   Submission Stream stream [RFC4844]; however however, the REFEDS
   working group sign-off Working Group sign-
   off process will have been followed for these documents, as described
   in the REFEDS Participant's Agreement [REFEDS.agreement].

   This document is a product of the REFEDS Working Group process.

2.  Notation and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Entity Category Attribute

3.1.  Syntax

   Entity category attribute values MUST be valid URIs.  It is
   RECOMMENDED that http:-scheme or https:-scheme URIs are used, and used; it is
   further RECOMMENDED that an entity category URI resolves to a human-
   readable document defining the category.

   Authorities defining entity categories MUST produce a specification
   of the entity category and SHOULD make arrangement for the entity
   category URI to resolve to the specification in human readable human-readable form.

   Authorities defining entity categories MAY use versioning of entity
   category URIs where appropriate, in which case appropriate; if versioning is used, each version
   of the specification of the entity category SHOULD clearly indicate
   the latest version of the entity category URI (and hence of the
   specification).  The specification SHOULD include a description of
   how the authority defining the entity category implements governance
   for the specification in the case when the specification may be
   updated.

   When used in SAML metadata or protocol elements, the entity category
   attribute MUST be encoded as a SAML 2.0 Attribute element with
   @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
   http://macedir.org/entity-category.

   A SAML entity is associated with one or more categories by including
   the Attribute element described here in the entity's metadata through
   use of the [SAML2MetadataAttr] metadata extension, extension defined in which [SAML2MetadataAttr].  In
   this extension, the Attribute element is contained within an
   mdattr:EntityAttributes element directly contained within an
   md:Extensions element directly contained within the entity's
   md:EntityDescriptor.

   The meaning of the entity category attribute is undefined not defined by this
   specification if it appears anywhere else within a metadata instance, instance
   or within any other XML document.

   If the entity category attribute Attribute element appears more than
   once in the metadata for an entity, the combined set of associated
   attribute values SHOULD be interpreted by relying parties as if they
   all appeared within a single Attribute element.

3.2.  Semantics

   The presence of the entity category attribute within an entity's
   entity attributes represents a series of claims (one for each
   attribute value) that the entity is a member of each named category.
   The precise semantics of such a claim depend on the definition of the
   category itself.

   An entity may be claimed to be a member of more than one category.
   In this case, the entity is claimed to meet the requirements of each
   category independently unless otherwise specified by the category
   definitions themselves.

   The definition of the concept of a category "category" is intentionally not
   addressed in this document, in order to leave it as general as
   possible.  However, to be useful, category definitions SHOULD include
   the following as appropriate:

   o  A definition of the authorities who may validly assert membership
      in the category.  While membership in some categories may be self-
      asserted informally by an entity's owner, others may need to be
      validated by third parties such as the entity's home federation or
      other registrar.

   o  A set of criteria by which an entity's membership in the category
      can be objectively assessed.

   o  A definition of the processes by which valid authorities may
      determine that an entity meets the category's membership criteria.

   o  A description of the anticipated uses for category membership by
      relying parties.

   o  A statement indicating the applicability or otherwise of
      membership of the entity category to different SAML role
      descriptors,
      descriptors and any protocol support restrictions that may be
      relevant.

   Entity categories SHOULD NOT be used to indicate the certification
   status of an entity regarding its conformance to the requirements of
   an identity assurance framework.  The [SAML2IDAssuranceProfile] extension defined in
   [SAML2IDAssuranceProfile] SHOULD be used for this purpose.

   If significant changes are made to a category definition, the new
   version of the category SHOULD be represented by a different category
   URI so that the old and new versions can be distinguished by a
   relying party.  It is for this reason that authorities defining
   entity categories MAY employ some form of versioning for entity
   category URI. URIs.  When versioning is used used, each version of the entity
   category MUST be treated as a separate URI.

   No ordering relation is defined over entity category value URIs.
   Entity category attribute value URIs MUST be treated as opaque
   strings for the purpose of comparison.  In particular, if the
   specification defining the entity category relies on versioning of
   the entity category URI, a relying party MUST NOT assume any
   particular ordering between different versions of the entity
   category.  Any order between versions MUST be spelled out in the
   specification.

3.3.  Entity Category Example
   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     entityID="https://service.example.com/entity">
     <md:Extensions>
       <mdattr:EntityAttributes
         xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
         <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
           NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
           Name="http://macedir.org/entity-category">
           <AttributeValue
             >http://example.org/category/dog</AttributeValue>
           <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
         </Attribute>
       </mdattr:EntityAttributes>
     </md:Extensions>
     ...
   </md:EntityDescriptor>

4.  Entity Category Support Attribute

4.1.  Syntax

   Entity category support attribute values MUST be URIs.  It is
   RECOMMENDED that http:-scheme or https:-scheme URLs are used, and used; it is
   further RECOMMENDED that each such value resolves to a human-readable
   document defining the value's semantics.  A given entity category
   value MAY be associated with multiple support values in order to
   allow for multiple forms of support, participation, or interoperation
   with entities in the category.  The authoritiy authority defining the entity
   category and entity category support values MUST clearly describe the
   relationship between (all versions of) the entity category URI and
   (all versions of) the entity category support URIs as applicable in
   the entity category specification.

   The entity category support attribute MUST be encoded as a SAML 2.0
   Attribute element with @NameFormat
   urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
   http://macedir.org/entity-category-support.

   Claims that a SAML entity implements support for one or more
   categories are represented by including the Attribute element
   described here in the entity's metadata through use of the
   [SAML2MetadataAttr] metadata extension,
   extension defined in which [SAML2MetadataAttr].  In this extension, the
   Attribute element is contained within an mdattr:EntityAttributes
   element directly contained within an md:Extensions element directly
   contained within the entity's md:EntityDescriptor.

   The meaning of the entity category support attribute is undefined not defined
   by this specification if it appears anywhere else within a metadata
   instance,
   instance or within any other XML document.

   If the entity category support attribute Attribute element appears
   more than once in the metadata for an entity, the combined set of
   associated attribute values SHOULD be interpreted by relying parties
   as if they all appeared within a single Attribute element.

4.2.  Semantics

   The presence of the entity category support attribute within an
   entity's entity attributes represents a series of claims (one for
   each attribute value) that the entity supports peer entities in a
   category in a particular fashion.  The precise semantics of such a
   claim depend on the definition of the category support identifier
   itself.  Category support claims will often be defined to be self-
   asserted.

   An entity may be claimed to support more than one category.  In this
   case, the entity is claimed to meet the support requirements of each
   category independently unless otherwise specified by the category
   definitions themselves.

   The definition of the concept of "support" for a category is
   intentionally not addressed in this document, in order to leave it as
   general as possible.  It is assumed that entity category definitions
   MAY define one or more support values signifying particular
   definitions for "support" by peers as motivated by use cases arising
   from the definition of the category itself.

   A common case is expected to be the definition of a single support
   value whose URI is identical to that defined for the category itself.

   If significant changes are made to a category support definition, the
   new version SHOULD be represented by a different category support URI
   so that the old and new versions can be distinguished by a relying
   party.  It is for this reason that authorities defining entity
   categories support MAY employ some form of versioning.  When
   versioning is used used, each version of the entity category support URI
   MUST be treated as a separate URI.

   No ordering relation is defined over entity category URIs.  Entity
   category attribute support value URIs MUST be treated as opaque
   strings for the purpose of comparison.  In particular, if the
   specification defining the entity category support values relies on
   versioning, a relying party MUST NOT assume any particular ordering
   between different versions of the entity category support URI.  Any
   order between versions MUST be spelled out in the specification.

4.3.  Entity Category Support Example

   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     entityID="https://idp.example.edu/entity">
     <md:Extensions>
       <mdattr:EntityAttributes
         xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
         <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
           NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
           Name="http://macedir.org/entity-category-support">
           <AttributeValue
             >http://example.org/category/dog/basic</AttributeValue>
           <AttributeValue
             >http://example.org/category/dog/advanced</AttributeValue>
           <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
         </Attribute>
       </mdattr:EntityAttributes>
     </md:Extensions>
     ...
   </md:EntityDescriptor>

5.  IANA Considerations

   This memo includes document has no request to IANA. IANA actions.

6.  Security Considerations

   The presence of the entity category attribute within an entity's
   entity attributes represents a series of claims (one for each
   attribute value) that the entity is a member of the named categories.
   Before accepting and acting on such claims, any relying party needs
   to establish, at a level of assurance sufficient for the intended
   use, a chain of trust concluding that the claim is justified.

   Some of the elements in such a chain of trust might include:

   o  The integrity of the metadata delivered to the relying party, as for example
      example, as assured by a digital signature.

   o  If the entity category attribute is carried within a signed
      assertion, the assertion itself must be evaluated.

   o  The policies and procedures of the immediate source of the
      metadata;
      metadata, in particular, any procedures the immediate source has
      with regard to aggregation of metadata from other sources.

   o  The policies and procedures implemented by agents along the
      publication path from the original metadata registrar: this registrar.  This may
      be determined either by examination of the published procedures of each
      agent in turn, turn or may be simplified if the entity metadata includes
      publication path metadata in mdrpi:PublicationPath elements as
      described in [SAML2MetadataRPI] section 2.3.1. Section 2.3.1 of [SAML2MetadataRPI].

   o  The policies and procedures implemented by the original metadata
      registrar.  The registrar's identity may be known implicitly, implicitly or
      may be determined from the entity metadata if it includes an
      mdrpi:RegistrationInfo element and corresponding
      @registrationAuthority attribute as described in
      [SAML2MetadataRPI] section 2.1.1. Section 2.1.1 of
      [SAML2MetadataRPI].

   o  The definition of the category itself; itself, in particular, any
      statements it makes about whether membership of the category may
      be self-asserted, self-asserted or may only be asserted by particular
      authorities.

   Although entity category support attribute values will often be
   defined as self-asserted claims by the containing entity, the
   provenance of the metadata remains relevant to a relying party's
   decision to accept a claim of support as legitimate, and the specific
   definition of a support claim will influence the assurance required
   to act on it.

   The conclusion that a claim of category membership or support is
   justified and should be acted upon may require a determination of the
   origin of the claim.  This may not be necessary if the immediate
   source of the metadata is trusted to such an extent that the trust
   calculation is essentially delegated to it.

   In many cases, a claim will be included in an entity's metadata by
   the original metadata registrar on behalf of the entity's owner, and
   the mdrpi:RegistrationInfo element's @registrationAuthority attribute
   is available to carry the registrar's identity.  However, any agent
   that is part of the chain of custody between the original registrar
   and the final relying party may have added, removed removed, or transformed
   claims according to local policy.  For example, an agent charged with
   redistributing metadata may remove claims it regards as
   untrustworthy, untrustworthy
   or add others which that were not already present if they have value to its
   intended audience.

7.  References

7.1.  Normative References

   [BCP14]

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [SAML2MetadataAttr]
              Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
              Attributes",
              Attributes Version 1.0", August 2009,
              <http://wiki.oasis-open.org/security/SAML2MetadataAttr>. <http://docs.oasis-
              open.org/security/saml/Post2.0/
              sstc-metadata-attr-cs-01.pdf>.

   [SAML2MetadataRPI]
              La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
              Registration and Publication Information Version 1.0",
              April 2012,
              <http://wiki.oasis-open.org/security/SAML2MetadataDRI>. <http://docs.oasis-
              open.org/security/saml/Post2.0/saml-metadata-
              rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.pdf>.

7.2.  Informative References

   [REFEDS]   Research   "Research and Education Federations, "REFEDS Home Page", Federations Group (REFEDS)",
              <http://www.refeds.org/>.

   [REFEDS.agreement]
              Research and Education Federations, "REFEDS Participant's
              Agreement",
              <https://refeds.org/about/refeds-participants-agreement>.

   [RFC4844]  Daigle, L. L., Ed. and Internet Architecture Board, "The RFC
              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
              July 2007. 2007, <https://www.rfc-editor.org/info/rfc4844>.

   [SAML2IDAssuranceProfile]
              Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed.,
              "SAML V2.0 Identity Assurance Profiles Version 1.0",
              November 2010, <https://wiki.oasis-open.org/security/
              SAML2IDAssuranceProfile>.

Appendix A. <http://docs.oasis-
              open.org/security/saml/Post2.0/
              sstc-saml-assurance-profile-cs-01.pdf>.

Acknowledgements

   This work has been a collaborative effort within the REFEDS and MACE-
   Dir communities.  Special thanks to the following individuals (in no
   particular order):

   o  RL 'Bob' Morgan

   o  Ken Klingenstein

   o  Keith Hazelton

   o  Steven Olshansky

   o  Mikael Linden

   o  Nicole Harris

   o  Tom Scavo

Authors' Addresses

   Ian A. Young (editor)
   Independent

   EMail:

   Email: ian@iay.org.uk

   Leif Johansson
   SUNET

   EMail:

   Email: leifj@sunet.se

   Scott Cantor
   Shibboleth Consortium

   EMail:

   Email: cantor.2@osu.edu