idnits 2.17.1
draft-young-entity-category-06.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 (January 10, 2018) is 2269 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: July 14, 2018 SUNET
6 S. Cantor
7 Shibboleth Consortium
8 January 10, 2018
10 The Entity Category SAML Attribute Types
11 draft-young-entity-category-06
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 https://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 July 14, 2018.
40 Copyright Notice
42 Copyright (c) 2018 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 (https://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-05 . . . . . . . . . . 11
74 B.2. Since draft-young-entity-category-04 . . . . . . . . . . 11
75 B.3. Since draft-young-entity-category-03 . . . . . . . . . . 11
76 B.4. Since draft-young-entity-category-02 . . . . . . . . . . 11
77 B.5. Since draft-young-entity-category-01 . . . . . . . . . . 12
78 B.6. Since draft-young-entity-category-00 . . . . . . . . . . 12
79 B.7. Since draft-macedir-entity-category . . . . . . . . . . . 13
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
82 1. Introduction
84 This document describes a SAML attribute, referred to here as the
85 "entity category attribute", values of which represent entity types
86 or categories. When used with the SAML V2.0 Metadata Extension for
87 Entity Attributes [SAML2MetadataAttr] each such entity category
88 attribute value represents a claim that the entity thus labelled
89 meets the requirements of, and is asserted to be a member of, the
90 indicated category.
92 These category membership claims MAY be used by a relying party to
93 provision policy for release of attributes from an identity provider,
94 to influence user interface decisions such as those related to
95 identity provider discovery, or for any other purpose. In general,
96 the intended uses of any claim of membership in a given category will
97 depend on the details of the category's definition, and will often be
98 included as part of that definition.
100 Entity category attribute values are URIs, and this document does not
101 specify a controlled vocabulary. Category URIs may therefore be
102 defined by any appropriate authority without any requirement for
103 central registration. It is anticipated that other specifications
104 may provide management and discovery mechanisms for entity category
105 attribute values.
107 A second SAML attribute, referred to here as the "entity category
108 support attribute", contains URI values which represent claims that
109 an entity supports and/or interoperates with entities in a given
110 category or categories. These values, defined in conjunction with
111 specific entity category values, provide entities in a category with
112 the means to identify peer entities that wish to interact with them
113 in category-specific fashion.
115 This document does not specify any values either for the entity
116 category attribute or for the entity category support attribute.
118 1.1. REFEDS Document Process
120 The Research and Education Federations group ([REFEDS]) is the voice
121 that articulates the mutual needs of research and education identity
122 federations worldwide. It aims to represent the requirements of
123 research and education in the ever-growing space of access and
124 identity management.
126 From time to time REFEDS will wish to publish a document in the
127 Internet RFC series. Such documents will be published as part of the
128 RFC Independent Submission Stream [RFC4844]; however the REFEDS
129 working group sign-off process will have been followed for these
130 documents, as described in the REFEDS Participant's Agreement
131 [REFEDS.agreement].
133 This document is a product of the REFEDS Working Group process.
135 2. Notation and Conventions
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in RFC 2119 [BCP14].
141 3. Entity Category Attribute
143 3.1. Syntax
145 Entity category attribute values MUST be URIs. It is RECOMMENDED
146 that http:-scheme or https:-scheme URLs are used, and further
147 RECOMMENDED that each such value resolves to a human-readable
148 document defining the category.
150 The entity category attribute MUST be encoded as a SAML 2.0 Attribute
151 element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-
152 format:uri and @Name http://macedir.org/entity-category.
154 A SAML entity is associated with one or more categories by including
155 the Attribute element described here in the entity's metadata through
156 use of the [SAML2MetadataAttr] metadata extension, in which the
157 Attribute element is contained within an mdattr:EntityAttributes
158 element directly contained within an md:Extensions element directly
159 contained within the entity's md:EntityDescriptor.
161 The meaning of the entity category attribute is undefined by this
162 specification if it appears anywhere else within a metadata instance,
163 or within any other XML document.
165 If the entity category attribute Attribute element appears more than
166 once in the metadata for an entity, the combined set of associated
167 attribute values SHOULD be interpreted by relying parties as if they
168 all appeared within a single Attribute element.
170 3.2. Semantics
172 The presence of the entity category attribute within an entity's
173 entity attributes represents a series of claims (one for each
174 attribute value) that the entity is a member of each named category.
175 The precise semantics of such a claim depend on the definition of the
176 category itself.
178 An entity may be claimed to be a member of more than one category.
179 In this case, the entity is claimed to meet the requirements of each
180 category independently unless otherwise specified by the category
181 definitions themselves.
183 The definition of the concept of a category is intentionally not
184 addressed in this document, in order to leave it as general as
185 possible. However, to be useful, category definitions SHOULD include
186 the following as appropriate:
188 o A definition of the authorities who may validly assert membership
189 in the category. While membership in some categories may be self-
190 asserted informally by an entity's owner, others may need to be
191 validated by third parties such as the entity's home federation or
192 other registrar.
194 o A set of criteria by which an entity's membership in the category
195 can be objectively assessed.
197 o A definition of the processes by which valid authorities may
198 determine that an entity meets the category's membership criteria.
200 o A description of the anticipated uses for category membership by
201 relying parties.
203 o A statement indicating the applicability or otherwise of
204 membership of the entity category to different SAML role
205 descriptors, and any protocol support restrictions that may be
206 relevant.
208 Entity categories SHOULD NOT be used to indicate the certification
209 status of an entity regarding its conformance to the requirements of
210 an identity assurance framework. The [SAML2IDAssuranceProfile]
211 extension SHOULD be used for this purpose.
213 If significant changes are made to a category definition, the new
214 version of the category SHOULD be represented by a different category
215 URI so that the old and new versions can be distinguished by a
216 relying party.
218 No ordering relation is defined over entity category value URIs.
219 Entity category attribute value URIs MUST be treated as opaque
220 strings for the purpose of comparison.
222 3.3. Entity Category Example
223
225
226
228
231 http://example.org/category/dog
233 urn:oid:1.3.6.1.4.1.21829
234
235
236
237 ...
238
240 4. Entity Category Support Attribute
242 4.1. Syntax
244 Entity category support attribute values MUST be URIs. It is
245 RECOMMENDED that http:-scheme or https:-scheme URLs are used, and
246 further RECOMMENDED that each such value resolves to a human-readable
247 document defining the value's semantics. A given entity category
248 value MAY be associated with multiple support values in order to
249 allow for multiple forms of support, participation, or interoperation
250 with entities in the category.
252 The entity category support attribute MUST be encoded as a SAML 2.0
253 Attribute element with @NameFormat
254 urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
255 http://macedir.org/entity-category-support.
257 Claims that a SAML entity implements support for one or more
258 categories are represented by including the Attribute element
259 described here in the entity's metadata through use of the
260 [SAML2MetadataAttr] metadata extension, in which the Attribute
261 element is contained within an mdattr:EntityAttributes element
262 directly contained within an md:Extensions element directly contained
263 within the entity's md:EntityDescriptor.
265 The meaning of the entity category support attribute is undefined by
266 this specification if it appears anywhere else within a metadata
267 instance, or within any other XML document.
269 If the entity category support attribute Attribute element appears
270 more than once in the metadata for an entity, the combined set of
271 associated attribute values SHOULD be interpreted by relying parties
272 as if they all appeared within a single Attribute element.
274 4.2. Semantics
276 The presence of the entity category support attribute within an
277 entity's entity attributes represents a series of claims (one for
278 each attribute value) that the entity supports peer entities in a
279 category in a particular fashion. The precise semantics of such a
280 claim depend on the definition of the category support identifier
281 itself. Category support claims will often be defined to be self-
282 asserted.
284 An entity may be claimed to support more than one category. In this
285 case, the entity is claimed to meet the support requirements of each
286 category independently unless otherwise specified by the category
287 definitions themselves.
289 The definition of the concept of "support" for a category is
290 intentionally not addressed in this document, in order to leave it as
291 general as possible. It is assumed that entity category definitions
292 MAY define one or more support values signifying particular
293 definitions for "support" by peers as motivated by use cases arising
294 from the definition of the category itself.
296 A common case is expected to be the definition of a single support
297 value whose URI is identical to that defined for the category itself.
299 If significant changes are made to a category support definition, the
300 new version SHOULD be represented by a different category support URI
301 so that the old and new versions can be distinguished by a relying
302 party.
304 No ordering relation is defined over entity category value URIs.
305 Entity category attribute value URIs MUST be treated as opaque
306 strings for the purpose of comparison.
308 4.3. Entity Category Support Example
309
311
312
314
317 http://example.org/category/dog/basic
319 http://example.org/category/dog/advanced
321 urn:oid:1.3.6.1.4.1.21829
322
323
324
325 ...
326
328 5. IANA Considerations
330 This memo includes no request to IANA.
332 6. Security Considerations
334 The presence of the entity category attribute within an entity's
335 entity attributes represents a series of claims (one for each
336 attribute value) that the entity is a member of the named categories.
337 Before accepting and acting on such claims, any relying party needs
338 to establish, at a level of assurance sufficient for the intended
339 use, a chain of trust concluding that the claim is justified.
341 Some of the elements in such a chain of trust might include:
343 o The integrity of the metadata delivered to the relying party, as
344 for example assured by a digital signature.
346 o If the entity category attribute is carried within a signed
347 assertion, the assertion itself must be evaluated.
349 o The policies and procedures of the immediate source of the
350 metadata; in particular, any procedures the immediate source has
351 with regard to aggregation of metadata from other sources.
353 o The policies and procedures implemented by agents along the
354 publication path from the original metadata registrar: this may be
355 determined either by examination of the published procedures of
356 each agent in turn, or may be simplified if the entity metadata
357 includes publication path metadata in mdrpi:PublicationPath
358 elements as described in [SAML2MetadataRPI] section 2.3.1.
360 o The policies and procedures implemented by the original metadata
361 registrar. The registrar's identity may be known implicitly, or
362 may be determined from the entity metadata if it includes an
363 mdrpi:RegistrationInfo element and corresponding
364 @registrationAuthority attribute as described in
365 [SAML2MetadataRPI] section 2.1.1.
367 o The definition of the category itself; in particular, any
368 statements it makes about whether membership of the category may
369 be self-asserted, or may only be asserted by particular
370 authorities.
372 Although entity category support attribute values will often be
373 defined as self-asserted claims by the containing entity, the
374 provenance of the metadata remains relevant to a relying party's
375 decision to accept a claim of support as legitimate, and the specific
376 definition of a support claim will influence the assurance required
377 to act on it.
379 The conclusion that a claim of category membership or support is
380 justified and should be acted upon may require a determination of the
381 origin of the claim. This may not be necessary if the immediate
382 source of the metadata is trusted to such an extent that the trust
383 calculation is essentially delegated to it.
385 In many cases, a claim will be included in an entity's metadata by
386 the original metadata registrar on behalf of the entity's owner, and
387 the mdrpi:RegistrationInfo element's @registrationAuthority attribute
388 is available to carry the registrar's identity. However, any agent
389 that is part of the chain of custody between the original registrar
390 and the final relying party may have added, removed or transformed
391 claims according to local policy. For example, an agent charged with
392 redistributing metadata may remove claims it regards as
393 untrustworthy, or add others which were not already present if they
394 have value to its intended audience.
396 7. References
398 7.1. Normative References
400 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
401 Requirement Levels", BCP 14, RFC 2119, March 1997.
403 [SAML2MetadataAttr]
404 Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
405 Attributes", August 2009,
406 .
408 [SAML2MetadataRPI]
409 La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
410 Registration and Publication Information Version 1.0",
411 April 2012,
412 .
414 7.2. Informative References
416 [REFEDS] Research and Education Federations, "REFEDS Home Page",
417 .
419 [REFEDS.agreement]
420 Research and Education Federations, "REFEDS Participant's
421 Agreement",
422 .
424 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
425 Series and RFC Editor", RFC 4844, July 2007.
427 [SAML2IDAssuranceProfile]
428 Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed.,
429 "SAML V2.0 Identity Assurance Profiles Version 1.0",
430 November 2010, .
433 Appendix A. Acknowledgements
435 This work has been a collaborative effort within the REFEDS and MACE-
436 Dir communities. Special thanks to (in no particular order):
438 o RL 'Bob' Morgan
440 o Ken Klingenstein
442 o Keith Hazelton
444 o Steven Olshansky
446 o Mikael Linden
448 o Nicole Harris
450 o Tom Scavo
452 Appendix B. Change Log (to be removed by RFC Editor before publication)
454 B.1. Since draft-young-entity-category-05
456 No substantive changes.
458 B.2. Since draft-young-entity-category-04
460 No substantive changes.
462 B.3. Since draft-young-entity-category-03
464 Additional improvements in response to IETF Gen-Art review:
466 o Section 3.2: additional SHOULD language recommending that category
467 definitions include applicability information for particular SAML
468 role descriptors.
470 o Section 3.2: added an informative reference to
471 [SAML2IDAssuranceProfile] and language recommending its use over
472 entity categories where appropriate.
474 B.4. Since draft-young-entity-category-02
476 Fix link to the REFEDS Participant's Agreement [REFEDS.agreement].
478 Clarifications in response to IETF Gen-Art review:
480 o Section 1: make explicit the fact that we don't specify any values
481 of either attribute in this document.
483 o Section 3.1, Section 4.1: clarify that it is possible for
484 attribute values to appear within multiple Attribute elements, and
485 that this SHOULD be regarded as equivalent to combining them
486 within a single Attribute element.
488 o Section 3.2, Section 4.2: clarify the expectation that categories
489 are independent unless their definitions say otherwise.
491 o Section 3.2, Section 4.2: If significant changes are made to a
492 category definition, the new version of the category SHOULD be
493 represented by a different category URI *so that the old and new
494 versions can be distinguished by a relying party*.
496 o Section 3.2, Section 4.2: *No ordering relation is defined over
497 entity category value URIs.* Entity category attribute value URIs
498 MUST be treated as opaque strings *for the purpose of comparison*.
500 B.5. Since draft-young-entity-category-01
502 Changes from REFEDS consultation process:
504 1. Simplify title from "The Entity Category SAML Entity Metadata
505 Attribute Types" to "The Entity Category SAML Attribute Types".
507 2. Clarify the use of [SAML2MetadataRPI] in Section 6 by indicating
508 the elements and attributes to be used, and the sections of
509 [SAML2MetadataRPI] in which they are defined.
511 3. Remove any implication that category and category support claims
512 are necessarily being made "by" the entity itself.
514 4. Clarify that the origin of a category membership or support claim
515 may not always be the original registrar.
517 Grammar fix in Abstract.
519 Change the reference anchor for the SAML [SAML2MetadataRPI]
520 extension, as it now more commonly known as RPI than its original DRI
521 abbreviation.
523 B.6. Since draft-young-entity-category-00
525 Update affiliations for Leif Johansson and Scott Cantor.
527 Remove authors from acknowledgements.
529 Reorganize some of the introductory boilerplate sections.
531 B.7. Since draft-macedir-entity-category
533 Adopted as base for draft-young-entity-category-00.
535 Changed ipr from "pre5378Trust200902" to "trust200902" and submission
536 type from IETF to independent.
538 Designate Ian Young as editor for this version. Set more general
539 affiliation.
541 Modernised reference to RFC 2119 [BCP14] and moved that reference to
542 the introduction.
544 Adjusted layout of examples so that they don't exceed the RFC
545 standard line length.
547 Minor typographical nits but (intentionally) no substantive content
548 changes.
550 Authors' Addresses
552 Ian A. Young (editor)
553 Independent
555 EMail: ian@iay.org.uk
557 Leif Johansson
558 SUNET
560 EMail: leifj@sunet.se
562 Scott Cantor
563 Shibboleth Consortium
565 EMail: cantor.2@osu.edu