Internet Engineering Task Force (IETF) L. Johansson
Request for Comments: 6711 NORDUNet
Category: Informational August 2012
ISSN: 2070-1721
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
IANA保证水平（LoA）档案登记册
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.
本文件为保证水平（LoA）档案建立了IANA登记册。该注册表旨在帮助在使用LoA概念的协议中发现此类LoA定义，包括安全断言标记语言（SAML）2.0和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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
This document establishes an IANA registry for Level of Assurance (LoA) Profiles.
本文件为保证水平（LoA）档案建立了IANA登记册。
[SAML] provides the following definition of the concept of "level of assurance":
[SAML]对“保证水平”的概念作了如下定义：
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".
许多现有（和潜在）SAML联合部署都采用了“保证级别”（或LOA）模型，用于将各种各样的身份验证方法划分为少量级别，通常基于身份验证强度的一些概念。然后，联合会成员（服务提供商或“依赖方”）根据对“价值”或“风险”的某些评估，决定访问特定受保护资源所需的保证级别。
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.
RFC 4949[RFC4949]中给出了“保证水平”的另一个定义，该定义还确定了NIST特别出版物系列中此类概要的根源，特别是SP 800-63[SP63]。保证级别配置文件用于各种协议，包括安全断言标记语言（SAML）2.0版和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.
现在存在一些所谓的信任框架和身份联盟，其中一些定义了一个或多个LOA。本规范的目的是创建一个IANA注册表，在该注册表中可以发现此类LoA定义。虽然上述引用引用了SAML，但保证级别的概念已得到广泛接受，应被视为独立于协议的概念。新创建的IANA注册表试图反映这一点。
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.
尽管注册表将包含引用SAML身份验证上下文概要文件的URI，但其他协议可能会使用此类URI来标识保证级别定义，而无需依赖或传输其SAML XML定义。鼓励通过SAML以外的协议使用注册表。
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.
例如，OpenID Connect将标准声明“acr”定义为一个标识符，该标识符可以引用SAML身份验证上下文类，即使OpenID Connect本身并不基于XML或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.
想要参考注册中心的协议设计者应意识到，注册的LOA可能依赖于不适用于所有协议的假设，并且这些假设可能因最初注册LOA的协议而异。
The name of the registry shall be "Level of Assurance (LoA) Profile", in plural "Level of Assurance (LoA) Profiles".
注册处的名称应为“保证等级（LoA）简介”，复数形式为“保证等级（LoA）简介”。
The following information must be provided with each registration:
每次注册必须提供以下信息：
URI: A URI referencing a Level of Assurance Profile. This is the registry key.
URI：引用保证级别概要文件的URI。这是注册表项。
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.
上下文类：满足[SAML]要求的SAML2.0LOA上下文类的有效XML模式定义。注册表项（URI）是上下文类的唯一标识符。
Name: A string uniquely and unambiguously identifying the LoA for use in protocols where URIs are not appropriate.
名称：一个字符串，唯一且明确地标识在URI不合适的协议中使用的LoA。
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.
信息URL：包含辅助信息的URL。此URL必须至少引用保证级别定义的管理机构的联系信息，并且必须使用http或https方案。
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.
请注意，单个SAML身份验证上下文类可能包含多个URI的定义。在这种情况下，将为每个URI使用单独的注册。名称和URI都要唯一且明确地标识LoA。该名称用于URI不合适的协议中。此外，请求者还应提供基本联系信息以及LoA定义注册代表的组织名称。
The name is defined by the following ABNF (as defined in RFC 5234 [RFC5234]):
名称由以下ABNF定义（如RFC 5234[RFC5234]中所定义）：
label = ( ALPHA / DIGIT )
name = label 1*( label / "-" / "." / "_" )
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:
以下ABNF产品定义的元素表示name元素的一组保留值，不需要注册：
reserved = loa / al / num
loa = ( "l" / "L" ) ( "o" / "O" ) ( "a" / "A") *DIGIT
al = ( "a" / "A") ( "l" / "L") *DIGIT
num = *DIGIT
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".
排除这些产品的原因是希望避免在“AL1”或“LOA2”等名称下注册过于通用的LoA配置文件。
1. Name of requester: J. Random User
1. 请求者姓名：J.随机用户
2. Email address of requester: jrandom@example.com
2. 请求者的电子邮件地址：jrandom@example.com
3. Organization of requester: Example Trust Frameworks LLP
3. 请求者的组织：示例信任框架LLP
4. Requested registration:
4. 申请注册：
URI http://foo.example.com/assurance/loa-1
URI http://foo.example.com/assurance/loa-1
Name foo-loa-1
名称foo-loa-1
Informational URL https://foo.example.com/assurance/
Informational URL https://foo.example.com/assurance/
SAML 2.0 Authentication Context Class Definition
SAML2.0身份验证上下文类定义
<?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>
<?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>
<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>
<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>
The example is borrowed (slightly modified) from [SAML]. The example should not be registered.
该示例从[SAML]借用（稍加修改）。不应注册该示例。
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.
登记处将根据RFC 5226[RFC5226]的“专家审查”政策运作，雇用一批专家。请IANA在专家之间进行粗略、随机的负载平衡，并对每次提交进行初步审查，以确保名称和URI在注册表中是唯一的。审查标准概述如下。
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.
对于在一组一致的策略中引用多个LoA的注册（例如，当一个信任框架定义了多个保证级别时），注册的LoA名称和URI应一致命名，以便可以将它们标识为属于同一组注册。例如，当这些名称指的是定义三个LOA的一组政策时，与苹果、梨和香蕉相比，更倾向于使用FROUTLOA1、FROUTLOA2和FROUTLOA3。
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.
IANA LoA注册处的期望是，它将包含真实保证水平档案的注册，同时不会提供很高的进入门槛。
Expert reviewers are expected to verify that:
专家审评员应核实：
o the registration is consistent and that the provided XML fulfills the requirements of [SAML].
o 注册是一致的，并且提供的XML满足[SAML]的要求。
o the name element is clearly associated with the registered LoA Profile and is not a reserved value.
o name元素显然与注册的LoA概要文件关联，并且不是保留值。
o the URI and name elements are not already registered.
o URI和name元素尚未注册。
o the Informational URL can be expected to be stable and permanent.
o 信息URL应该是稳定和永久的。
Note that multiple registrations may share a common Informational URL.
请注意，多个注册可能共享一个公共信息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.
如果名称不能明确标识LoA定义，或者名称是保留名称之一的简单变体，则审核人应排除注册。
Expert reviewers are expected to allow registrations made in good faith that fulfill these requirements.
专家评审员应允许善意注册，以满足这些要求。
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.
此注册表的预期用途是作为发现LoA定义的基础，例如，协议特定（如SAML 2.0或OpenID Connect）管理工具可能会使用这些定义。
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.
请注意，作为[SAML]实现的注册表使用者，预计将允许在系统部署时配置LoA URI。如果除了注册表之外还允许多个LoA URI源（例如，手动输入），那么避免与注册表中的URI发生冲突是很重要的。
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.
登记册中的条目并不意味着任何语义或质量超出了专家审评员作为登记过程一部分所做审评的结果。
This document sets up a registry with IANA, making the whole document a set of considerations for IANA.
本文档为IANA建立了一个注册表，使整个文档成为IANA的一组考虑事项。
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.
注册表不是联合或信任框架。强烈建议注册处的消费者在使用LoA之前，先查看有关LoA的信息。
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.
RL“Bob”Morgan、Scott Cantor、Lucy Lynch和John Bradley参与了关于这个想法的初步讨论，并对注册表的语义做出了贡献。该文件的各种版本在坎塔拉联邦互操作性工作组和身份社区的其他部分进行了社交。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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>.
[SAML]Morgan，RL.，Madsen，PM.，和S.Cantor，“SAML V2.0身份保证概要，版本1.0”，2010年11月<http://docs.oasis-open.org/security/saml/Post2.0/ sstc saml assurance profile.html>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[SP63] NIST, "Electronic Authentication Guideline, NIST Special Publication 800-63", June 2004.
[SP63]NIST，“电子认证指南，NIST特别出版物800-63”，2004年6月。
Author's Address
作者地址
Leif Johansson NORDUNet Tulegatan 11 Stockholm Sweden
莱夫·约翰森·诺杜内特·图莱坦11瑞典斯德哥尔摩
EMail: leifj@nordu.net
EMail: leifj@nordu.net