idnits 2.17.1
draft-young-entity-category-01.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 (May 15, 2014) is 3633 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: November 16, 2014 SUNET
6 S. Cantor
7 Shibboleth Consortium
8 May 15, 2014
10 The Entity Category SAML Entity Metadata Attribute Types
11 draft-young-entity-category-01
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 or support for entities
18 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 November 16, 2014.
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 . . . . . . . . . . . . . . . . . 4
61 4. Entity Category Support Attribute . . . . . . . . . . . . . . 5
62 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 8
71 Appendix B. Change Log (to be removed by RFC Editor before
72 publication) . . . . . . . . . . . . . . . . . . . . 9
73 B.1. Since draft-young-entity-category-00 . . . . . . . . . . 9
74 B.2. Since draft-macedir-entity-category . . . . . . . . . . . 9
76 1. Introduction
78 This document describes a SAML attribute, referred to here as the
79 "entity category attribute", values of which represent entity types
80 or categories. When used with the SAML V2.0 Metadata Extension for
81 Entity Attributes [SAML2MetadataAttr] each such entity category
82 attribute value represents a claim that the entity thus labelled
83 meets the requirements of, and is asserted to be a member of, the
84 indicated category.
86 These category membership claims MAY be used by a relying party to
87 provision policy for release of attributes from an identity provider,
88 to influence user interface decisions such as those related to
89 identity provider discovery, or for any other purpose. In general,
90 the intended uses of any claim of membership in a given category will
91 depend on the details of the category's definition, and will often be
92 included as part of that definition.
94 Entity category attribute values are URIs, and this document does not
95 specify a controlled vocabulary. Category URIs may therefore be
96 defined by any appropriate authority without any requirement for
97 central registration. It is anticipated that other specifications
98 may provide management and discovery mechanisms for entity category
99 attribute values.
101 A second SAML attribute, referred to here as the "entity category
102 support attribute", contains URI values which represent claims by an
103 entity to support and/or interoperate with entities in a given
104 category or categories. These values, defined in conjunction with
105 specific entity category values, provide entities in a category with
106 the means to identify peer entities that wish to interact with them
107 in category-specific fashion.
109 1.1. REFEDS Document Process
111 The Research and Education Federations group ([REFEDS]) is the voice
112 that articulates the mutual needs of research and education identity
113 federations worldwide. It aims to represent the requirements of
114 research and education in the ever-growing space of access and
115 identity management.
117 From time to time REFEDS will wish to publish a document in the
118 Internet RFC series. Such documents will be published as part of the
119 RFC Independent Submission Stream [RFC4844]; however the REFEDS
120 working group sign-off process will have been followed for these
121 documents, as described in the REFEDS Participant's Agreement
122 [REFEDS.agreement].
124 This document is a product of the REFEDS Working Group process.
126 2. Notation and Conventions
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in RFC 2119 [BCP14].
132 3. Entity Category Attribute
134 3.1. Syntax
136 Entity category attribute values MUST be URIs. It is RECOMMENDED
137 that http:-scheme or https:-scheme URLs are used, and further
138 RECOMMENDED that each such value resolves to a human-readable
139 document defining the category.
141 The entity category attribute MUST be encoded as a SAML 2.0 Attribute
142 element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-
143 format:uri and @Name http://macedir.org/entity-category.
145 A SAML entity is associated with one or more categories by including
146 the Attribute element described here in the entity's metadata through
147 use of the [SAML2MetadataAttr] metadata extension, in which the
148 Attribute element is contained within an mdattr:EntityAttributes
149 element directly contained within an md:Extensions element directly
150 contained within the entity's md:EntityDescriptor. The meaning of
151 the entity category attribute is undefined by this specification if
152 it appears anywhere else within a metadata instance, or within any
153 other XML document.
155 3.2. Semantics
157 The presence of the entity category attribute within an entity's
158 entity attributes represents a series of claims (one for each
159 attribute value) that the entity is a member of each named category.
160 The precise semantics of such a claim depend on the definition of the
161 category itself.
163 The definition of the concept of a category is intentionally not
164 addressed in this document, in order to leave it as general as
165 possible. However, to be useful, category definitions SHOULD include
166 the following as appropriate:
168 o A definition of the authorities who may validly assert membership
169 in the category. While membership in some categories may be self-
170 asserted informally by an entity's owner, others may need to be
171 validated by third parties such as the entity's home federation or
172 other registrar.
174 o A set of criteria by which an entity's membership in the category
175 can be objectively assessed.
177 o A definition of the processes by which valid authorities may
178 determine that an entity meets the category's membership criteria.
180 o A description of the anticipated uses for category membership by
181 relying parties.
183 If significant changes are made to a category definition, the new
184 version of the category SHOULD be represented by a different category
185 URI.
187 Entity category attribute value URIs MUST be treated as opaque
188 strings.
190 3.3. Entity Category Example
191
193
194
196
199 http://example.org/category/dog
201 urn:oid:1.3.6.1.4.1.21829
202
203
204
205 ...
206
208 4. Entity Category Support Attribute
210 4.1. Syntax
212 Entity category support attribute values MUST be URIs. It is
213 RECOMMENDED that http:-scheme or https:-scheme URLs are used, and
214 further RECOMMENDED that each such value resolves to a human-readable
215 document defining the value's semantics. A given entity category
216 value MAY be associated with multiple support values in order to
217 allow for multiple forms of support, participation, or interoperation
218 with entities in the category.
220 The entity category support attribute MUST be encoded as a SAML 2.0
221 Attribute element with @NameFormat urn:oasis:names:tc:SAML:2.0
222 :attrname-format:uri and @Name http://macedir.org/entity-category-
223 support.
225 A SAML entity claims a form of support for entities in one or more
226 categories by including the Attribute element described here in the
227 entity's metadata through use of the [SAML2MetadataAttr] metadata
228 extension, in which the Attribute element is contained within an
229 mdattr:EntityAttributes element directly contained within an
230 md:Extensions element directly contained within the entity's
231 md:EntityDescriptor. The meaning of the entity category support
232 attribute is undefined by this specification if it appears anywhere
233 else within a metadata instance, or within any other XML document.
235 4.2. Semantics
236 The presence of the entity category support attribute within an
237 entity's entity attributes represents a series of claims (one for
238 each attribute value) that the entity supports peer entities in a
239 category in a particular fashion. The precise semantics of such a
240 claim depend on the definition of the category support identifier
241 itself. Category support claims will often be defined to be self-
242 asserted.
244 The definition of the concept of "support" for a category is
245 intentionally not addressed in this document, in order to leave it as
246 general as possible. It is assumed that entity category definitions
247 MAY define one or more support values signifying particular
248 definitions for "support" by peers as motivated by use cases arising
249 from the definition of the category itself.
251 A common case is expected to be the definition of a single support
252 value whose URI is identical to that defined for the category itself.
254 If significant changes are made to a category support definition, the
255 new version SHOULD be represented by a different category support
256 URI.
258 Entity category support attribute value URIs MUST be treated as
259 opaque strings.
261 4.3. Entity Category Support Example
263
265
266
268
271 http://example.org/category/dog/basic
273 http://example.org/category/dog/advanced
275 urn:oid:1.3.6.1.4.1.21829
276
277
278
279 ...
280
282 5. IANA Considerations
284 This memo includes no request to IANA.
286 6. Security Considerations
288 The presence of the entity category attribute within an entity's
289 entity attributes represents a series of claims (one for each
290 attribute value) that the entity is a member of the named categories.
291 Before accepting and acting on such claims, any relying party needs
292 to establish, at a level of assurance sufficient for the intended
293 use, a chain of trust concluding that the claim is justified.
295 Some of the elements in such a chain of trust might include:
297 o The integrity of the metadata delivered to the relying party, as
298 for example assured by a digital signature.
300 o If the entity category attribute is carried within a signed
301 assertion, the assertion itself must be evaluated.
303 o The procedures and policies of the immediate source of the
304 metadata; in particular, any procedures the immediate source has
305 with regard to aggregation of metadata from other sources.
307 o The policies and procedures implemented by agents along the
308 publication path from the original metadata registrar: this may be
309 determined either by examination of the published procedures of
310 each agent in turn, or may be simplified if the entity metadata
311 includes publication path metadata as described in the
312 [SAML2MetadataDRI] extension.
314 o The policies and procedures implemented by the original metadata
315 registrar.
317 o The definition of the category itself; in particular, any
318 statements it makes about whether membership of the category may
319 be self-asserted, or may only be asserted by particular
320 authorities.
322 Although entity category support attribute values will often be
323 defined as self-asserted claims by the containing entity, the
324 provenance of the metadata remains relevant to a relying party's
325 decision to accept a claim of support as legitimate, and the specific
326 definition of a support claim will influence the assurance required
327 to act on it.
329 7. References
331 7.1. Normative References
333 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
334 Requirement Levels ", BCP 14, RFC 2119, March 1997.
336 [SAML2MetadataAttr]
337 Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
338 Attributes", August 2009,
339 .
341 [SAML2MetadataDRI]
342 La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
343 Registration and Publication Information Version 1.0",
344 April 2012,
345 .
347 7.2. Informative References
349 [REFEDS.agreement]
350 Research and Education Federations, "REFEDS Participant's
351 Agreement", , .
354 [REFEDS] Research and Education Federations, "REFEDS Home Page", ,
355 .
357 [RFC4844] Daigle, L. Internet Architecture Board, "The RFC Series
358 and RFC Editor", RFC 4844, July 2007.
360 Appendix A. Acknowledgements
362 This work has been a collaborative effort within the REFEDS and MACE-
363 Dir communities. Special thanks to (in no particular order):
365 o RL 'Bob' Morgan
367 o Ken Klingenstein
369 o Keith Hazelton
371 o Steven Olshansky
373 o Mikael Linden
375 o Nicole Harris
376 o Tom Scavo
378 Appendix B. Change Log (to be removed by RFC Editor before publication)
380 B.1. Since draft-young-entity-category-00
382 Update affiliations for Leif Johansson and Scott Cantor.
384 Remove authors from acknowledgements.
386 Reorganize some of the introductory boilerplate sections.
388 B.2. Since draft-macedir-entity-category
390 Adopted as base for draft-young-entity-category-00.
392 Changed ipr from "pre5378Trust200902" to "trust200902" and submission
393 type from IETF to independent.
395 Designate Ian Young as editor for this version. Set more general
396 affiliation.
398 Modernised reference to RFC 2119 [BCP14] and moved that reference to
399 the introduction.
401 Adjusted layout of examples so that they don't exceed the RFC
402 standard line length.
404 Minor typographical nits but (intentionally) no substantive content
405 changes.
407 Authors' Addresses
409 Ian A. Young (editor)
410 Independent
412 EMail: ian@iay.org.uk
414 Leif Johansson
415 SUNET
417 EMail: leifj@sunet.se
418 Scott Cantor
419 Shibboleth Consortium
421 EMail: cantor.2@osu.edu