idnits 2.17.1
draft-young-entity-category-07.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 31, 2018) is 2275 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: August 4, 2018 SUNET
6 S. Cantor
7 Shibboleth Consortium
8 January 31, 2018
10 The Entity Category SAML Attribute Types
11 draft-young-entity-category-07
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 August 4, 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 . . . . . . . . . . . . . . . . . 6
61 4. Entity Category Support Attribute . . . . . . . . . . . . . . 6
62 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7
64 4.3. Entity Category Support Example . . . . . . . . . . . . . 8
65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
68 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
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
101 therefore does not specify a controlled vocabulary for assigning
102 entity category values. Category URIs may be defined by any
103 appropriate authority without any requirement for central
104 registration. It is anticipated that other specifications may
105 provide management and discovery mechanisms for entity category
106 attribute values.
108 A second SAML attribute, referred to here as the "entity category
109 support attribute", contains URI values which represent claims that
110 an entity supports and/or interoperates with entities in a given
111 category or categories. These values, defined in conjunction with
112 specific entity category values, provide entities in a category with
113 the means to identify peer entities that wish to interact with them
114 in a fashion described by the category specification.
116 This document does not specify any values either for the entity
117 category attribute or for the entity category support attribute.
119 1.1. REFEDS Document Process
121 The Research and Education Federations group ([REFEDS]) is the voice
122 that articulates the mutual needs of research and education identity
123 federations worldwide. It aims to represent the requirements of
124 research and education in the ever-growing space of access and
125 identity management.
127 From time to time REFEDS will wish to publish a document in the
128 Internet RFC series. Such documents will be published as part of the
129 RFC Independent Submission Stream [RFC4844]; however the REFEDS
130 working group sign-off process will have been followed for these
131 documents, as described in the REFEDS Participant's Agreement
132 [REFEDS.agreement].
134 This document is a product of the REFEDS Working Group process.
136 2. Notation and Conventions
138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 document are to be interpreted as described in RFC 2119 [BCP14].
142 3. Entity Category Attribute
144 3.1. Syntax
146 Entity category attribute values MUST be valid URIs. It is
147 RECOMMENDED that http:-scheme or https:-scheme URIs are used, and
148 further RECOMMENDED that an entity category URI resolves to a human-
149 readable document defining the category.
151 Authorities defining entity categories MUST produce a specification
152 of the entity category and SHOULD make arrangement for the entity
153 category URI to resolve to the specification in human readable form.
155 Authorities defining entity categories MAY use versioning of entity
156 category URIs where appropriate, in which case each version of the
157 specification of the entity category SHOULD clearly indicate the
158 latest version of the entity category URI (and hence of the
159 specification). The specification SHOULD include a description of
160 how the authority defining the entity category implements governance
161 for the specification in the case when the specification may be
162 updated.
164 When used in SAML metadata or protocol elements, the entity category
165 attribute MUST be encoded as a SAML 2.0 Attribute element with
166 @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
167 http://macedir.org/entity-category.
169 A SAML entity is associated with one or more categories by including
170 the Attribute element described here in the entity's metadata through
171 use of the [SAML2MetadataAttr] metadata extension, in which the
172 Attribute element is contained within an mdattr:EntityAttributes
173 element directly contained within an md:Extensions element directly
174 contained within the entity's md:EntityDescriptor.
176 The meaning of the entity category attribute is undefined by this
177 specification if it appears anywhere else within a metadata instance,
178 or within any other XML document.
180 If the entity category attribute Attribute element appears more than
181 once in the metadata for an entity, the combined set of associated
182 attribute values SHOULD be interpreted by relying parties as if they
183 all appeared within a single Attribute element.
185 3.2. Semantics
187 The presence of the entity category attribute within an entity's
188 entity attributes represents a series of claims (one for each
189 attribute value) that the entity is a member of each named category.
191 The precise semantics of such a claim depend on the definition of the
192 category itself.
194 An entity may be claimed to be a member of more than one category.
195 In this case, the entity is claimed to meet the requirements of each
196 category independently unless otherwise specified by the category
197 definitions themselves.
199 The definition of the concept of a category is intentionally not
200 addressed in this document, in order to leave it as general as
201 possible. However, to be useful, category definitions SHOULD include
202 the following as appropriate:
204 o A definition of the authorities who may validly assert membership
205 in the category. While membership in some categories may be self-
206 asserted informally by an entity's owner, others may need to be
207 validated by third parties such as the entity's home federation or
208 other registrar.
210 o A set of criteria by which an entity's membership in the category
211 can be objectively assessed.
213 o A definition of the processes by which valid authorities may
214 determine that an entity meets the category's membership criteria.
216 o A description of the anticipated uses for category membership by
217 relying parties.
219 o A statement indicating the applicability or otherwise of
220 membership of the entity category to different SAML role
221 descriptors, and any protocol support restrictions that may be
222 relevant.
224 Entity categories SHOULD NOT be used to indicate the certification
225 status of an entity regarding its conformance to the requirements of
226 an identity assurance framework. The [SAML2IDAssuranceProfile]
227 extension SHOULD be used for this purpose.
229 If significant changes are made to a category definition, the new
230 version of the category SHOULD be represented by a different category
231 URI so that the old and new versions can be distinguished by a
232 relying party. It is for this reason that authorities defining
233 entity categories MAY employ some form of versioning for entity
234 category URI. When versioning is used each version of the entity
235 category MUST be treated as a separate URI.
237 No ordering relation is defined over entity category value URIs.
238 Entity category attribute value URIs MUST be treated as opaque
239 strings for the purpose of comparison. In particular, if the
240 specification defining the entity category relies on versioning of
241 the entity category URI, a relying party MUST NOT assume any
242 particular ordering between different versions of the entity
243 category. Any order between versions MUST be spelled out in the
244 specification.
246 3.3. Entity Category Example
248
250
251
253
256 http://example.org/category/dog
258 urn:oid:1.3.6.1.4.1.21829
259
260
261
262 ...
263
265 4. Entity Category Support Attribute
267 4.1. Syntax
269 Entity category support attribute values MUST be URIs. It is
270 RECOMMENDED that http:-scheme or https:-scheme URLs are used, and
271 further RECOMMENDED that each such value resolves to a human-readable
272 document defining the value's semantics. A given entity category
273 value MAY be associated with multiple support values in order to
274 allow for multiple forms of support, participation, or interoperation
275 with entities in the category. The authoritiy defining the entity
276 category and entity category support values MUST clearly describe the
277 relationship between (all versions of) the entity category URI and
278 (all versions of) the entity category support URIs as applicable in
279 the entity category specification.
281 The entity category support attribute MUST be encoded as a SAML 2.0
282 Attribute element with @NameFormat
283 urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
284 http://macedir.org/entity-category-support.
286 Claims that a SAML entity implements support for one or more
287 categories are represented by including the Attribute element
288 described here in the entity's metadata through use of the
289 [SAML2MetadataAttr] metadata extension, in which the Attribute
290 element is contained within an mdattr:EntityAttributes element
291 directly contained within an md:Extensions element directly contained
292 within the entity's md:EntityDescriptor.
294 The meaning of the entity category support attribute is undefined by
295 this specification if it appears anywhere else within a metadata
296 instance, or within any other XML document.
298 If the entity category support attribute Attribute element appears
299 more than once in the metadata for an entity, the combined set of
300 associated attribute values SHOULD be interpreted by relying parties
301 as if they all appeared within a single Attribute element.
303 4.2. Semantics
305 The presence of the entity category support attribute within an
306 entity's entity attributes represents a series of claims (one for
307 each attribute value) that the entity supports peer entities in a
308 category in a particular fashion. The precise semantics of such a
309 claim depend on the definition of the category support identifier
310 itself. Category support claims will often be defined to be self-
311 asserted.
313 An entity may be claimed to support more than one category. In this
314 case, the entity is claimed to meet the support requirements of each
315 category independently unless otherwise specified by the category
316 definitions themselves.
318 The definition of the concept of "support" for a category is
319 intentionally not addressed in this document, in order to leave it as
320 general as possible. It is assumed that entity category definitions
321 MAY define one or more support values signifying particular
322 definitions for "support" by peers as motivated by use cases arising
323 from the definition of the category itself.
325 A common case is expected to be the definition of a single support
326 value whose URI is identical to that defined for the category itself.
328 If significant changes are made to a category support definition, the
329 new version SHOULD be represented by a different category support URI
330 so that the old and new versions can be distinguished by a relying
331 party. It is for this reason that authorities defining entity
332 categories support MAY employ some form of versioning. When
333 versioning is used each version of the entity category support URI
334 MUST be treated as a separate URI.
336 No ordering relation is defined over entity category URIs. Entity
337 category attribute support value URIs MUST be treated as opaque
338 strings for the purpose of comparison. In particular, if the
339 specification defining the entity category support values relies on
340 versioning, a relying party MUST NOT assume any particular ordering
341 between different versions of the entity category support URI. Any
342 order between versions MUST be spelled out in the specification.
344 4.3. Entity Category Support Example
346
348
349
351
354 http://example.org/category/dog/basic
356 http://example.org/category/dog/advanced
358 urn:oid:1.3.6.1.4.1.21829
359
360
361
362 ...
363
365 5. IANA Considerations
367 This memo includes no request to IANA.
369 6. Security Considerations
371 The presence of the entity category attribute within an entity's
372 entity attributes represents a series of claims (one for each
373 attribute value) that the entity is a member of the named categories.
374 Before accepting and acting on such claims, any relying party needs
375 to establish, at a level of assurance sufficient for the intended
376 use, a chain of trust concluding that the claim is justified.
378 Some of the elements in such a chain of trust might include:
380 o The integrity of the metadata delivered to the relying party, as
381 for example assured by a digital signature.
383 o If the entity category attribute is carried within a signed
384 assertion, the assertion itself must be evaluated.
386 o The policies and procedures of the immediate source of the
387 metadata; in particular, any procedures the immediate source has
388 with regard to aggregation of metadata from other sources.
390 o The policies and procedures implemented by agents along the
391 publication path from the original metadata registrar: this may be
392 determined either by examination of the published procedures of
393 each agent in turn, or may be simplified if the entity metadata
394 includes publication path metadata in mdrpi:PublicationPath
395 elements as described in [SAML2MetadataRPI] section 2.3.1.
397 o The policies and procedures implemented by the original metadata
398 registrar. The registrar's identity may be known implicitly, or
399 may be determined from the entity metadata if it includes an
400 mdrpi:RegistrationInfo element and corresponding
401 @registrationAuthority attribute as described in
402 [SAML2MetadataRPI] section 2.1.1.
404 o The definition of the category itself; in particular, any
405 statements it makes about whether membership of the category may
406 be self-asserted, or may only be asserted by particular
407 authorities.
409 Although entity category support attribute values will often be
410 defined as self-asserted claims by the containing entity, the
411 provenance of the metadata remains relevant to a relying party's
412 decision to accept a claim of support as legitimate, and the specific
413 definition of a support claim will influence the assurance required
414 to act on it.
416 The conclusion that a claim of category membership or support is
417 justified and should be acted upon may require a determination of the
418 origin of the claim. This may not be necessary if the immediate
419 source of the metadata is trusted to such an extent that the trust
420 calculation is essentially delegated to it.
422 In many cases, a claim will be included in an entity's metadata by
423 the original metadata registrar on behalf of the entity's owner, and
424 the mdrpi:RegistrationInfo element's @registrationAuthority attribute
425 is available to carry the registrar's identity. However, any agent
426 that is part of the chain of custody between the original registrar
427 and the final relying party may have added, removed or transformed
428 claims according to local policy. For example, an agent charged with
429 redistributing metadata may remove claims it regards as
430 untrustworthy, or add others which were not already present if they
431 have value to its intended audience.
433 7. References
435 7.1. Normative References
437 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
438 Requirement Levels", BCP 14, RFC 2119, March 1997.
440 [SAML2MetadataAttr]
441 Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
442 Attributes", August 2009,
443 .
445 [SAML2MetadataRPI]
446 La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
447 Registration and Publication Information Version 1.0",
448 April 2012,
449 .
451 7.2. Informative References
453 [REFEDS] Research and Education Federations, "REFEDS Home Page",
454 .
456 [REFEDS.agreement]
457 Research and Education Federations, "REFEDS Participant's
458 Agreement",
459 .
461 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
462 Series and RFC Editor", RFC 4844, July 2007.
464 [SAML2IDAssuranceProfile]
465 Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed.,
466 "SAML V2.0 Identity Assurance Profiles Version 1.0",
467 November 2010, .
470 Appendix A. Acknowledgements
472 This work has been a collaborative effort within the REFEDS and MACE-
473 Dir communities. Special thanks to (in no particular order):
475 o RL 'Bob' Morgan
477 o Ken Klingenstein
479 o Keith Hazelton
481 o Steven Olshansky
483 o Mikael Linden
485 o Nicole Harris
487 o Tom Scavo
489 Appendix B. Change Log (to be removed by RFC Editor before publication)
491 B.1. Since draft-young-entity-category-05
493 Recommendation on versioning and language on requirements for entity
494 category specification.
496 B.2. Since draft-young-entity-category-04
498 No substantive changes.
500 B.3. Since draft-young-entity-category-03
502 Additional improvements in response to IETF Gen-Art review:
504 o Section 3.2: additional SHOULD language recommending that category
505 definitions include applicability information for particular SAML
506 role descriptors.
508 o Section 3.2: added an informative reference to
509 [SAML2IDAssuranceProfile] and language recommending its use over
510 entity categories where appropriate.
512 B.4. Since draft-young-entity-category-02
514 Fix link to the REFEDS Participant's Agreement [REFEDS.agreement].
516 Clarifications in response to IETF Gen-Art review:
518 o Section 1: make explicit the fact that we don't specify any values
519 of either attribute in this document.
521 o Section 3.1, Section 4.1: clarify that it is possible for
522 attribute values to appear within multiple Attribute elements, and
523 that this SHOULD be regarded as equivalent to combining them
524 within a single Attribute element.
526 o Section 3.2, Section 4.2: clarify the expectation that categories
527 are independent unless their definitions say otherwise.
529 o Section 3.2, Section 4.2: If significant changes are made to a
530 category definition, the new version of the category SHOULD be
531 represented by a different category URI *so that the old and new
532 versions can be distinguished by a relying party*.
534 o Section 3.2, Section 4.2: *No ordering relation is defined over
535 entity category value URIs.* Entity category attribute value URIs
536 MUST be treated as opaque strings *for the purpose of comparison*.
538 B.5. Since draft-young-entity-category-01
540 Changes from REFEDS consultation process:
542 1. Simplify title from "The Entity Category SAML Entity Metadata
543 Attribute Types" to "The Entity Category SAML Attribute Types".
545 2. Clarify the use of [SAML2MetadataRPI] in Section 6 by indicating
546 the elements and attributes to be used, and the sections of
547 [SAML2MetadataRPI] in which they are defined.
549 3. Remove any implication that category and category support claims
550 are necessarily being made "by" the entity itself.
552 4. Clarify that the origin of a category membership or support claim
553 may not always be the original registrar.
555 Grammar fix in Abstract.
557 Change the reference anchor for the SAML [SAML2MetadataRPI]
558 extension, as it now more commonly known as RPI than its original DRI
559 abbreviation.
561 B.6. Since draft-young-entity-category-00
563 Update affiliations for Leif Johansson and Scott Cantor.
565 Remove authors from acknowledgements.
567 Reorganize some of the introductory boilerplate sections.
569 B.7. Since draft-macedir-entity-category
571 Adopted as base for draft-young-entity-category-00.
573 Changed ipr from "pre5378Trust200902" to "trust200902" and submission
574 type from IETF to independent.
576 Designate Ian Young as editor for this version. Set more general
577 affiliation.
579 Modernised reference to RFC 2119 [BCP14] and moved that reference to
580 the introduction.
582 Adjusted layout of examples so that they don't exceed the RFC
583 standard line length.
585 Minor typographical nits but (intentionally) no substantive content
586 changes.
588 Authors' Addresses
590 Ian A. Young (editor)
591 Independent
593 EMail: ian@iay.org.uk
595 Leif Johansson
596 SUNET
598 EMail: leifj@sunet.se
600 Scott Cantor
601 Shibboleth Consortium
603 EMail: cantor.2@osu.edu