[要約] RFC 6711は、レベルオブアシュアランス（LoA）プロファイルのためのIANAレジストリに関するものであり、要約すると、LoAプロファイルの一貫性と一元管理を目的としています。
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
保証レベル（LoA）プロファイルのIANAレジストリ
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レジストリを確立します。レジストリは、セキュリティアサーションマークアップ言語（SAML）2.0やOpenID Connectなど、LoAコンセプトを使用するプロトコルでそのようなLoA定義を検出するための補助として使用することを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
現在、いくつかのいわゆる信頼フレームワークとIDフェデレーションが存在し、そのいくつかは1つ以上のLoAを定義しています。この仕様の目的は、そのようなLoA定義を検出できるIANAレジストリを作成することです。上記の引用は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はそれ自体がXMLまたはSAMLに基づいていない場合でも、標準クレーム「acr」を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".
レジストリの名前は、「Level of Assurance（LoA）Profile」で、複数の「Level of Assurance（LoA）Profiles」とします。
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]の要件を満たすSAML 2.0 LoAコンテキストクラスの有効な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 / "-" / "." / "_" )
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
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. 依頼者の組織：Trust Frameworks LLPの例
4. Requested registration:
4. リクエストされた登録：
URI http://foo.example.com/assurance/loa-1
Name foo-loa-1
名前foo-loa-1
Informational URL https://foo.example.com/assurance/
SAML 2.0 Authentication Context Class Definition
SAML 2.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>
<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は、同じセットに属していると識別できるように一貫して名前を付ける必要があります登録の。たとえば、fruitLoA1、fruitLoA2、fruitLoA3は、これらの名前が3つのLoAを定義する単一のポリシーセットを参照する場合、apple、pear、およびbananaよりも優先されます。
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要素と名前要素はまだ登録されていません。
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定義を明確に識別しない登録、または名前が予約済みの名前の1つの単純なバリエーションである登録を除外する必要があります。
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.
このレジストリの使用目的は、たとえば、プロトコル固有の（SAML 2.0やOpenID Connectなどの）管理ツールで使用される可能性のあるLoA定義の検出の基礎として機能することです。
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は、このアイデアに関する最初の議論に参加し、レジストリのセマンティクスに貢献しました。ドキュメントのさまざまなバージョンは、Kantara Federation Interoperability WGやアイデンティティコミュニティの他の部分で社会化されました。
[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。、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>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SP63] NIST, "Electronic Authentication Guideline, NIST Special Publication 800-63", June 2004.
[SP63] NIST、「電子認証ガイドライン、NIST Special Publication 800-63」、2004年6月。
Author's Address
著者のアドレス
Leif Johansson NORDUNet Tulegatan 11 Stockholm Sweden
Leif Johansson NORDUNet Tulegatan 11ストックホルムスウェーデン
EMail: leifj@nordu.net