doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6711.txt b/doc/rfc/rfc6711.txt
new file mode 100644
index 0000000..7bc0c34
--- /dev/null
+++ b/doc/rfc/rfc6711.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      L. Johansson
+Request for Comments: 6711                                      NORDUNet
+Category: Informational                                      August 2012
+ISSN: 2070-1721
+
+
+         An IANA Registry for Level of Assurance (LoA) Profiles
+
+Abstract
+
+   This document establishes an IANA registry for Level of Assurance
+   (LoA) Profiles.  The registry is intended to be used as an aid to
+   discovering such LoA definitions in protocols that use an LoA
+   concept, including Security Assertion Markup Language (SAML) 2.0 and
+   OpenID Connect.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6711.
+
+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
+   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.
+
+
+
+
+
+Johansson                     Informational                     [Page 1]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Name of Registry ................................................3
+   3. Registration Template ...........................................3
+      3.1. Example Registration .......................................4
+      3.2. Note on the Example ........................................5
+   4. Registration Policy .............................................5
+      4.1. Reviewer Expectations ......................................5
+   5. Registry Semantics ..............................................6
+   6. IANA Considerations .............................................6
+   7. Security Considerations .........................................7
+   8. Acknowledgements ................................................7
+   9. References ......................................................7
+      9.1. Normative References .......................................7
+      9.2. Informative References .....................................7
+
+1.  Introduction
+
+   This document establishes an IANA registry for Level of Assurance
+   (LoA) Profiles.
+
+   [SAML] provides the following definition of the concept of "level of
+   assurance":
+
+      Many existing (and potential) SAML federation deployments have
+      adopted a "levels of assurance" (or LOA) model for categorizing
+      the wide variety of authentication methods into a small number of
+      levels, typically based on some notion of the strength of the
+      authentication.  Federation members (service providers or "relying
+      parties") then decide which level of assurance is required to
+      access specific protected resources, based on some assessment of
+      "value" or "risk".
+
+   Another definition of an "assurance level" is given in RFC 4949
+   [RFC4949], which also identifies the roots of such profiles in the
+   NIST special publication series, in particular SP 800-63 [SP63].
+   Level of Assurance Profiles are used in various protocols, including
+   the Security Assertion Markup Language (SAML) version 2.0 and OpenID
+   Connect.
+
+   Several so-called trust frameworks and identity federations now
+   exist, some of which define one or more LoAs.  The purpose of this
+   specification is to create an IANA registry where such LoA
+   definitions can be discovered.  While the quote above references
+   SAML, the notion of a level of assurance has gained widespread
+   acceptance and should be treated as a protocol-independent concept.
+   The newly created IANA registry attempts to reflect this.
+
+
+
+Johansson                     Informational                     [Page 2]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+   Although the registry will contain URIs that reference SAML
+   Authentication Context Profiles, other protocols may use such URIs to
+   identify level of assurance definitions without relying on or
+   transmitting their SAML XML definitions.  Use of the registry by
+   protocols other than SAML is encouraged.
+
+   For instance, OpenID Connect defines the standard claim 'acr' as a
+   identifier that may reference a SAML Authentication Context Class
+   even though OpenID Connect is not itself based on XML or SAML.
+
+   Protocol designers who want to reference the registry should be aware
+   that registered LoAs may depend on assumptions that do not carry over
+   to all protocols and that such assumptions may vary among the
+   protocols for which the LoAs were originally registered.
+
+2.  Name of Registry
+
+   The name of the registry shall be "Level of Assurance (LoA) Profile",
+   in plural "Level of Assurance (LoA) Profiles".
+
+3.  Registration Template
+
+   The following information must be provided with each registration:
+
+   URI:  A URI referencing a Level of Assurance Profile.  This is the
+      registry key.
+
+   Context Class:  A valid XML schema definition for the SAML 2.0 LoA
+      Context Class fulfilling the requirements of [SAML].  The registry
+      key (the URI) is the unique identifier for the Context Class.
+
+   Name:  A string uniquely and unambiguously identifying the LoA for
+      use in protocols where URIs are not appropriate.
+
+   Informational URL:  A URL containing auxiliary information.  This URL
+      must minimally reference contact information for the
+      administrative authority of the level of assurance definition and
+      must use either the http or https scheme.
+
+   Note that it is possible for a single SAML Authentication Context
+   Class to contain definitions of multiple URIs.  In that case, a
+   separate registration is to be used for each URI.  Both the name and
+   the URI are to uniquely and unambiguously identify the LoA.  The name
+   is meant to be used in protocols where URIs are not appropriate.  In
+   addition the requester is expected to provide basic contact
+   information and the name of the organization on behalf of which the
+   LoA definition is registered.
+
+
+
+
+Johansson                     Informational                     [Page 3]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+   The name is defined by the following ABNF (as defined in RFC 5234
+   [RFC5234]):
+
+   label = ( ALPHA / DIGIT )
+   name = label 1*( label / "-" / "." / "_" )
+
+   The elements defined by the following ABNF productions represent a
+   set of reserved values for the name element and are not to be
+   registered:
+
+   reserved = loa / al / num
+   loa = ( "l" / "L" ) ( "o" / "O" ) ( "a" / "A") *DIGIT
+   al = ( "a" / "A") ( "l" / "L") *DIGIT
+   num = *DIGIT
+
+   The reason for excluding these productions is a desire to avoid a
+   race to register overly generic LoA Profiles under names like "AL1"
+   or "LOA2".
+
+3.1.  Example Registration
+
+   1.  Name of requester: J. Random User
+
+   2.  Email address of requester: jrandom@example.com
+
+   3.  Organization of requester: Example Trust Frameworks LLP
+
+   4.  Requested registration:
+
+   URI  http://foo.example.com/assurance/loa-1
+
+   Name  foo-loa-1
+
+   Informational URL  https://foo.example.com/assurance/
+
+   SAML 2.0 Authentication Context Class Definition
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <xs:schema
+       targetNamespace="http://foo.example.com/assurance/loa-1"
+       xmlns:xs="http://www.w3.org/2001/XMLSchema"
+       xmlns="http://foo.example.com/assurance/loa-1"
+       finalDefault="extension"
+       blockDefault="substitution"
+       version="2.0">
+     <xs:redefine
+        schemaLocation="saml-schema-authn-context-loa-profile.xsd">
+         <xs:annotation>
+
+
+
+Johansson                     Informational                     [Page 4]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+             <xs:documentation>
+                 Class identifier:
+                     http://foo.example.com/assurance/loa-1
+                     Defines Level 1 of the Foo Assurance Framework
+             </xs:documentation>
+         </xs:annotation>
+         <xs:complexType name="GoverningAgreementRefType">
+           <xs:complexContent>
+             <xs:restriction base="GoverningAgreementRefType">
+               <xs:attribute name="governingAgreementRef"
+                 type="xs:anyURI"
+                 fixed="https://foo.example.com/assurance/"
+                 use="required"/>
+               </xs:restriction>
+           </xs:complexContent>
+         </xs:complexType>
+     </xs:redefine>
+   </xs:schema>
+
+3.2.  Note on the Example
+
+   The example is borrowed (slightly modified) from [SAML].  The example
+   should not be registered.
+
+4.  Registration Policy
+
+   The registry is to be operated under the "Expert Review" policy from
+   RFC 5226 [RFC5226], employing a pool of experts.  IANA will be kindly
+   asked to do rough, randomized load-balancing among the experts and
+   also to perform an initial review of each submission to ensure that
+   the name and URI are unique within the registry.  The review criteria
+   are outlined below.
+
+   For registrations that reference multiple LoAs in a consistent set of
+   policies -- for instance, when a trust framework defines multiple
+   levels of assurance -- the registered LoA name and URIs should be
+   consistently named so that they can be identified as belonging to the
+   same set of registrations.  For instance, fruitLoA1, fruitLoA2, and
+   fruitLoA3 are preferred over apple, pear, and banana when these names
+   refer to a single set of policies defining three LoAs.
+
+4.1.  Reviewer Expectations
+
+   The expectation of the IANA LoA Registry is that it will contain
+   registrations of bona fide Level of Assurance Profiles while not
+   presenting a very high bar for entry.
+
+
+
+
+
+Johansson                     Informational                     [Page 5]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+   Expert reviewers are expected to verify that:
+
+   o  the registration is consistent and that the provided XML fulfills
+      the requirements of [SAML].
+
+   o  the name element is clearly associated with the registered LoA
+      Profile and is not a reserved value.
+
+   o  the URI and name elements are not already registered.
+
+   o  the Informational URL can be expected to be stable and permanent.
+
+   Note that multiple registrations may share a common Informational
+   URL.
+
+   The reviewers should exclude registrations where the name does not
+   unambiguously identify the LoA definition or where the name is a
+   simple variation on one of the reserved names.
+
+   Expert reviewers are expected to allow registrations made in good
+   faith that fulfill these requirements.
+
+5.  Registry Semantics
+
+   The intended use for this registry is to serve as a basis for
+   discovery of LoA definitions that might, for instance, be used by
+   protocol-specific (e.g., SAML 2.0 or OpenID Connect) management
+   tools.
+
+   Note that consumers of the registry, being implementations of [SAML],
+   are expected to allow configuration of LoA URIs at system deployment
+   time.  If multiple sources of LoA URIs are permitted in addition to
+   the registry (e.g., manual input), then it is important to avoid
+   collisions with URIs found in the registry.
+
+   The presence of an entry in the registry does not imply any semantics
+   or quality beyond that which results from the review done by the
+   expert reviewer as part of the registration process.
+
+6.  IANA Considerations
+
+   This document sets up a registry with IANA, making the whole document
+   a set of considerations for IANA.
+
+
+
+
+
+
+
+
+Johansson                     Informational                     [Page 6]
+
+RFC 6711                      LoA Registry                   August 2012
+
+
+7.  Security Considerations
+
+   The registry is not a federation or trust framework.  Consumers of
+   the registry are strongly advised to review the information about an
+   LoA before relying on it.
+
+8.  Acknowledgements
+
+   RL "Bob" Morgan, Scott Cantor, Lucy Lynch, and John Bradley were
+   involved in the initial discussions around this idea and contributed
+   to the semantics of the registry.  The various versions of the
+   document were socialized in the Kantara Federation Interoperability
+   WG and in other parts of the identity community.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [SAML]     Morgan, RL., Madsen, PM., and S. Cantor, "SAML V2.0
+              Identity Assurance Profiles, Version 1.0", November 2010,
+              <http://docs.oasis-open.org/security/saml/Post2.0/
+              sstc-saml-assurance-profile.html>.
+
+9.2.  Informative References
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [SP63]     NIST, "Electronic Authentication Guideline, NIST Special
+              Publication 800-63", June 2004.
+
+Author's Address
+
+   Leif Johansson
+   NORDUNet
+   Tulegatan 11
+   Stockholm
+   Sweden
+
+   EMail: leifj@nordu.net
+
+
+
+
+Johansson                     Informational                     [Page 7]
+