[要約] RFC 8409は、セキュリティアサーションマークアップ言語(SAML)属性タイプのエンティティカテゴリに関するものです。このRFCの目的は、SAML属性を使用してエンティティのカテゴリ情報を提供し、セキュリティ上の要件を満たすための標準化を促進することです。

Independent Submission                                     I. Young, Ed.
Request for Comments: 8409                                   Independent
Category: Informational                                     L. Johansson
ISSN: 2070-1721                                                    SUNET
                                                               S. Cantor
                                                   Shibboleth Consortium
                                                             August 2018
        

The Entity Category Security Assertion Markup Language (SAML) Attribute Types

エンティティカテゴリのセキュリティアサーションマークアップ言語(SAML)属性タイプ

Abstract

概要

This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.

このドキュメントでは、2つのSAMLエンティティ属性について説明します。1つはエンティティにカテゴリメンバーシップセマンティクスを割り当てるために使用でき、もう1つはそのようなカテゴリのエンティティとの相互運用またはサポートの主張に使用するために使用できます。

This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.

この文書は、研究教育連合(REFEDS)グループのワーキンググループプロセスの成果物です。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8409.

このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8409で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. REFEDS Document Process ....................................3
   2. Notation and Conventions ........................................4
   3. Entity Category Attribute .......................................4
      3.1. Syntax .....................................................4
      3.2. Semantics ..................................................5
      3.3. Entity Category Example ....................................6
   4. Entity Category Support Attribute ...............................7
      4.1. Syntax .....................................................7
      4.2. Semantics ..................................................7
      4.3. Entity Category Support Example ............................9
   5. IANA Considerations .............................................9
   6. Security Considerations .........................................9
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................11
   Acknowledgements ..................................................12
   Authors' Addresses ................................................12
        
1. Introduction
1. はじめに

This document describes a SAML attribute called the "entity category attribute". Values of this attribute represent entity types or categories. When used with the SAML V2.0 Metadata Extension for Entity Attributes [SAML2MetadataAttr], each such entity category attribute value represents a claim that the entity thus labeled meets the requirements of, and is asserted to be a member of, the indicated category.

このドキュメントでは、「エンティティカテゴリ属性」と呼ばれるSAML属性について説明します。この属性の値は、エンティティタイプまたはカテゴリを表します。エンティティ属性のSAML V2.0メタデータ拡張[SAML2MetadataAttr]と共に使用すると、そのような各エンティティカテゴリ属性値は、このようにラベル付けされたエンティティが指定されたカテゴリの要件を満たし、そのカテゴリのメンバーであると主張されている主張を表します。

These category membership claims MAY be used by a relying party to provision policy for release of attributes from an identity provider, to influence user interface decisions such as those related to identity provider discovery, or for any other purpose. In general, the intended uses of any claim of membership in a given category will depend on the details of the category's definition and will often be included as part of that definition.

これらのカテゴリメンバーシップ要求は、IDプロバイダーからの属性のリリースに関するポリシーをプロビジョニングするため、IDプロバイダーの検出に関連するものなどのユーザーインターフェイスの決定に影響を与えるため、またはその他の目的で、依存パーティによって使用される場合があります。一般に、所定のカテゴリーのメンバーシップの請求の意図される使用は、カテゴリーの定義の詳細に依存し、多くの場合、その定義の一部として含まれます。

Entity category attribute values are URIs. Therefore, this document does not specify a controlled vocabulary for assigning such values; they may be defined by any appropriate authority without any requirement for central registration. It is anticipated that other specifications may provide management and discovery mechanisms for entity category attribute values.

エンティティカテゴリの属性値はURIです。したがって、このドキュメントでは、そのような値を割り当てるための統制語彙を指定していません。それらは、集中登録を必要とせずに、適切な当局によって定義される場合があります。他の仕様では、エンティティカテゴリの属性値の管理と検出のメカニズムが提供されることが予想されます。

This document also describes a SAML attribute called the "entity category support attribute". This attribute contains URI values that represent claims that an entity supports and/or interoperates with entities in a given category or categories. These values, defined in conjunction with specific entity category attribute values, provide entities in a category with the means to identify peer entities that wish to interact with them in a fashion described by the category specification.

このドキュメントでは、「エンティティカテゴリサポート属性」と呼ばれるSAML属性についても説明します。この属性には、エンティティが特定のカテゴリのエンティティをサポートおよび/または相互運用するクレームを表すURI値が含まれます。これらの値は、特定のエンティティカテゴリ属性値と組み合わせて定義され、カテゴリ仕様で記述された方法でやり取りするピアエンティティを識別する手段をカテゴリ内のエンティティに提供します。

This document does not specify any values for either the entity category attribute or the entity category support attribute.

このドキュメントでは、エンティティカテゴリ属性またはエンティティカテゴリサポート属性の値を指定していません。

1.1. REFEDS Document Process
1.1. REFEDSドキュメントプロセス

The Research and Education FEDerations [REFEDS] group is the voice that articulates the mutual needs of research and education identity federations worldwide. It aims to represent the requirements of research and education in the ever-growing space of access and identity management.

Research and Education Federations [REFEDS]グループは、世界中の研究および教育アイデンティティ連合の相互のニーズを明確に示す声です。アクセスとアイデンティティ管理の増大し続ける空間における研究と教育の要件を表すことを目的としています。

From time to time, REFEDS will publish a document in the RFC Series. Such documents will be published as part of the Independent Submission stream [RFC4844]; however, the REFEDS Working Group sign-off process will have been followed for these documents, as described in the REFEDS Participant's Agreement [REFEDS.agreement].

REFEDSは時折、RFCシリーズでドキュメントを公開します。このようなドキュメントは、独立提出ストリーム[RFC4844]の一部として公開されます。ただし、REFEDS参加者の合意[REFEDS.agreement]に記載されているように、これらの文書についてはREFEDSワーキンググループの承認プロセスが行われます。

This document is a product of the REFEDS Working Group process.

この文書は、REFEDSワーキンググループプロセスの成果物です。

2. Notation and Conventions
2. 表記と表記法

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

The notation "@example" is used as a shorthand for an XML attribute with attribute name "example".

「@example」という表記は、属性名が「example」のXML属性の省略形として使用されます。

3. Entity Category Attribute
3. エンティティカテゴリ属性
3.1. Syntax
3.1. 構文

Entity category attribute values MUST be URIs. Such values are also referred to as "category URIs" in this document.

エンティティカテゴリの属性値はURIである必要があります。このような値は、このドキュメントでは「カテゴリURI」とも呼ばれます。

It is RECOMMENDED that http:-scheme or https:-scheme URIs are used; it is further RECOMMENDED that a category URI resolves to a human-readable document defining the category.

http:-schemeまたはhttps:-scheme URIを使用することをお勧めします。さらに、カテゴリURIが、カテゴリを定義する人間が読めるドキュメントに解決されることが推奨されます。

Authorities defining entity categories MUST produce a specification of the entity category and SHOULD make arrangement for the category URI to resolve to the specification in human-readable form.

エンティティカテゴリを定義する機関は、エンティティカテゴリの仕様を作成する必要があり、カテゴリURIが人間が読める形式で仕様に解決されるように手配する必要があります。

Authorities defining entity categories MAY use versioning of category URIs where appropriate; if versioning is used, each version of the specification of the entity category SHOULD clearly indicate the latest version of the category URI (and hence of the specification). The specification SHOULD include a description of how the authority defining the entity category implements governance for the specification if the specification is updated.

エンティティカテゴリを定義する機関は、必要に応じてカテゴリURIのバージョン管理を使用できます。バージョニングを使用する場合、エンティティカテゴリの仕様の各バージョンは、カテゴリURI(および仕様)の最新バージョンを明確に示す必要があります(SHOULD)。仕様には、仕様が更新された場合にエンティティカテゴリを定義する機関が仕様のガバナンスを実装する方法の説明を含める必要があります(SHOULD)。

When used in SAML metadata or protocol elements, the entity category attribute MUST be encoded as a SAML 2.0 Attribute element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name http://macedir.org/entity-category.

SAMLメタデータまたはプロトコル要素で使用する場合、エンティティカテゴリ属性は、@ NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uriおよび@Name http:// macedirを使用してSAML 2.0属性要素としてエンコードする必要があります.org / entity-category。

A SAML entity is associated with one or more categories by including the Attribute element described here in the entity's metadata through use of the metadata extension defined in [SAML2MetadataAttr]. In this extension, the Attribute element is contained within an mdattr:EntityAttributes element directly contained within an md:Extensions element directly contained within the entity's md:EntityDescriptor.

SAMLエンティティは、[SAML2MetadataAttr]で定義されたメタデータ拡張を使用して、エンティティのメタデータにここで説明されているAttribute要素を含めることにより、1つ以上のカテゴリに関連付けられます。この拡張機能では、Attribute要素は、エンティティのmd:EntityDescriptor内に直接含まれているmd:Extensions要素内に直接含まれているmdattr:EntityAttributes要素内に含まれています。

The meaning of the entity category attribute is not defined by this specification if it appears anywhere else within a metadata instance or within any other XML document.

エンティティカテゴリ属性の意味は、メタデータインスタンス内または他のXMLドキュメント内の他の場所にある場合、この仕様では定義されていません。

If the entity category attribute appears more than once in the metadata for an entity, relying parties SHOULD interpret the combined set of associated attribute values as if they all appeared together within a single entity category attribute.

エンティティカテゴリ属性がエンティティのメタデータに複数回出現する場合、証明書利用者は、関連付けられた属性値の組み合わせセットを、1つのエンティティカテゴリ属性内にすべて一緒に出現するかのように解釈する必要があります(SHOULD)。

3.2. Semantics
3.2. 意味論

The presence of the entity category attribute within an entity's entity attributes represents a series of claims (one for each attribute value) that the entity is a member of each named category. The precise semantics of such a claim depend on the definition of the category itself.

エンティティのエンティティ属性内のエンティティカテゴリ属性の存在は、エンティティが各名前付きカテゴリのメンバーであるという一連のクレーム(属性値ごとに1つ)を表します。そのような主張の正確なセマンティクスは、カテゴリー自体の定義に依存します。

An entity may be claimed to be a member of more than one category. In this case, the entity is claimed to meet the requirements of each category independently unless otherwise specified by the category definitions themselves.

エンティティは複数のカテゴリのメンバーであると主張される場合があります。この場合、エンティティは、カテゴリ定義自体で特に指定されていない限り、各カテゴリの要件を個別に満たしていると主張されます。

This document intentionally does not define "category", in order to leave the concept as general as possible. However, to be useful, category definitions SHOULD include the following as appropriate:

このドキュメントでは、概念をできるだけ一般的なものにするために、「カテゴリ」を意図的に定義していません。ただし、役立つために、カテゴリ定義には必要に応じて以下を含める必要があります。

o A definition of the authorities who may validly assert membership in the category. While membership in some categories may be self-asserted informally by an entity's owner, others may need to be validated by third parties such as the entity's home federation or other registrar.

o カテゴリーのメンバーであることを正当に主張できる当局の定義。一部のカテゴリのメンバーシップは、エンティティの所有者によって非公式に自己主張される場合がありますが、エンティティのホームフェデレーションまたは他のレジストラなどのサードパーティによる検証が必要な場合があります。

o A set of criteria by which an entity's membership in the category can be objectively assessed.

o カテゴリ内のエンティティのメンバーシップを客観的に評価できる一連の基準。

o A definition of the processes by which valid authorities may determine that an entity meets the category's membership criteria.

o 有効な機関がエンティティがカテゴリのメンバーシップ基準を満たしていると判断できるプロセスの定義。

o A description of the anticipated uses for category membership by relying parties.

o 証明書利用者によるカテゴリメンバーシップの予想される用途の説明。

o A statement indicating the applicability or otherwise of membership of the entity category to different SAML role descriptors and any protocol support restrictions that may be relevant.

o さまざまなSAMLロール記述子へのエンティティカテゴリのメンバーシップの適用可能性またはその他の方法を示すステートメント、および関連するプロトコルサポート制限。

Entity categories SHOULD NOT be used to indicate the certification status of an entity regarding its conformance to the requirements of an identity assurance framework. The SAML extension defined in [SAML2IDAssuranceProfile] SHOULD be used for this purpose.

エンティティカテゴリは、アイデンティティ保証フレームワークの要件への適合に関するエンティティの認証ステータスを示すために使用してはなりません。 [SAML2IDAssuranceProfile]で定義されているSAML拡張機能は、この目的で使用する必要があります(SHOULD)。

If significant changes are made to a category definition, the new version of the category SHOULD be represented by a different category URI so that the old and new versions can be distinguished by a relying party. It is for this reason that authorities defining entity categories MAY employ some form of versioning for category URIs. When versioning is used, each version of the entity category MUST be treated as a separate URI.

カテゴリ定義に大幅な変更が加えられた場合、古いバージョンと新しいバージョンを証明書利用者が区別できるように、新しいバージョンのカテゴリを別のカテゴリURIで表す必要があります(SHOULD)。このため、エンティティカテゴリを定義する当局は、カテゴリURIに何らかの形式のバージョン管理を使用できます(MAY)。バージョン管理を使用する場合、エンティティカテゴリの各バージョンは、個別のURIとして処理する必要があります。

No ordering relation is defined for entity category attribute values. Entity category attribute values MUST be treated as opaque strings for the purpose of comparison. In particular, if the specification defining the entity category relies on versioning of the category URI, a relying party MUST NOT assume any particular ordering between different versions of the category URI. Any order between versions MUST be spelled out in the specification.

エンティティカテゴリの属性値には、順序関係は定義されていません。エンティティカテゴリの属性値は、比較のために不透明な文字列として扱う必要があります。特に、エンティティカテゴリを定義する仕様がカテゴリURIのバージョン管理に依存している場合、依存パーティは、カテゴリURIの異なるバージョン間の特定の順序を想定してはなりません。バージョン間の順序は、仕様に明記する必要があります。

3.3. Entity Category Example
3.3. エンティティカテゴリの例
   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     entityID="https://service.example.com/entity">
     <md:Extensions>
       <mdattr:EntityAttributes
         xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
         <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
           NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
           Name="http://macedir.org/entity-category">
           <AttributeValue
             >http://example.org/category/dog</AttributeValue>
           <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
         </Attribute>
       </mdattr:EntityAttributes>
     </md:Extensions>
     ...
   </md:EntityDescriptor>
        
4. Entity Category Support Attribute
4. エンティティカテゴリサポート属性
4.1. Syntax
4.1. 構文

Entity category support attribute values MUST be URIs. Such values are also referred to as "category support URIs" in this document.

エンティティカテゴリサポートの属性値はURIである必要があります。このような値は、このドキュメントでは「カテゴリサポートURI」とも呼ばれます。

It is RECOMMENDED that http:-scheme or https:-scheme URLs are used; it is further RECOMMENDED that each such value resolves to a human-readable document defining the value's semantics.

http:-schemeまたはhttps:-schemeのURLを使用することをお勧めします。さらに、そのような各値が、値のセマンティクスを定義する人間が読めるドキュメントに解決されることが推奨されます。

A given category URI MAY be associated with multiple category support URIs in order to allow for multiple forms of support, participation, or interoperation with entities in the category. The authority defining the category URI and category support URIs MUST clearly describe the relationship between (all versions of) the category URI and (all versions of) the category support URIs as applicable in the entity category specification.

カテゴリ内のエンティティとの複数の形式のサポート、参加、または相互運用を可能にするために、特定のカテゴリURIを複数のカテゴリサポートURIに関連付けることができます。カテゴリURIとカテゴリサポートURIを定義する機関は、エンティティカテゴリ仕様で適用可能なカテゴリURI(のすべてのバージョン)とカテゴリサポートURI(のすべてのバージョン)の間の関係を明確に記述する必要があります。

The entity category support attribute MUST be encoded as a SAML 2.0 Attribute element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name http://macedir.org/entity-category-support.

エンティティカテゴリサポート属性は、@ NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uriおよび@Name http://macedir.org/entity-category-supportを使用してSAML 2.0属性要素としてエンコードする必要があります。

Claims that a SAML entity implements support for one or more categories are represented by including the Attribute element described here in the entity's metadata through use of the metadata extension defined in [SAML2MetadataAttr]. In this extension, the Attribute element is contained within an mdattr:EntityAttributes element directly contained within an md:Extensions element directly contained within the entity's md:EntityDescriptor.

SAMLエンティティが1つ以上のカテゴリのサポートを実装しているという主張は、[SAML2MetadataAttr]で定義されているメタデータ拡張を使用して、ここで説明するAttribute要素をエンティティのメタデータに含めることによって表されます。この拡張機能では、Attribute要素は、エンティティのmd:EntityDescriptor内に直接含まれているmd:Extensions要素内に直接含まれているmdattr:EntityAttributes要素内に含まれています。

The meaning of the entity category support attribute is not defined by this specification if it appears anywhere else within a metadata instance or within any other XML document.

エンティティカテゴリサポート属性の意味は、メタデータインスタンス内または他のXMLドキュメント内の他の場所にある場合、この仕様では定義されていません。

If the entity category support attribute appears more than once in the metadata for an entity, relying parties SHOULD interpret the combined set of associated attribute values as if they all appeared together within a single entity category support attribute.

エンティティカテゴリサポート属性がエンティティのメタデータに複数回出現する場合、証明書利用者は、関連付けられた属性値の組み合わせセットを、1つのエンティティカテゴリサポート属性内にすべて一緒に出現するかのように解釈する必要があります(SHOULD)。

4.2. Semantics
4.2. 意味論

The presence of the entity category support attribute within an entity's entity attributes represents a series of claims (one for each attribute value) that the entity supports peer entities in a category in a particular fashion. The precise semantics of such a claim depend on the definition of the category support URI itself. Category support claims will often be defined to be self-asserted.

エンティティのエンティティ属性内のエンティティカテゴリサポート属性の存在は、エンティティが特定の方法でカテゴリのピアエンティティをサポートする一連のクレーム(属性値ごとに1つ)を表します。このようなクレームの正確なセマンティクスは、カテゴリサポートURI自体の定義に依存します。カテゴリサポートの主張は、多くの場合、自己主張されるように定義されます。

An entity may be claimed to support more than one category. In this case, the entity is claimed to meet the support requirements of each category independently unless otherwise specified by the category definitions themselves.

エンティティは複数のカテゴリをサポートすると主張される場合があります。この場合、エンティティは、カテゴリ定義自体で特に指定されていない限り、各カテゴリのサポート要件を個別に満たしていると主張されます。

This document intentionally does not define "support" for a category, in order to leave the concept as general as possible. It is assumed that entity category definitions MAY define one or more category support URIs signifying particular definitions for "support" by peers as motivated by use cases arising from the definition of the category itself.

このドキュメントでは、概念をできるだけ一般的なものにするために、カテゴリの「サポート」を意図的に定義していません。エンティティカテゴリ定義は、カテゴリ自体の定義から生じるユースケースによって動機付けされた、ピアによる「サポート」の特定の定義を示す1つ以上のカテゴリサポートURIを定義する場合があると想定されます。

A common case is expected to be the definition of a single category support URI whose value is identical to the category URI.

一般的なケースは、値がカテゴリURIと同一である単一のカテゴリサポートURIの定義であると予想されます。

If significant changes are made to a category support definition, the new version SHOULD be represented by a different category support URI so that the old and new versions can be distinguished by a relying party. It is for this reason that authorities defining entity categories support MAY employ some form of versioning. When versioning is used, each version of the category support URI MUST be treated as a separate URI.

カテゴリサポート定義に大幅な変更が加えられた場合、新バージョンは別のカテゴリサポートURIで表す必要があるため(SHOULD)、古いバージョンと新しいバージョンを証明書利用者が区別できます。エンティティカテゴリをサポートする当局が何らかのバージョン管理を採用する可能性があるのはこのためです。バージョン管理を使用する場合、カテゴリサポートURIの各バージョンを個別のURIとして処理する必要があります。

No ordering relation is defined for entity category support attribute values. Entity category support attribute values MUST be treated as opaque strings for the purpose of comparison. In particular, if the specification defining the category support URIs relies on versioning, a relying party MUST NOT assume any particular ordering between different versions of the category support URI. Any order between versions MUST be spelled out in the specification.

エンティティカテゴリサポート属性値には、順序関係は定義されていません。エンティティカテゴリサポートの属性値は、比較のために不透明な文字列として処理する必要があります。特に、カテゴリサポートURIを定義する仕様がバージョン管理に依存している場合、依存パーティは、カテゴリサポートURIの異なるバージョン間の特定の順序付けを想定してはなりません。バージョン間の順序は、仕様に明記する必要があります。

4.3. Entity Category Support Example
4.3. エンティティカテゴリサポートの例
   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     entityID="https://idp.example.edu/entity">
     <md:Extensions>
       <mdattr:EntityAttributes
         xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
         <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
           NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
           Name="http://macedir.org/entity-category-support">
           <AttributeValue
             >http://example.org/category/dog/basic</AttributeValue>
           <AttributeValue
             >http://example.org/category/dog/advanced</AttributeValue>
           <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
         </Attribute>
       </mdattr:EntityAttributes>
     </md:Extensions>
     ...
   </md:EntityDescriptor>
        
5. IANA Considerations
5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. Security Considerations
6. セキュリティに関する考慮事項

The presence of the entity category attribute within an entity's entity attributes represents a series of claims (one for each attribute value) that the entity is a member of the named categories. Before accepting and acting on such claims, any relying party needs to establish, at a level of assurance sufficient for the intended use, a chain of trust concluding that the claim is justified.

エンティティのエンティティ属性内のエンティティカテゴリ属性の存在は、エンティティが名前付きカテゴリのメンバーであるという一連のクレーム(属性値ごとに1つ)を表します。そのようなクレームを受け入れて行動する前に、依存する当事者は、意図された使用に十分なレベルの保証で、クレームが正当であると結論付ける信頼の連鎖を確立する必要があります。

Some of the elements in such a chain of trust might include:

このような信頼の連鎖の要素には、次のようなものがあります。

o The integrity of the metadata delivered to the relying party, for example, as assured by a digital signature.

o たとえば、デジタル署名によって保証される、依存パーティに配信されるメタデータの整合性。

o If the entity category attribute is carried within a signed assertion, the assertion itself must be evaluated.

o エンティティカテゴリ属性が署名付きアサーション内で運ばれる場合、アサーション自体を評価する必要があります。

o The policies and procedures of the immediate source of the metadata, in particular, any procedures the immediate source has with regard to aggregation of metadata from other sources.

o メタデータの直接のソースのポリシーと手順、特に、直接のソースが他のソースからのメタデータの集約に関して持っているすべての手順。

o The policies and procedures implemented by agents along the publication path from the original metadata registrar. This may be determined by examination of the published procedures of each agent in turn or may be simplified if the entity metadata includes publication path metadata in mdrpi:PublicationPath elements as described in Section 2.3.1 of [SAML2MetadataRPI].

o 元のメタデータレジストラからの公開パスに沿ってエージェントによって実装されたポリシーと手順。 [SAML2MetadataRPI]のセクション2.3.1で説明されているように、エンティティメタデータにmdrpi:PublicationPath要素のパブリケーションパスメタデータが含まれている場合、これは各エージェントの公開手順を順番に調べることで決定できます。

o The policies and procedures implemented by the original metadata registrar. The registrar's identity may be known implicitly or may be determined from the entity metadata if it includes an mdrpi:RegistrationInfo element and corresponding @registrationAuthority as described in Section 2.1.1 of [SAML2MetadataRPI].

o 元のメタデータレジストラによって実装されたポリシーと手順。 [SAML2MetadataRPI]のセクション2.1.1で説明されているように、レジストラのIDは暗黙的に知られているか、mdrpi:RegistrationInfo要素と対応する@registrationAuthorityが含まれている場合はエンティティメタデータから決定されます。

o The definition of the category itself, in particular, any statements it makes about whether membership of the category may be self-asserted or may only be asserted by particular authorities.

o カテゴリー自体の定義、特に、カテゴリーのメンバーシップが自己主張できるか、または特定の当局によってのみ主張されるかどうかについての説明。

Although entity category support attribute values will often be defined as self-asserted claims by the containing entity, the provenance of the metadata remains relevant to a relying party's decision to accept a claim of support as legitimate, and the specific definition of a support claim will influence the assurance required to act on it.

エンティティカテゴリのサポート属性値は多くの場合、包含エンティティによって自己主張されたクレームとして定義されますが、メタデータの出所は、正当なサポートのクレームを受け入れるという依拠当事者の決定に関連し続け、サポートクレームの具体的な定義はそれに基づいて行動するために必要な保証に影響を与える。

The conclusion that a claim of category membership or support is justified and should be acted upon may require a determination of the origin of the claim. This may not be necessary if the immediate source of the metadata is trusted to such an extent that the trust calculation is essentially delegated to it.

カテゴリーのメンバーシップまたはサポートの主張は正当化され、実行されるべきであるという結論は、主張の出所の決定を必要とする場合があります。メタデータの直接のソースが、信頼の計算が本質的に委任される程度に信頼されている場合、これは必要ない場合があります。

In many cases, a claim will be included in an entity's metadata by the original metadata registrar on behalf of the entity's owner, and the mdrpi:RegistrationInfo element's @registrationAuthority is available to carry the registrar's identity. However, any agent that is part of the chain of custody between the original registrar and the final relying party may have added, removed, or transformed claims according to local policy. For example, an agent charged with redistributing metadata may remove claims it regards as untrustworthy or add others that were not already present if they have value to its intended audience.

多くの場合、クレームはエンティティの所有者に代わって元のメタデータレジストラによってエンティティのメタデータに含まれ、mdrpi:RegistrationInfo要素の@registrationAuthorityはレジストラのIDを保持するために使用できます。ただし、元のレジストラと最終的な依存パーティとの間の一連の管理の一部であるエージェントは、ローカルポリシーに従ってクレームを追加、削除、または変換した可能性があります。たとえば、メタデータの再配布を担当するエージェントは、信頼できないと見なす申し立てを削除したり、意図した対象者に価値がある場合はまだ存在しない他の人を追加したりできます。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[SAML2MetadataAttr] Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity Attributes Version 1.0", August 2009, <http://docs.oasis-open.org/security/saml/Post2.0/ sstc-metadata-attr-cs-01.pdf>.

[SAML2MetadataAttr] Cantor、S.、Ed。、 "SAML V2.0 Metadata Extension for Entity Attributes Version 1.0"、August 2009、<http://docs.oasis-open.org/security/saml/Post2.0/ sstc -metadata-attr-cs-01.pdf>。

[SAML2MetadataRPI] La Joie, C., Ed., "SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0", April 2012, <http://docs.oasis-open.org/ security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/ saml-metadata-rpi-v1.0-cs01.pdf>.

[SAML2MetadataRPI] La Joie、C。、編、「SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0」、2012年4月、<http://docs.oasis-open.org/security/saml/Post2。 0 / saml-metadata-rpi / v1.0 / cs01 / saml-metadata-rpi-v1.0-cs01.pdf>。

7.2. Informative References
7.2. 参考引用

[REFEDS] "Research and Education FEDerations (REFEDS) Group", <http://www.refeds.org/>.

[REFEDS] "Research and Education Federations(REFEDS)Group"、<http://www.refeds.org/>。

[REFEDS.agreement] Research and Education Federations, "REFEDS Participant's Agreement", <https://refeds.org/about/refeds-participants-agreement>.

[REFEDS.agreement] Research and Education Federations、「REFEDS Participant's Agreement」、<https://refeds.org/about/refeds-participants-agreement>。

[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.

[RFC4844]ダイグル、L。、エド。およびインターネットアーキテクチャボード、「The RFC Series and RFC Editor」、RFC 4844、DOI 10.17487 / RFC4844、2007年7月、<https://www.rfc-editor.org/info/rfc4844>。

[SAML2IDAssuranceProfile] Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed., "SAML V2.0 Identity Assurance Profiles Version 1.0", November 2010, <http://docs.oasis-open.org/security/saml/ Post2.0/sstc-saml-assurance-profile-cs-01.pdf>.

[SAML2IDAssuranceProfile] Morgan、RL。、Ed。、Madsen、P.、Ed。、And S. Cantor、Ed。、 "SAML V2.0 Identity Assurance Profiles Version 1.0"、2010年11月、<http://docs.oasis -open.org/security/saml/ Post2.0 / sstc-saml-assurance-profile-cs-01.pdf>。

Acknowledgements

謝辞

This work has been a collaborative effort within the REFEDS and MACE-Dir communities. Special thanks to the following individuals (in no particular order):

この作業は、REFEDSおよびMACE-Dirコミュニティ内での共同作業です。以下の個人に特に感謝します(順不同)。

o RL 'Bob' Morgan

o RLボブモーガン

o Ken Klingenstein

o けん Kぃんげんsていん

o Keith Hazelton

o キース・ヘーゼルトン

o Steven Olshansky

o スティーブン・オルシャンスキー

o Mikael Linden

o ミカエル・リンデン

o Nicole Harris

o ニコール・ハリス

o Tom Scavo

o トム・スカボ

Authors' Addresses

著者のアドレス

Ian A. Young (editor) Independent

Ian A. Young(編集者)独立

   Email: ian@iay.org.uk
        

Leif Johansson SUNET

レイフヨハンソンSUNET

   Email: leifj@sunet.se
        

Scott Cantor Shibboleth Consortium

スコットカンターシボレスコンソーシアム

   Email: cantor.2@osu.edu