idnits 2.17.1 draft-young-entity-category-05.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 (July 17, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational L. Johansson 5 Expires: January 18, 2018 SUNET 6 S. Cantor 7 Shibboleth Consortium 8 July 17, 2017 10 The Entity Category SAML Attribute Types 11 draft-young-entity-category-05 13 Abstract 15 This document describes a SAML entity attribute which can be used to 16 assign category membership semantics to an entity, and a second 17 attribute for use in claiming interoperation with or support for 18 entities in such categories. 20 This document is a product of the Research and Education Federations 21 (REFEDS) Working Group process. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 18, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. REFEDS Document Process . . . . . . . . . . . . . . . . . 3 56 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 3 57 3. Entity Category Attribute . . . . . . . . . . . . . . . . . . 4 58 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Entity Category Example . . . . . . . . . . . . . . . . . 5 61 4. Entity Category Support Attribute . . . . . . . . . . . . . . 6 62 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Entity Category Support Example . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 71 Appendix B. Change Log (to be removed by RFC Editor before 72 publication) . . . . . . . . . . . . . . . . . . . . 11 73 B.1. Since draft-young-entity-category-04 . . . . . . . . . . 11 74 B.2. Since draft-young-entity-category-03 . . . . . . . . . . 11 75 B.3. Since draft-young-entity-category-02 . . . . . . . . . . 11 76 B.4. Since draft-young-entity-category-01 . . . . . . . . . . 12 77 B.5. Since draft-young-entity-category-00 . . . . . . . . . . 12 78 B.6. Since draft-macedir-entity-category . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document describes a SAML attribute, referred to here as the 84 "entity category attribute", values of which represent entity types 85 or categories. When used with the SAML V2.0 Metadata Extension for 86 Entity Attributes [SAML2MetadataAttr] each such entity category 87 attribute value represents a claim that the entity thus labelled 88 meets the requirements of, and is asserted to be a member of, the 89 indicated category. 91 These category membership claims MAY be used by a relying party to 92 provision policy for release of attributes from an identity provider, 93 to influence user interface decisions such as those related to 94 identity provider discovery, or for any other purpose. In general, 95 the intended uses of any claim of membership in a given category will 96 depend on the details of the category's definition, and will often be 97 included as part of that definition. 99 Entity category attribute values are URIs, and this document does not 100 specify a controlled vocabulary. Category URIs may therefore be 101 defined by any appropriate authority without any requirement for 102 central registration. It is anticipated that other specifications 103 may provide management and discovery mechanisms for entity category 104 attribute values. 106 A second SAML attribute, referred to here as the "entity category 107 support attribute", contains URI values which represent claims that 108 an entity supports and/or interoperates with entities in a given 109 category or categories. These values, defined in conjunction with 110 specific entity category values, provide entities in a category with 111 the means to identify peer entities that wish to interact with them 112 in category-specific fashion. 114 This document does not specify any values either for the entity 115 category attribute or for the entity category support attribute. 117 1.1. REFEDS Document Process 119 The Research and Education Federations group ([REFEDS]) is the voice 120 that articulates the mutual needs of research and education identity 121 federations worldwide. It aims to represent the requirements of 122 research and education in the ever-growing space of access and 123 identity management. 125 From time to time REFEDS will wish to publish a document in the 126 Internet RFC series. Such documents will be published as part of the 127 RFC Independent Submission Stream [RFC4844]; however the REFEDS 128 working group sign-off process will have been followed for these 129 documents, as described in the REFEDS Participant's Agreement 130 [REFEDS.agreement]. 132 This document is a product of the REFEDS Working Group process. 134 2. Notation and Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [BCP14]. 140 3. Entity Category Attribute 142 3.1. Syntax 144 Entity category attribute values MUST be URIs. It is RECOMMENDED 145 that http:-scheme or https:-scheme URLs are used, and further 146 RECOMMENDED that each such value resolves to a human-readable 147 document defining the category. 149 The entity category attribute MUST be encoded as a SAML 2.0 Attribute 150 element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname- 151 format:uri and @Name http://macedir.org/entity-category. 153 A SAML entity is associated with one or more categories by including 154 the Attribute element described here in the entity's metadata through 155 use of the [SAML2MetadataAttr] metadata extension, in which the 156 Attribute element is contained within an mdattr:EntityAttributes 157 element directly contained within an md:Extensions element directly 158 contained within the entity's md:EntityDescriptor. 160 The meaning of the entity category attribute is undefined by this 161 specification if it appears anywhere else within a metadata instance, 162 or within any other XML document. 164 If the entity category attribute Attribute element appears more than 165 once in the metadata for an entity, the combined set of associated 166 attribute values SHOULD be interpreted by relying parties as if they 167 all appeared within a single Attribute element. 169 3.2. Semantics 171 The presence of the entity category attribute within an entity's 172 entity attributes represents a series of claims (one for each 173 attribute value) that the entity is a member of each named category. 174 The precise semantics of such a claim depend on the definition of the 175 category itself. 177 An entity may be claimed to be a member of more than one category. 178 In this case, the entity is claimed to meet the requirements of each 179 category independently unless otherwise specified by the category 180 definitions themselves. 182 The definition of the concept of a category is intentionally not 183 addressed in this document, in order to leave it as general as 184 possible. However, to be useful, category definitions SHOULD include 185 the following as appropriate: 187 o A definition of the authorities who may validly assert membership 188 in the category. While membership in some categories may be self- 189 asserted informally by an entity's owner, others may need to be 190 validated by third parties such as the entity's home federation or 191 other registrar. 193 o A set of criteria by which an entity's membership in the category 194 can be objectively assessed. 196 o A definition of the processes by which valid authorities may 197 determine that an entity meets the category's membership criteria. 199 o A description of the anticipated uses for category membership by 200 relying parties. 202 o A statement indicating the applicability or otherwise of 203 membership of the entity category to different SAML role 204 descriptors, and any protocol support restrictions that may be 205 relevant. 207 Entity categories SHOULD NOT be used to indicate the certification 208 status of an entity regarding its conformance to the requirements of 209 an identity assurance framework. The [SAML2IDAssuranceProfile] 210 extension SHOULD be used for this purpose. 212 If significant changes are made to a category definition, the new 213 version of the category SHOULD be represented by a different category 214 URI so that the old and new versions can be distinguished by a 215 relying party. 217 No ordering relation is defined over entity category value URIs. 218 Entity category attribute value URIs MUST be treated as opaque 219 strings for the purpose of comparison. 221 3.3. Entity Category Example 222 224 225 227 230 http://example.org/category/dog 232 urn:oid:1.3.6.1.4.1.21829 233 234 235 236 ... 237 239 4. Entity Category Support Attribute 241 4.1. Syntax 243 Entity category support attribute values MUST be URIs. It is 244 RECOMMENDED that http:-scheme or https:-scheme URLs are used, and 245 further RECOMMENDED that each such value resolves to a human-readable 246 document defining the value's semantics. A given entity category 247 value MAY be associated with multiple support values in order to 248 allow for multiple forms of support, participation, or interoperation 249 with entities in the category. 251 The entity category support attribute MUST be encoded as a SAML 2.0 252 Attribute element with @NameFormat 253 urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name 254 http://macedir.org/entity-category-support. 256 Claims that a SAML entity implements support for one or more 257 categories are represented by including the Attribute element 258 described here in the entity's metadata through use of the 259 [SAML2MetadataAttr] metadata extension, in which the Attribute 260 element is contained within an mdattr:EntityAttributes element 261 directly contained within an md:Extensions element directly contained 262 within the entity's md:EntityDescriptor. 264 The meaning of the entity category support attribute is undefined by 265 this specification if it appears anywhere else within a metadata 266 instance, or within any other XML document. 268 If the entity category support attribute Attribute element appears 269 more than once in the metadata for an entity, the combined set of 270 associated attribute values SHOULD be interpreted by relying parties 271 as if they all appeared within a single Attribute element. 273 4.2. Semantics 275 The presence of the entity category support attribute within an 276 entity's entity attributes represents a series of claims (one for 277 each attribute value) that the entity supports peer entities in a 278 category in a particular fashion. The precise semantics of such a 279 claim depend on the definition of the category support identifier 280 itself. Category support claims will often be defined to be self- 281 asserted. 283 An entity may be claimed to support more than one category. In this 284 case, the entity is claimed to meet the support requirements of each 285 category independently unless otherwise specified by the category 286 definitions themselves. 288 The definition of the concept of "support" for a category is 289 intentionally not addressed in this document, in order to leave it as 290 general as possible. It is assumed that entity category definitions 291 MAY define one or more support values signifying particular 292 definitions for "support" by peers as motivated by use cases arising 293 from the definition of the category itself. 295 A common case is expected to be the definition of a single support 296 value whose URI is identical to that defined for the category itself. 298 If significant changes are made to a category support definition, the 299 new version SHOULD be represented by a different category support URI 300 so that the old and new versions can be distinguished by a relying 301 party. 303 No ordering relation is defined over entity category value URIs. 304 Entity category attribute value URIs MUST be treated as opaque 305 strings for the purpose of comparison. 307 4.3. Entity Category Support Example 308 310 311 313 316 http://example.org/category/dog/basic 318 http://example.org/category/dog/advanced 320 urn:oid:1.3.6.1.4.1.21829 321 322 323 324 ... 325 327 5. IANA Considerations 329 This memo includes no request to IANA. 331 6. Security Considerations 333 The presence of the entity category attribute within an entity's 334 entity attributes represents a series of claims (one for each 335 attribute value) that the entity is a member of the named categories. 336 Before accepting and acting on such claims, any relying party needs 337 to establish, at a level of assurance sufficient for the intended 338 use, a chain of trust concluding that the claim is justified. 340 Some of the elements in such a chain of trust might include: 342 o The integrity of the metadata delivered to the relying party, as 343 for example assured by a digital signature. 345 o If the entity category attribute is carried within a signed 346 assertion, the assertion itself must be evaluated. 348 o The policies and procedures of the immediate source of the 349 metadata; in particular, any procedures the immediate source has 350 with regard to aggregation of metadata from other sources. 352 o The policies and procedures implemented by agents along the 353 publication path from the original metadata registrar: this may be 354 determined either by examination of the published procedures of 355 each agent in turn, or may be simplified if the entity metadata 356 includes publication path metadata in mdrpi:PublicationPath 357 elements as described in [SAML2MetadataRPI] section 2.3.1. 359 o The policies and procedures implemented by the original metadata 360 registrar. The registrar's identity may be known implicitly, or 361 may be determined from the entity metadata if it includes an 362 mdrpi:RegistrationInfo element and corresponding 363 @registrationAuthority attribute as described in 364 [SAML2MetadataRPI] section 2.1.1. 366 o The definition of the category itself; in particular, any 367 statements it makes about whether membership of the category may 368 be self-asserted, or may only be asserted by particular 369 authorities. 371 Although entity category support attribute values will often be 372 defined as self-asserted claims by the containing entity, the 373 provenance of the metadata remains relevant to a relying party's 374 decision to accept a claim of support as legitimate, and the specific 375 definition of a support claim will influence the assurance required 376 to act on it. 378 The conclusion that a claim of category membership or support is 379 justified and should be acted upon may require a determination of the 380 origin of the claim. This may not be necessary if the immediate 381 source of the metadata is trusted to such an extent that the trust 382 calculation is essentially delegated to it. 384 In many cases, a claim will be included in an entity's metadata by 385 the original metadata registrar on behalf of the entity's owner, and 386 the mdrpi:RegistrationInfo element's @registrationAuthority attribute 387 is available to carry the registrar's identity. However, any agent 388 that is part of the chain of custody between the original registrar 389 and the final relying party may have added, removed or transformed 390 claims according to local policy. For example, an agent charged with 391 redistributing metadata may remove claims it regards as 392 untrustworthy, or add others which were not already present if they 393 have value to its intended audience. 395 7. References 397 7.1. Normative References 399 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [SAML2MetadataAttr] 403 Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity 404 Attributes", August 2009, 405 . 407 [SAML2MetadataRPI] 408 La Joie, C., Ed., "SAML V2.0 Metadata Extensions for 409 Registration and Publication Information Version 1.0", 410 April 2012, 411 . 413 7.2. Informative References 415 [REFEDS] Research and Education Federations, "REFEDS Home Page", 416 . 418 [REFEDS.agreement] 419 Research and Education Federations, "REFEDS Participant's 420 Agreement", . 423 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 424 Series and RFC Editor", RFC 4844, July 2007. 426 [SAML2IDAssuranceProfile] 427 Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed., 428 "SAML V2.0 Identity Assurance Profiles Version 1.0", 429 November 2010, . 432 Appendix A. Acknowledgements 434 This work has been a collaborative effort within the REFEDS and MACE- 435 Dir communities. Special thanks to (in no particular order): 437 o RL 'Bob' Morgan 439 o Ken Klingenstein 441 o Keith Hazelton 443 o Steven Olshansky 445 o Mikael Linden 447 o Nicole Harris 449 o Tom Scavo 451 Appendix B. Change Log (to be removed by RFC Editor before publication) 453 B.1. Since draft-young-entity-category-04 455 No substantive changes. 457 B.2. Since draft-young-entity-category-03 459 Additional improvements in response to IETF Gen-Art review: 461 o Section 3.2: additional SHOULD language recommending that category 462 definitions include applicability information for particular SAML 463 role descriptors. 465 o Section 3.2: added an informative reference to 466 [SAML2IDAssuranceProfile] and language recommending its use over 467 entity categories where appropriate. 469 B.3. Since draft-young-entity-category-02 471 Fix link to the REFEDS Participant's Agreement [REFEDS.agreement]. 473 Clarifications in response to IETF Gen-Art review: 475 o Section 1: make explicit the fact that we don't specify any values 476 of either attribute in this document. 478 o Section 3.1, Section 4.1: clarify that it is possible for 479 attribute values to appear within multiple Attribute elements, and 480 that this SHOULD be regarded as equivalent to combining them 481 within a single Attribute element. 483 o Section 3.2, Section 4.2: clarify the expectation that categories 484 are independent unless their definitions say otherwise. 486 o Section 3.2, Section 4.2: If significant changes are made to a 487 category definition, the new version of the category SHOULD be 488 represented by a different category URI *so that the old and new 489 versions can be distinguished by a relying party*. 491 o Section 3.2, Section 4.2: *No ordering relation is defined over 492 entity category value URIs.* Entity category attribute value URIs 493 MUST be treated as opaque strings *for the purpose of comparison*. 495 B.4. Since draft-young-entity-category-01 497 Changes from REFEDS consultation process: 499 1. Simplify title from "The Entity Category SAML Entity Metadata 500 Attribute Types" to "The Entity Category SAML Attribute Types". 502 2. Clarify the use of [SAML2MetadataRPI] in Section 6 by indicating 503 the elements and attributes to be used, and the sections of 504 [SAML2MetadataRPI] in which they are defined. 506 3. Remove any implication that category and category support claims 507 are necessarily being made "by" the entity itself. 509 4. Clarify that the origin of a category membership or support claim 510 may not always be the original registrar. 512 Grammar fix in Abstract. 514 Change the reference anchor for the SAML [SAML2MetadataRPI] 515 extension, as it now more commonly known as RPI than its original DRI 516 abbreviation. 518 B.5. Since draft-young-entity-category-00 520 Update affiliations for Leif Johansson and Scott Cantor. 522 Remove authors from acknowledgements. 524 Reorganize some of the introductory boilerplate sections. 526 B.6. Since draft-macedir-entity-category 528 Adopted as base for draft-young-entity-category-00. 530 Changed ipr from "pre5378Trust200902" to "trust200902" and submission 531 type from IETF to independent. 533 Designate Ian Young as editor for this version. Set more general 534 affiliation. 536 Modernised reference to RFC 2119 [BCP14] and moved that reference to 537 the introduction. 539 Adjusted layout of examples so that they don't exceed the RFC 540 standard line length. 542 Minor typographical nits but (intentionally) no substantive content 543 changes. 545 Authors' Addresses 547 Ian A. Young (editor) 548 Independent 550 EMail: ian@iay.org.uk 552 Leif Johansson 553 SUNET 555 EMail: leifj@sunet.se 557 Scott Cantor 558 Shibboleth Consortium 560 EMail: cantor.2@osu.edu