idnits 2.17.1
draft-young-entity-category-02.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 21, 2014) is 3566 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 22, 2015 SUNET
6 S. Cantor
7 Shibboleth Consortium
8 July 21, 2014
10 The Entity Category SAML Attribute Types
11 draft-young-entity-category-02
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 22, 2015.
40 Copyright Notice
42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 3
58 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 4
60 3.3. Entity Category Example . . . . . . . . . . . . . . . . . 5
61 4. Entity Category Support Attribute . . . . . . . . . . . . . . 5
62 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 6
64 4.3. Entity Category Support Example . . . . . . . . . . . . . 6
65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
69 7.2. Informative References . . . . . . . . . . . . . . . . . 8
70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
71 Appendix B. Change Log (to be removed by RFC Editor before
72 publication) . . . . . . . . . . . . . . . . . . . . 10
73 B.1. Since draft-young-entity-category-01 . . . . . . . . . . 10
74 B.2. Since draft-young-entity-category-00 . . . . . . . . . . 11
75 B.3. Since draft-macedir-entity-category . . . . . . . . . . . 11
77 1. Introduction
79 This document describes a SAML attribute, referred to here as the
80 "entity category attribute", values of which represent entity types
81 or categories. When used with the SAML V2.0 Metadata Extension for
82 Entity Attributes [SAML2MetadataAttr] each such entity category
83 attribute value represents a claim that the entity thus labelled
84 meets the requirements of, and is asserted to be a member of, the
85 indicated category.
87 These category membership claims MAY be used by a relying party to
88 provision policy for release of attributes from an identity provider,
89 to influence user interface decisions such as those related to
90 identity provider discovery, or for any other purpose. In general,
91 the intended uses of any claim of membership in a given category will
92 depend on the details of the category's definition, and will often be
93 included as part of that definition.
95 Entity category attribute values are URIs, and this document does not
96 specify a controlled vocabulary. Category URIs may therefore be
97 defined by any appropriate authority without any requirement for
98 central registration. It is anticipated that other specifications
99 may provide management and discovery mechanisms for entity category
100 attribute values.
102 A second SAML attribute, referred to here as the "entity category
103 support attribute", contains URI values which represent claims that
104 an entity supports and/or interoperates with entities in a given
105 category or categories. These values, defined in conjunction with
106 specific entity category values, provide entities in a category with
107 the means to identify peer entities that wish to interact with them
108 in category-specific fashion.
110 1.1. REFEDS Document Process
112 The Research and Education Federations group ([REFEDS]) is the voice
113 that articulates the mutual needs of research and education identity
114 federations worldwide. It aims to represent the requirements of
115 research and education in the ever-growing space of access and
116 identity management.
118 From time to time REFEDS will wish to publish a document in the
119 Internet RFC series. Such documents will be published as part of the
120 RFC Independent Submission Stream [RFC4844]; however the REFEDS
121 working group sign-off process will have been followed for these
122 documents, as described in the REFEDS Participant's Agreement
123 [REFEDS.agreement].
125 This document is a product of the REFEDS Working Group process.
127 2. Notation and Conventions
129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
131 document are to be interpreted as described in RFC 2119 [BCP14].
133 3. Entity Category Attribute
135 3.1. Syntax
137 Entity category attribute values MUST be URIs. It is RECOMMENDED
138 that http:-scheme or https:-scheme URLs are used, and further
139 RECOMMENDED that each such value resolves to a human-readable
140 document defining the category.
142 The entity category attribute MUST be encoded as a SAML 2.0 Attribute
143 element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-
144 format:uri and @Name http://macedir.org/entity-category.
146 A SAML entity is associated with one or more categories by including
147 the Attribute element described here in the entity's metadata through
148 use of the [SAML2MetadataAttr] metadata extension, in which the
149 Attribute element is contained within an mdattr:EntityAttributes
150 element directly contained within an md:Extensions element directly
151 contained within the entity's md:EntityDescriptor. The meaning of
152 the entity category attribute is undefined by this specification if
153 it appears anywhere else within a metadata instance, or within any
154 other XML document.
156 3.2. Semantics
158 The presence of the entity category attribute within an entity's
159 entity attributes represents a series of claims (one for each
160 attribute value) that the entity is a member of each named category.
161 The precise semantics of such a claim depend on the definition of the
162 category itself.
164 The definition of the concept of a category is intentionally not
165 addressed in this document, in order to leave it as general as
166 possible. However, to be useful, category definitions SHOULD include
167 the following as appropriate:
169 o A definition of the authorities who may validly assert membership
170 in the category. While membership in some categories may be self-
171 asserted informally by an entity's owner, others may need to be
172 validated by third parties such as the entity's home federation or
173 other registrar.
175 o A set of criteria by which an entity's membership in the category
176 can be objectively assessed.
178 o A definition of the processes by which valid authorities may
179 determine that an entity meets the category's membership criteria.
181 o A description of the anticipated uses for category membership by
182 relying parties.
184 If significant changes are made to a category definition, the new
185 version of the category SHOULD be represented by a different category
186 URI.
188 Entity category attribute value URIs MUST be treated as opaque
189 strings.
191 3.3. Entity Category Example
193
195
196
198
201 http://example.org/category/dog
203 urn:oid:1.3.6.1.4.1.21829
204
205
206
207 ...
208
210 4. Entity Category Support Attribute
212 4.1. Syntax
214 Entity category support attribute values MUST be URIs. It is
215 RECOMMENDED that http:-scheme or https:-scheme URLs are used, and
216 further RECOMMENDED that each such value resolves to a human-readable
217 document defining the value's semantics. A given entity category
218 value MAY be associated with multiple support values in order to
219 allow for multiple forms of support, participation, or interoperation
220 with entities in the category.
222 The entity category support attribute MUST be encoded as a SAML 2.0
223 Attribute element with @NameFormat
224 urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
225 http://macedir.org/entity-category-support.
227 Claims that a SAML entity implements support for one or more
228 categories are represented by including the Attribute element
229 described here in the entity's metadata through use of the
230 [SAML2MetadataAttr] metadata extension, in which the Attribute
231 element is contained within an mdattr:EntityAttributes element
232 directly contained within an md:Extensions element directly contained
233 within the entity's md:EntityDescriptor. The meaning of the entity
234 category support attribute is undefined by this specification if it
235 appears anywhere else within a metadata instance, or within any other
236 XML document.
238 4.2. Semantics
240 The presence of the entity category support attribute within an
241 entity's entity attributes represents a series of claims (one for
242 each attribute value) that the entity supports peer entities in a
243 category in a particular fashion. The precise semantics of such a
244 claim depend on the definition of the category support identifier
245 itself. Category support claims will often be defined to be self-
246 asserted.
248 The definition of the concept of "support" for a category is
249 intentionally not addressed in this document, in order to leave it as
250 general as possible. It is assumed that entity category definitions
251 MAY define one or more support values signifying particular
252 definitions for "support" by peers as motivated by use cases arising
253 from the definition of the category itself.
255 A common case is expected to be the definition of a single support
256 value whose URI is identical to that defined for the category itself.
258 If significant changes are made to a category support definition, the
259 new version SHOULD be represented by a different category support
260 URI.
262 Entity category support attribute value URIs MUST be treated as
263 opaque strings.
265 4.3. Entity Category Support Example
267
269
270
272
275 http://example.org/category/dog/basic
277 http://example.org/category/dog/advanced
279 urn:oid:1.3.6.1.4.1.21829
280
281
282
283 ...
284
286 5. IANA Considerations
288 This memo includes no request to IANA.
290 6. Security Considerations
292 The presence of the entity category attribute within an entity's
293 entity attributes represents a series of claims (one for each
294 attribute value) that the entity is a member of the named categories.
295 Before accepting and acting on such claims, any relying party needs
296 to establish, at a level of assurance sufficient for the intended
297 use, a chain of trust concluding that the claim is justified.
299 Some of the elements in such a chain of trust might include:
301 o The integrity of the metadata delivered to the relying party, as
302 for example assured by a digital signature.
304 o If the entity category attribute is carried within a signed
305 assertion, the assertion itself must be evaluated.
307 o The policies and procedures of the immediate source of the
308 metadata; in particular, any procedures the immediate source has
309 with regard to aggregation of metadata from other sources.
311 o The policies and procedures implemented by agents along the
312 publication path from the original metadata registrar: this may be
313 determined either by examination of the published procedures of
314 each agent in turn, or may be simplified if the entity metadata
315 includes publication path metadata in mdrpi:PublicationPath
316 elements as described in [SAML2MetadataRPI] section 2.3.1.
318 o The policies and procedures implemented by the original metadata
319 registrar. The registrar's identity may be known implicitly, or
320 may be determined from the entity metadata if it includes an
321 mdrpi:RegistrationInfo element and corresponding
322 @registrationAuthority attribute as described in
323 [SAML2MetadataRPI] section 2.1.1.
325 o The definition of the category itself; in particular, any
326 statements it makes about whether membership of the category may
327 be self-asserted, or may only be asserted by particular
328 authorities.
330 Although entity category support attribute values will often be
331 defined as self-asserted claims by the containing entity, the
332 provenance of the metadata remains relevant to a relying party's
333 decision to accept a claim of support as legitimate, and the specific
334 definition of a support claim will influence the assurance required
335 to act on it.
337 The conclusion that a claim of category membership or support is
338 justified and should be acted upon may require a determination of the
339 origin of the claim. This may not be necessary if the immediate
340 source of the metadata is trusted to such an extent that the trust
341 calculation is essentially delegated to it.
343 In many cases, a claim will be included in an entity's metadata by
344 the original metadata registrar on behalf of the entity's owner, and
345 the mdrpi:RegistrationInfo element's @registrationAuthority attribute
346 is available to carry the registrar's identity. However, any agent
347 that is part of the chain of custody between the original registrar
348 and the final relying party may have added, removed or transformed
349 claims according to local policy. For example, an agent charged with
350 redistributing metadata may remove claims it regards as
351 untrustworthy, or add others which were not already present if they
352 have value to its intended audience.
354 7. References
356 7.1. Normative References
358 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
359 Requirement Levels", BCP 14, RFC 2119, March 1997.
361 [SAML2MetadataAttr]
362 Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
363 Attributes", August 2009,
364 .
366 [SAML2MetadataRPI]
367 La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
368 Registration and Publication Information Version 1.0",
369 April 2012,
370 .
372 7.2. Informative References
374 [REFEDS] Research and Education Federations, "REFEDS Home Page",
375 .
377 [REFEDS.agreement]
378 Research and Education Federations, "REFEDS Participant's
379 Agreement", .
382 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
383 Series and RFC Editor", RFC 4844, July 2007.
385 Appendix A. Acknowledgements
387 This work has been a collaborative effort within the REFEDS and MACE-
388 Dir communities. Special thanks to (in no particular order):
390 o RL 'Bob' Morgan
392 o Ken Klingenstein
394 o Keith Hazelton
396 o Steven Olshansky
398 o Mikael Linden
400 o Nicole Harris
402 o Tom Scavo
404 Appendix B. Change Log (to be removed by RFC Editor before publication)
406 B.1. Since draft-young-entity-category-01
408 Changes from REFEDS consultation process:
410 1. Simplify title from "The Entity Category SAML Entity Metadata
411 Attribute Types" to "The Entity Category SAML Attribute Types".
413 2. Clarify the use of [SAML2MetadataRPI] in Section 6 by indicating
414 the elements and attributes to be used, and the sections of
415 [SAML2MetadataRPI] in which they are defined.
417 3. Remove any implication that category and category support claims
418 are necessarily being made "by" the entity itself.
420 4. Clarify that the origin of a category membership or support claim
421 may not always be the original registrar.
423 Grammar fix in Abstract.
425 Change the reference anchor for the SAML [SAML2MetadataRPI]
426 extension, as it now more commonly known as RPI than its original DRI
427 abbreviation.
429 B.2. Since draft-young-entity-category-00
431 Update affiliations for Leif Johansson and Scott Cantor.
433 Remove authors from acknowledgements.
435 Reorganize some of the introductory boilerplate sections.
437 B.3. Since draft-macedir-entity-category
439 Adopted as base for draft-young-entity-category-00.
441 Changed ipr from "pre5378Trust200902" to "trust200902" and submission
442 type from IETF to independent.
444 Designate Ian Young as editor for this version. Set more general
445 affiliation.
447 Modernised reference to RFC 2119 [BCP14] and moved that reference to
448 the introduction.
450 Adjusted layout of examples so that they don't exceed the RFC
451 standard line length.
453 Minor typographical nits but (intentionally) no substantive content
454 changes.
456 Authors' Addresses
458 Ian A. Young (editor)
459 Independent
461 EMail: ian@iay.org.uk
463 Leif Johansson
464 SUNET
466 EMail: leifj@sunet.se
468 Scott Cantor
469 Shibboleth Consortium
471 EMail: cantor.2@osu.edu