idnits 2.17.1 draft-johansson-loa-registry-02.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 (June 25, 2011) is 4687 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 June 25, 2011 5 Expires: December 27, 2011 7 An IANA registry for SAML 2.0 Level of Assurance Context Classes 8 draft-johansson-loa-registry-02 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 December 27, 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 . . . . . . . . . . . . . . . . . . 5 62 5. Registry Semantics . . . . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 9.1. since -00 . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9.2. since -01 . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 This document establishes an IANA registry for Level of Assurance 75 Context Profiles for SAML 2.0. Such objects are XML schema 76 definitions that fulfil the requirements of sstc-saml-loa- 77 authncontext-profile-draft-01 78 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. Quoting from 79 this specification we find the following definition of the concept of 80 level of assurance: 82 _Many existing (and potential) SAML federation deployments have 83 adopted a "levels of assurance" (or LOA) model for categorizing the 84 wide variety of authentication methods into a small number of levels, 85 typically based on some notion of the strength of the authentication. 86 Federation members (service providers or "relying parties") then 87 decide which level of assurance is required to access specific 88 protected resources, based on some assessment of "value" or "risk"._ 90 Several so called trust frameworks and identity federations now 91 exist, some of which define one or more LoAs. The purpose of this 92 specification is to create an IANA registry where such LoA 93 definitions can be discovered. 95 Although the registry will contain URIs that reference SAML 96 Authentication Context Profiles other protocols MAY use such URIs to 97 represent levels of assurance definitions without relying on their 98 SAML XML definitions. Use of the registry by protocols other than 99 SAML is encouraged. 101 2. Name of Registry 103 The name of the registry shall be "SAML 2.0 LoA Context Class", in 104 plural "SAML LoA Context Classes". The term LoA is an abbreviation 105 of Level of Assurance. 107 3. Registration Template 109 The following information MUST be provided with each registration: 111 URI: A URI referencing a SAML 2.0 LoA Context Class. This is the 112 registry key. 114 Context Class: A valid XML schema definition for the SAML 2.0 LoA 115 Context Class fulfilling the requirements of sstc-saml-loa- 116 authncontext-profile-draft-01 117 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. 119 Name: A string uniquely identifying the LoA for use in protocols 120 where URIs are not appropriate. 122 Informational URL: A URL containing auxilliary information. This 123 URL MUST minimally reference contact information for the 124 administrative authority of the level of assurance definition. 126 Note that it is not uncommon for a single XML Schema to contain 127 definitions of multiple URIs. In that case the registration MUST be 128 repeated for each URI. Both the name and the URI must uniquely 129 identify the LoA. The name is meant to be used in protocols where 130 URIs are not appropriate. 132 The name must fulfill the following ABNF: 133 label = ( ALPHA / DIGIT ) 134 name = label 1*( label / '-' / '.' / '_' ) 136 The following ABNF productions represent reserved values and names 137 matching any of these productions MUST NOT be present in any 138 registration: 139 reserved = loa / al 140 loa = ( 'l' / 'L' ) ( 'o' / 'O' ) ( 'a' / 'A') *DIGIT 141 al = ( 'a' / 'A') ( 'l' / 'L') *DIGIT 143 4. Registration Policy 145 The registry is to be operated under the "Designated Expert Review" 146 policy from RFC5226 [RFC5226] employing a pool of experts. IANA is 147 kindly asked to do rough randomized load-balancing among the experts 148 and also do an initial review of each submission to ensure that the 149 name is unique within the registry.The initial pool of expert and the 150 review criteria are outlined below. 152 4.1. Reviewer Expectations 154 The of the IANA LoA Registry is that it contain bona fide SAML 2.0 155 LoA Context Class definitions while not presenting a very high bar 156 for entry. Expert reviewers SHOULD NOT place undue value in any 157 percieved or actual quality of the associated trust framework or 158 federation and SHOULD only exclude such registrations that in the 159 view of the experts do not represent bona fide attempts at defining 160 an LoA. 162 The designated experts are also expected to verify that the 163 registration is consistent and that the provided XML fulfills the 164 requirements of sstc-saml-loa-authncontext-profile-draft-01 165 [OASIS.sstc.saml-loa-authncontext-profile-draft-01]. 167 4.2. Designated Experts Pool 169 TBD 171 5. Registry Semantics 173 The intended use for this registry is to serve as a basis for 174 discovery of LoA definitions that might for instance be used by SAML 175 management tools. Consumers of the registry MUST NOT treat it as a 176 complete list of all existing LoA definitions and MUST provide a way 177 for the user to provide additional LoA Context Class definitions by 178 other means. It is not expected that all LoA definitions will be 179 contained in this registry. 181 The presense of an entry in the registy MUST NOT be taken to imply 182 any semantics beyond the review done by the expert reviewers as part 183 of the registration process. 185 6. IANA Considerations 187 This document sets up a registry with IANA making the whole document 188 a set of considerations for IANA. 190 7. Security Considerations 192 An implementor of MUST NOT treat the registry as a trust framework or 193 federation and MUST NOT make any assumptions about the properties of 194 any of the listed level of assurance URIs or their associated trust 195 frameworks or federations based on their presense in the IANA 196 registry. 198 8. Acknowledgements 200 Bob 'RL' Morgan, Scott Cantor, Lucy Lynch and John Bradley were 201 involved in the initial discussions around this idea and contributed 202 to the semantics of the registry. 204 9. Changes 206 Note to the RFC editor: This section should be removed before 207 publication. 209 9.1. since -00 211 o Clarified the security considerations wrt the status of the IANA 212 registry. 214 o Text in the introduction that explains that the registry can be 215 used by other protocols than SAML and that this is encouraged. 217 9.2. since -01 219 o Allow for registration of short identifiers. 221 10. Normative References 223 [OASIS.sstc.saml-loa-authncontext-profile-draft-01] 224 Tiffany, E., Madsen, P., and S. Cantor, "Level of 225 Assurance Authentication Context Profiles for SAML 2.0", 226 July 2008. 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, March 1997. 231 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 232 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 233 May 2008. 235 Author's Address 237 Leif Johansson 238 NORDUNet 239 Tulegatan 11 240 Stockholm 241 Sweden 243 Email: leifj@nordu.net