idnits 2.17.1 draft-johansson-loa-registry-01.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 date (April 14, 2011) is 4761 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Johansson 3 Internet-Draft NORDUNet 4 Intended status: Informational April 14, 2011 5 Expires: October 16, 2011 7 An IANA registry for SAML 2.0 Level of Assurance Context Classes 8 draft-johansson-loa-registry-01 10 Abstract 12 This document establishes an IANA registry for Level of Assurance 13 Context Classes for SAML 2.0. The registry is intended to be used as 14 an aid to discovering such LoA 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 October 16, 2011. 39 Copyright Notice 41 Copyright (c) 2011 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 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Name of Registry . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Registration Template . . . . . . . . . . . . . . . . . . . . . 3 59 4. Registration Policy . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Reviewer Expectations . . . . . . . . . . . . . . . . . . . 4 61 4.2. Designated Experts Pool . . . . . . . . . . . . . . . . . . 4 62 5. Registry Semantics . . . . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 9.1. since -00 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 10. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 This document establishes an IANA registry for Level of Assurance 74 Context Profiles for SAML 2.0. Such objects are XML schema 75 definitions that fulfil the requirements of sstc-saml-loa- 76 authncontext-profile-draft-01 77 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. Quoting from 78 this specification we find the following definition of the concept of 79 level of assurance: 81 _Many existing (and potential) SAML federation deployments have 82 adopted a "levels of assurance" (or LOA) model for categorizing the 83 wide variety of authentication methods into a small number of levels, 84 typically based on some notion of the strength of the authentication. 85 Federation members (service providers or "relying parties") then 86 decide which level of assurance is required to access specific 87 protected resources, based on some assessment of "value" or "risk"._ 89 Several so called trust frameworks and identity federations now 90 exist, some of which define one or more LoAs. The purpose of this 91 specification is to create an IANA registry where such LoA 92 definitions can be discovered. 94 Although the registry will contain URIs that reference SAML 95 Authentication Context Profiles other protocols MAY use such URIs to 96 represent levels of assurance definitions without relying on their 97 SAML XML definitions. Use of the registry by protocols other than 98 SAML is encouraged. 100 2. Name of Registry 102 The name of the registry shall be "SAML 2.0 LoA Context Class", in 103 plural "SAML LoA Context Classes". The term LoA is an abbreviation 104 of Level of Assurance. 106 3. Registration Template 108 The following information MUST be provided with each registration: 110 URI: A URI referencing a SAML 2.0 LoA Context Class. This is the 111 registry key. 113 Context Class: A valid XML schema definition for the SAML 2.0 LoA 114 Context Class fulfilling the requirements of sstc-saml-loa- 115 authncontext-profile-draft-01 116 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. 118 Informational URL: A URL containing auxilliary information. This 119 URL MUST minimally reference contact information for the 120 administrative authority of the level of assurance definition. 122 Note that it is not uncommon for a single XML Schema to contain 123 definitions of multiple URIs. In that case the registration MUST be 124 repeated for each URI. Since the registry key (the URI) is unique by 125 design there is no need for namespace management for this registry. 127 4. Registration Policy 129 The registry is to be operated under the "Designated Expert Review" 130 policy from RFC5226 [RFC5226] employing a pool of experts. IANA is 131 kindly asked to do rough randomized load-balancing among the experts. 132 The initial pool of expert and the review criteria are outlined 133 below. 135 4.1. Reviewer Expectations 137 The of the IANA LoA Registry is that it contain bona fide SAML 2.0 138 LoA Context Class definitions while not presenting a very high bar 139 for entry. Expert reviewers SHOULD NOT place undue value in any 140 percieved or actual quality of the associated trust framework or 141 federation and SHOULD only exclude such registrations that in the 142 view of the experts do not represent bona fide attempts at defining 143 an LoA. 145 The designated experts are also expected to verify that the 146 registration is consistent and that the provided XML fulfills the 147 requirements of sstc-saml-loa-authncontext-profile-draft-01 148 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. 150 4.2. Designated Experts Pool 152 TBD 154 5. Registry Semantics 156 The intended use for this registry is to serve as a basis for 157 discovery of LoA definitions that might for instance be used by SAML 158 management tools. Consumers of the registry MUST NOT treat it as a 159 complete list of all existing LoA definitions and MUST provide a way 160 for the user to provide additional LoA Context Class definitions by 161 other means. It is not expected that all LoA definitions will be 162 contained in this registry. 164 The presense of an entry in the registy MUST NOT be taken to imply 165 any semantics beyond the review done by the expert reviewers as part 166 of the registration process. 168 6. IANA Considerations 170 This document sets up a registry with IANA making the whole document 171 a set of considerations for IANA. 173 7. Security Considerations 175 An implementor of MUST NOT treat the registry as a trust framework or 176 federation and MUST NOT make any assumptions about the properties of 177 any of the listed level of assurance URIs or their associated trust 178 frameworks or federations based on their presense in the IANA 179 registry. 181 8. Acknowledgements 183 Bob 'RL' Morgan, Scott Cantor, Lucy Lynch and John Bradley were 184 involved in the initial discussions around this idea and contributed 185 to the semantics of the registry. 187 9. Changes 189 Note to the RFC editor: This section should be removed before 190 publication. 192 9.1. since -00 194 o Clarified the security considerations wrt the status of the IANA 195 registry. 197 o Text in the introduction that explains that the registry can be 198 used by other protocols than SAML and that this is encouraged. 200 10. Normative References 202 [OASIS.sstc.saml-loa-authncontext-profile-draft-01] 203 Tiffany, E., Madsen, P., and S. Cantor, "Level of 204 Assurance Authentication Context Profiles for SAML 2.0", 205 July 2008. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 211 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 212 May 2008. 214 Author's Address 216 Leif Johansson 217 NORDUNet 218 Tulegatan 11 219 Stockholm 220 Sweden 222 Email: leifj@nordu.net