-
Notifications
You must be signed in to change notification settings - Fork 2
/
rfc8409-diff.html
680 lines (523 loc) · 42.1 KB
/
rfc8409-diff.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
<html><head><title>wdiff rfc8409.original rfc8409.txt</title></head><body>
<pre>
<strike><font color='red'>Network Working Group</font></strike>
<strong><font color='green'>Independent Submission</font></strong> I. Young, Ed.
<strike><font color='red'>Internet-Draft</font></strike>
<strong><font color='green'>Request for Comments: 8409</font></strong> Independent
<strike><font color='red'>Intended status:</font></strike>
<strong><font color='green'>Category:</font></strong> Informational L. Johansson
<strike><font color='red'>Expires: August 4, 2018</font></strike>
<strong><font color='green'>ISSN: 2070-1721</font></strong> SUNET
S. Cantor
Shibboleth Consortium
<strike><font color='red'>January 31,</font></strike>
<strong><font color='green'>August</font></strong> 2018
The Entity Category <strike><font color='red'>SAML</font></strike> <strong><font color='green'>Security Assertion Markup Language (SAML)</font></strong>
Attribute Types
<strike><font color='red'>draft-young-entity-category-07</font></strike>
Abstract
This document describes <strike><font color='red'>a</font></strike> <strong><font color='green'>two</font></strong> SAML entity <strike><font color='red'>attribute which</font></strike> <strong><font color='green'>attributes: one that</font></strong> can be
used to assign category membership semantics to an <strike><font color='red'>entity,</font></strike> <strong><font color='green'>entity</font></strong> and <strike><font color='red'>a second
attribute</font></strike> <strong><font color='green'>another</font></strong>
for use in claiming interoperation with or support for entities in
such categories.
This document is a product of the <strong><font color='green'>working group process of the</font></strong>
Research and Education <strike><font color='red'>Federations</font></strike> <strong><font color='green'>FEDerations</font></strong> (REFEDS) <strike><font color='red'>Working Group process.</font></strike> <strong><font color='green'>group.</font></strong>
Status of This Memo
This <strike><font color='red'>Internet-Draft</font></strike> <strong><font color='green'>document</font></strong> is <strike><font color='red'>submitted in full conformance with</font></strike> <strong><font color='green'>not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to</font></strong> the
<strike><font color='red'>provisions</font></strike> <strong><font color='green'>RFC Series, independently</font></strong> of <strike><font color='red'>BCP 78</font></strike> <strong><font color='green'>any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion</font></strong> and <strike><font color='red'>BCP 79.
Internet-Drafts</font></strike> <strong><font color='green'>makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor</font></strong> are <strike><font color='red'>working documents</font></strike> <strong><font color='green'>not candidates for any level</font></strong> of <strike><font color='red'>the</font></strike> Internet <strike><font color='red'>Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list</font></strike> <strong><font color='green'>Standard;
see Section 2</font></strong> of <strong><font color='green'>RFC 7841.
Information about the</font></strong> current <strike><font color='red'>Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum</font></strike> <strong><font color='green'>status</font></strong> of <strike><font color='red'>six months</font></strike> <strong><font color='green'>this document, any errata,</font></strong>
and <strong><font color='green'>how to provide feedback on it</font></strong> may be <strike><font color='red'>updated, replaced, or obsoleted by other documents</font></strike> <strong><font color='green'>obtained</font></strong> at <strike><font color='red'>any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2018.</font></strike>
<strong><font color='green'>https://www.rfc-editor.org/info/rfc8409.</font></strong>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. REFEDS Document Process . . . . . . . . . . . . . . . . . 3
2. Notation and Conventions . . . . . . . . . . . . . . . . . . 3
3. Entity Category Attribute . . . . . . . . . . . . . . . . . . <strike><font color='red'>4</font></strike> <strong><font color='green'>3</font></strong>
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . <strike><font color='red'>4</font></strike> <strong><font color='green'>3</font></strong>
3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Entity Category Example . . . . . . . . . . . . . . . . . 6
4. Entity Category Support Attribute . . . . . . . . . . . . . . 6
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Entity Category Support Example . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
<strike><font color='red'>Appendix A.</font></strike>
Acknowledgements . . . . . . . . . . . . . . . . . . <strike><font color='red'>11
Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 11
B.1. Since draft-young-entity-category-05 . . . . . . . . . . 11
B.2. Since draft-young-entity-category-04 . . . . . . . . . . 11
B.3. Since draft-young-entity-category-03 . . . . . . . . . . 11
B.4. Since draft-young-entity-category-02 . . . .</font></strike> . . . . . . 11
<strike><font color='red'>B.5. Since draft-young-entity-category-01 . . . . . . . . . . 12
B.6. Since draft-young-entity-category-00 . . . . . . . . . . 12
B.7. Since draft-macedir-entity-category . . . . . . . . . . . 13</font></strike>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <strike><font color='red'>13</font></strike> <strong><font color='green'>11</font></strong>
1. Introduction
This document describes a SAML <strike><font color='red'>attribute, referred to here as</font></strike> <strong><font color='green'>attribute called</font></strong> the "entity category <strike><font color='red'>attribute", values</font></strike>
<strong><font color='green'>attribute". Values</font></strong> of <strike><font color='red'>which</font></strike> <strong><font color='green'>this attribute</font></strong> represent entity types or
categories. When used with the SAML V2.0 Metadata Extension for
Entity Attributes <strike><font color='red'>[SAML2MetadataAttr]</font></strike> <strong><font color='green'>[SAML2MetadataAttr],</font></strong> each such entity category
attribute value represents a claim that the entity thus <strike><font color='red'>labelled</font></strike> <strong><font color='green'>labeled</font></strong> meets
the requirements of, and is asserted to be a member of, the indicated
category.
These category membership claims MAY be used by a relying party to
provision policy for release of attributes from an identity provider,
to influence user interface decisions such as those related to
identity provider discovery, or for any other purpose. In general,
the intended uses of any claim of membership in a given category will
depend on the details of the category's <strike><font color='red'>definition,</font></strike> <strong><font color='green'>definition</font></strong> and will often be
included as part of that definition.
Entity category attribute values are <strike><font color='red'>URIs, and</font></strike> <strong><font color='green'>URIs. Therefore,</font></strong> this document
<strike><font color='red'>therefore</font></strike>
does not specify a controlled vocabulary for assigning
<strike><font color='red'>entity category values. Category URIs</font></strike> <strong><font color='green'>such values;
they</font></strong> may be defined by any appropriate authority without any
requirement for central registration. It is anticipated that other
specifications may provide management and discovery mechanisms for
entity category attribute values.
<strike><font color='red'>A second SAML attribute, referred to here as</font></strike>
<strong><font color='green'>This document also describes a SAML attribute called</font></strong> the "entity
category support <strike><font color='red'>attribute",</font></strike> <strong><font color='green'>attribute". This attribute</font></strong> contains URI values <strike><font color='red'>which</font></strike> <strong><font color='green'>that</font></strong>
represent claims that an entity supports and/or interoperates with
entities in a given category or categories. These values, defined in
conjunction with specific entity category <strong><font color='green'>attribute</font></strong> values, provide
entities in a category with the means to identify peer entities that
wish to interact with them in a fashion described by the category
specification.
This document does not specify any values <strike><font color='red'>either</font></strike> for <strong><font color='green'>either</font></strong> the entity
category attribute or <strike><font color='red'>for</font></strike> the entity category support attribute.
1.1. REFEDS Document Process
The Research and Education <strike><font color='red'>Federations</font></strike> <strong><font color='green'>FEDerations [REFEDS]</font></strong> group <strike><font color='red'>([REFEDS])</font></strike> is the voice
that articulates the mutual needs of research and education identity
federations worldwide. It aims to represent the requirements of
research and education in the ever-growing space of access and
identity management.
From time to <strike><font color='red'>time</font></strike> <strong><font color='green'>time,</font></strong> REFEDS will <strike><font color='red'>wish to</font></strike> publish a document in the
<strike><font color='red'>Internet</font></strike> RFC <strike><font color='red'>series.</font></strike> <strong><font color='green'>Series.</font></strong>
Such documents will be published as part of the
<strike><font color='red'>RFC</font></strike> Independent
Submission <strike><font color='red'>Stream</font></strike> <strong><font color='green'>stream</font></strong> [RFC4844]; <strike><font color='red'>however</font></strike> <strong><font color='green'>however,</font></strong> the REFEDS
<strike><font color='red'>working group sign-off</font></strike> <strong><font color='green'>Working Group sign-
off</font></strong> process will have been followed for these documents, as described
in the REFEDS Participant's Agreement [REFEDS.agreement].
This document is a product of the REFEDS Working Group process.
2. Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", <strong><font color='green'>"NOT RECOMMENDED",</font></strong> "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <strike><font color='red'>RFC 2119 [BCP14].</font></strike>
<strong><font color='green'>BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The notation "@example" is used as a shorthand for an XML attribute
with attribute name "example".</font></strong>
3. Entity Category Attribute
3.1. Syntax
Entity category attribute values MUST be <strike><font color='red'>valid</font></strike> URIs. <strong><font color='green'>Such values are also
referred to as "category URIs" in this document.</font></strong>
It is RECOMMENDED that http:-scheme or https:-scheme URIs are <strike><font color='red'>used, and</font></strike> <strong><font color='green'>used;
it is</font></strong> further RECOMMENDED that <strike><font color='red'>an entity</font></strike> <strong><font color='green'>a</font></strong> category URI resolves to a human-
readable document defining the category.
Authorities defining entity categories MUST produce a specification
of the entity category and SHOULD make arrangement for the <strike><font color='red'>entity</font></strike> category
URI to resolve to the specification in <strike><font color='red'>human readable</font></strike> <strong><font color='green'>human-readable</font></strong> form.
Authorities defining entity categories MAY use versioning of <strike><font color='red'>entity</font></strike> category
URIs where <strike><font color='red'>appropriate, in which case</font></strike> <strong><font color='green'>appropriate; if versioning is used,</font></strong> each version of the
specification of the entity category SHOULD clearly indicate the
latest version of the <strike><font color='red'>entity</font></strike> category URI (and hence of the specification).
The specification SHOULD include a description of how the authority
defining the entity category implements governance for the
specification <strike><font color='red'>in the case when</font></strike> <strong><font color='green'>if</font></strong> the specification <strike><font color='red'>may be</font></strike> <strong><font color='green'>is</font></strong> updated.
When used in SAML metadata or protocol elements, the entity category
attribute MUST be encoded as a SAML 2.0 Attribute element with
@NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
http://macedir.org/entity-category.
A SAML entity is associated with one or more categories by including
the Attribute element described here in the entity's metadata through
use of the <strike><font color='red'>[SAML2MetadataAttr]</font></strike> metadata <strike><font color='red'>extension,</font></strike> <strong><font color='green'>extension defined</font></strong> in <strike><font color='red'>which</font></strike> <strong><font color='green'>[SAML2MetadataAttr]. In
this extension,</font></strong> the Attribute element is contained within an
mdattr:EntityAttributes element directly contained within an
md:Extensions element directly contained within the entity's
md:EntityDescriptor.
The meaning of the entity category attribute is <strike><font color='red'>undefined</font></strike> <strong><font color='green'>not defined</font></strong> by this
specification if it appears anywhere else within a metadata <strike><font color='red'>instance,</font></strike> <strong><font color='green'>instance</font></strong>
or within any other XML document.
If the entity category attribute <strike><font color='red'>Attribute element</font></strike> appears more than once in the
metadata for an entity, <strong><font color='green'>relying parties SHOULD interpret</font></strong> the combined
set of associated attribute values <strike><font color='red'>SHOULD be interpreted by relying parties</font></strike> as if they all appeared <strong><font color='green'>together</font></strong>
within a single <strike><font color='red'>Attribute element.</font></strike> <strong><font color='green'>entity category attribute.</font></strong>
3.2. Semantics
The presence of the entity category attribute within an entity's
entity attributes represents a series of claims (one for each
attribute value) that the entity is a member of each named category.
The precise semantics of such a claim depend on the definition of the
category itself.
An entity may be claimed to be a member of more than one category.
In this case, the entity is claimed to meet the requirements of each
category independently unless otherwise specified by the category
definitions themselves.
<strike><font color='red'>The definition of the concept of a category is</font></strike>
<strong><font color='green'>This document</font></strong> intentionally <strong><font color='green'>does</font></strong> not
<strike><font color='red'>addressed in this document,</font></strike> <strong><font color='green'>define "category",</font></strong> in order to
leave <strike><font color='red'>it</font></strike> <strong><font color='green'>the concept</font></strong> as general as possible. However, to be useful,
category definitions SHOULD include the following as appropriate:
o A definition of the authorities who may validly assert membership
in the category. While membership in some categories may be self-
asserted informally by an entity's owner, others may need to be
validated by third parties such as the entity's home federation or
other registrar.
o A set of criteria by which an entity's membership in the category
can be objectively assessed.
o A definition of the processes by which valid authorities may
determine that an entity meets the category's membership criteria.
o A description of the anticipated uses for category membership by
relying parties.
o A statement indicating the applicability or otherwise of
membership of the entity category to different SAML role
<strike><font color='red'>descriptors,</font></strike>
<strong><font color='green'>descriptors</font></strong> and any protocol support restrictions that may be
relevant.
Entity categories SHOULD NOT be used to indicate the certification
status of an entity regarding its conformance to the requirements of
an identity assurance framework. The <strike><font color='red'>[SAML2IDAssuranceProfile]</font></strike> <strong><font color='green'>SAML</font></strong> extension <strong><font color='green'>defined in
[SAML2IDAssuranceProfile]</font></strong> SHOULD be used for this purpose.
If significant changes are made to a category definition, the new
version of the category SHOULD be represented by a different category
URI so that the old and new versions can be distinguished by a
relying party. It is for this reason that authorities defining
entity categories MAY employ some form of versioning for <strike><font color='red'>entity</font></strike> category <strike><font color='red'>URI.</font></strike>
<strong><font color='green'>URIs.</font></strong> When versioning is <strike><font color='red'>used</font></strike> <strong><font color='green'>used,</font></strong> each version of the entity category
MUST be treated as a separate URI.
No ordering relation is defined <strike><font color='red'>over</font></strike> <strong><font color='green'>for</font></strong> entity category <strike><font color='red'>value URIs.</font></strike> <strong><font color='green'>attribute values.</font></strong>
Entity category attribute <strike><font color='red'>value URIs</font></strike> <strong><font color='green'>values</font></strong> MUST be treated as opaque strings
for the purpose of comparison. In particular, if the specification
defining the entity category relies on versioning of the <strike><font color='red'>entity</font></strike> category
URI, a relying party MUST NOT assume any particular ordering between
different versions of the <strike><font color='red'>entity
category.</font></strike> <strong><font color='green'>category URI.</font></strong> Any order between versions
MUST be spelled out in the specification.
3.3. Entity Category Example
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://service.example.com/entity">
<md:Extensions>
<mdattr:EntityAttributes
xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://macedir.org/entity-category">
<AttributeValue
>http://example.org/category/dog</AttributeValue>
<AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
</Attribute>
</mdattr:EntityAttributes>
</md:Extensions>
...
</md:EntityDescriptor>
4. Entity Category Support Attribute
4.1. Syntax
Entity category support attribute values MUST be URIs. <strong><font color='green'>Such values
are also referred to as "category support URIs" in this document.</font></strong>
It is RECOMMENDED that http:-scheme or https:-scheme URLs are <strike><font color='red'>used, and</font></strike> <strong><font color='green'>used;
it is</font></strong> further RECOMMENDED that each such value resolves to a <strike><font color='red'>human-readable</font></strike> <strong><font color='green'>human-
readable</font></strong> document defining the value's semantics.
A given <strike><font color='red'>entity</font></strike> category
<strike><font color='red'>value</font></strike> <strong><font color='green'>URI</font></strong> MAY be associated with multiple <strong><font color='green'>category</font></strong> support <strike><font color='red'>values</font></strike>
<strong><font color='green'>URIs</font></strong> in order to allow for multiple forms of support, participation,
or interoperation with entities in the category. The <strike><font color='red'>authoritiy</font></strike> <strong><font color='green'>authority</font></strong>
defining the <strike><font color='red'>entity</font></strike> category <strong><font color='green'>URI</font></strong> and <strike><font color='red'>entity</font></strike> category support <strike><font color='red'>values</font></strike> <strong><font color='green'>URIs</font></strong> MUST clearly
describe the relationship between (all versions of) the <strike><font color='red'>entity</font></strike> category URI
and (all versions of) the <strike><font color='red'>entity</font></strike> category support URIs as applicable in the
entity category specification.
The entity category support attribute MUST be encoded as a SAML 2.0
Attribute element with @NameFormat
urn:oasis:names:tc:SAML:2.0:attrname-format:uri and @Name
http://macedir.org/entity-category-support.
Claims that a SAML entity implements support for one or more
categories are represented by including the Attribute element
described here in the entity's metadata through use of the
<strike><font color='red'>[SAML2MetadataAttr]</font></strike> metadata <strike><font color='red'>extension,</font></strike>
<strong><font color='green'>extension defined</font></strong> in <strike><font color='red'>which</font></strike> <strong><font color='green'>[SAML2MetadataAttr]. In this extension,</font></strong> the
Attribute element is contained within an mdattr:EntityAttributes
element directly contained within an md:Extensions element directly
contained within the entity's md:EntityDescriptor.
The meaning of the entity category support attribute is <strike><font color='red'>undefined</font></strike> <strong><font color='green'>not defined</font></strong>
by this specification if it appears anywhere else within a metadata
<strike><font color='red'>instance,</font></strike>
<strong><font color='green'>instance</font></strong> or within any other XML document.
If the entity category support attribute <strike><font color='red'>Attribute element</font></strike> appears more than once in
the metadata for an entity, <strong><font color='green'>relying parties SHOULD interpret</font></strong> the
combined set of associated attribute values <strike><font color='red'>SHOULD be interpreted by relying parties</font></strike> as if they all appeared
<strong><font color='green'>together</font></strong> within a single <strike><font color='red'>Attribute element.</font></strike> <strong><font color='green'>entity category support attribute.</font></strong>
4.2. Semantics
The presence of the entity category support attribute within an
entity's entity attributes represents a series of claims (one for
each attribute value) that the entity supports peer entities in a
category in a particular fashion. The precise semantics of such a
claim depend on the definition of the category support <strike><font color='red'>identifier</font></strike> <strong><font color='green'>URI</font></strong> itself.
Category support claims will often be defined to be <strike><font color='red'>self-
asserted.</font></strike> <strong><font color='green'>self-asserted.</font></strong>
An entity may be claimed to support more than one category. In this
case, the entity is claimed to meet the support requirements of each
category independently unless otherwise specified by the category
definitions themselves.
<strike><font color='red'>The definition of the concept of</font></strike>
<strong><font color='green'>This document intentionally does not define</font></strong> "support" for a <strike><font color='red'>category is
intentionally not addressed in this document,</font></strike> <strong><font color='green'>category,</font></strong>
in order to leave <strike><font color='red'>it</font></strike> <strong><font color='green'>the concept</font></strong> as general as possible. It is assumed
that entity category definitions MAY define one or more <strong><font color='green'>category</font></strong>
support <strike><font color='red'>values</font></strike> <strong><font color='green'>URIs</font></strong> signifying particular definitions for "support" by peers
as motivated by use cases arising from the definition of the category
itself.
A common case is expected to be the definition of a single <strong><font color='green'>category</font></strong>
support
<strike><font color='red'>value whose</font></strike> URI <strong><font color='green'>whose value</font></strong> is identical to <strike><font color='red'>that defined for</font></strike> the category <strike><font color='red'>itself.</font></strike> <strong><font color='green'>URI.</font></strong>
If significant changes are made to a category support definition, the
new version SHOULD be represented by a different category support URI
so that the old and new versions can be distinguished by a relying
party. It is for this reason that authorities defining entity
categories support MAY employ some form of versioning. When
versioning is <strike><font color='red'>used</font></strike> <strong><font color='green'>used,</font></strong> each version of the <strike><font color='red'>entity</font></strike> category support URI MUST be
treated as a separate URI.
No ordering relation is defined <strike><font color='red'>over</font></strike> <strong><font color='green'>for</font></strong> entity category <strike><font color='red'>URIs. Entity
category</font></strike> <strong><font color='green'>support</font></strong> attribute
<strong><font color='green'>values. Entity category</font></strong> support <strike><font color='red'>value URIs</font></strike> <strong><font color='green'>attribute values</font></strong> MUST be treated as
opaque strings for the purpose of comparison. In particular, if the
specification defining the <strike><font color='red'>entity</font></strike> category support <strike><font color='red'>values</font></strike> <strong><font color='green'>URIs</font></strong> relies on
versioning, a relying party MUST NOT assume any particular ordering
between different versions of the <strike><font color='red'>entity</font></strike> category support URI. Any order
between versions MUST be spelled out in the specification.
4.3. Entity Category Support Example
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://idp.example.edu/entity">
<md:Extensions>
<mdattr:EntityAttributes
xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://macedir.org/entity-category-support">
<AttributeValue
>http://example.org/category/dog/basic</AttributeValue>
<AttributeValue
>http://example.org/category/dog/advanced</AttributeValue>
<AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
</Attribute>
</mdattr:EntityAttributes>
</md:Extensions>
...
</md:EntityDescriptor>
5. IANA Considerations
This <strike><font color='red'>memo includes</font></strike> <strong><font color='green'>document has</font></strong> no <strike><font color='red'>request to IANA.</font></strike> <strong><font color='green'>IANA actions.</font></strong>
6. Security Considerations
The presence of the entity category attribute within an entity's
entity attributes represents a series of claims (one for each
attribute value) that the entity is a member of the named categories.
Before accepting and acting on such claims, any relying party needs
to establish, at a level of assurance sufficient for the intended
use, a chain of trust concluding that the claim is justified.
Some of the elements in such a chain of trust might include:
o The integrity of the metadata delivered to the relying party, <strike><font color='red'>as</font></strike> for <strike><font color='red'>example</font></strike>
<strong><font color='green'>example, as</font></strong> assured by a digital signature.
o If the entity category attribute is carried within a signed
assertion, the assertion itself must be evaluated.
o The policies and procedures of the immediate source of the
<strike><font color='red'>metadata;</font></strike>
<strong><font color='green'>metadata,</font></strong> in particular, any procedures the immediate source has
with regard to aggregation of metadata from other sources.
o The policies and procedures implemented by agents along the
publication path from the original metadata <strike><font color='red'>registrar: this</font></strike> <strong><font color='green'>registrar. This</font></strong> may
be determined <strike><font color='red'>either</font></strike> by examination of the published procedures of each
agent in <strike><font color='red'>turn,</font></strike> <strong><font color='green'>turn</font></strong> or may be simplified if the entity metadata includes
publication path metadata in mdrpi:PublicationPath elements as
described in <strike><font color='red'>[SAML2MetadataRPI] section 2.3.1.</font></strike> <strong><font color='green'>Section 2.3.1 of [SAML2MetadataRPI].</font></strong>
o The policies and procedures implemented by the original metadata
registrar. The registrar's identity may be known <strike><font color='red'>implicitly,</font></strike> <strong><font color='green'>implicitly</font></strong> or
may be determined from the entity metadata if it includes an
mdrpi:RegistrationInfo element and corresponding
@registrationAuthority <strike><font color='red'>attribute</font></strike> as described in
<strike><font color='red'>[SAML2MetadataRPI] section 2.1.1.</font></strike> <strong><font color='green'>Section 2.1.1 of
[SAML2MetadataRPI].</font></strong>
o The definition of the category <strike><font color='red'>itself;</font></strike> <strong><font color='green'>itself,</font></strong> in particular, any
statements it makes about whether membership of the category may
be <strike><font color='red'>self-asserted,</font></strike> <strong><font color='green'>self-asserted</font></strong> or may only be asserted by particular
authorities.
Although entity category support attribute values will often be
defined as self-asserted claims by the containing entity, the
provenance of the metadata remains relevant to a relying party's
decision to accept a claim of support as legitimate, and the specific
definition of a support claim will influence the assurance required
to act on it.
The conclusion that a claim of category membership or support is
justified and should be acted upon may require a determination of the
origin of the claim. This may not be necessary if the immediate
source of the metadata is trusted to such an extent that the trust
calculation is essentially delegated to it.
In many cases, a claim will be included in an entity's metadata by
the original metadata registrar on behalf of the entity's owner, and
the mdrpi:RegistrationInfo element's @registrationAuthority <strike><font color='red'>attribute</font></strike> is
available to carry the registrar's identity. However, any agent that
is part of the chain of custody between the original registrar and
the final relying party may have added, <strike><font color='red'>removed</font></strike> <strong><font color='green'>removed,</font></strong> or transformed
claims according to local policy. For example, an agent charged with
redistributing metadata may remove claims it regards as
<strike><font color='red'>untrustworthy,</font></strike> <strong><font color='green'>untrustworthy</font></strong>
or add others <strike><font color='red'>which</font></strike> <strong><font color='green'>that</font></strong> were not already present if they have value to its
intended audience.
7. References
7.1. Normative References
<strike><font color='red'>[BCP14]</font></strike>
<strong><font color='green'>[RFC2119]</font></strong> Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
<strong><font color='green'>DOI 10.17487/RFC2119,</font></strong> March <strike><font color='red'>1997.</font></strike> <strong><font color='green'>1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.</font></strong>
[SAML2MetadataAttr]
Cantor, S., Ed., "SAML V2.0 Metadata Extension for Entity
<strike><font color='red'>Attributes",</font></strike>
<strong><font color='green'>Attributes Version 1.0",</font></strong> August 2009,
<strike><font color='red'><http://wiki.oasis-open.org/security/SAML2MetadataAttr>.</font></strike> <strong><font color='green'><http://docs.oasis-
open.org/security/saml/Post2.0/
sstc-metadata-attr-cs-01.pdf>.</font></strong>
[SAML2MetadataRPI]
La Joie, C., Ed., "SAML V2.0 Metadata Extensions for
Registration and Publication Information Version 1.0",
April 2012,
<strike><font color='red'><http://wiki.oasis-open.org/security/SAML2MetadataDRI>.</font></strike> <strong><font color='green'><http://docs.oasis-
open.org/security/saml/Post2.0/saml-metadata-
rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.pdf>.</font></strong>
7.2. Informative References
[REFEDS] <strike><font color='red'>Research</font></strike> <strong><font color='green'>"Research</font></strong> and Education <strike><font color='red'>Federations, "REFEDS Home Page",</font></strike> <strong><font color='green'>FEDerations (REFEDS) Group",</font></strong>
<http://www.refeds.org/>.
[REFEDS.agreement]
Research and Education Federations, "REFEDS Participant's
Agreement",
<https://refeds.org/about/refeds-participants-agreement>.
[RFC4844] Daigle, <strike><font color='red'>L.</font></strike> <strong><font color='green'>L., Ed.</font></strong> and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, <strong><font color='green'>DOI 10.17487/RFC4844,</font></strong>
July <strike><font color='red'>2007.</font></strike> <strong><font color='green'>2007, <https://www.rfc-editor.org/info/rfc4844>.</font></strong>
[SAML2IDAssuranceProfile]
Morgan, RL., Ed., Madsen, P., Ed., and S. Cantor, Ed.,
"SAML V2.0 Identity Assurance Profiles Version 1.0",
November 2010, <strike><font color='red'><https://wiki.oasis-open.org/security/
SAML2IDAssuranceProfile>.
Appendix A.</font></strike> <strong><font color='green'><http://docs.oasis-
open.org/security/saml/Post2.0/
sstc-saml-assurance-profile-cs-01.pdf>.</font></strong>
Acknowledgements
This work has been a collaborative effort within the REFEDS and MACE-
Dir communities. Special thanks to <strong><font color='green'>the following individuals</font></strong> (in no
particular order):
o RL 'Bob' Morgan
o Ken Klingenstein
o Keith Hazelton
o Steven Olshansky
o Mikael Linden
o Nicole Harris
o Tom Scavo
<strike><font color='red'>Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1. Since draft-young-entity-category-05
Recommendation on versioning and language on requirements for entity
category specification.
B.2. Since draft-young-entity-category-04
No substantive changes.
B.3. Since draft-young-entity-category-03
Additional improvements in response to IETF Gen-Art review:
o Section 3.2: additional SHOULD language recommending that category
definitions include applicability information for particular SAML
role descriptors.
o Section 3.2: added an informative reference to
[SAML2IDAssuranceProfile] and language recommending its use over
entity categories where appropriate.
B.4. Since draft-young-entity-category-02
Fix link to the REFEDS Participant's Agreement [REFEDS.agreement].
Clarifications in response to IETF Gen-Art review:
o Section 1: make explicit the fact that we don't specify any values
of either attribute in this document.
o Section 3.1, Section 4.1: clarify that it is possible for
attribute values to appear within multiple Attribute elements, and
that this SHOULD be regarded as equivalent to combining them
within a single Attribute element.
o Section 3.2, Section 4.2: clarify the expectation that categories
are independent unless their definitions say otherwise.
o Section 3.2, Section 4.2: If significant changes are made to a
category definition, the new version of the category SHOULD be
represented by a different category URI *so that the old and new
versions can be distinguished by a relying party*.
o Section 3.2, Section 4.2: *No ordering relation is defined over
entity category value URIs.* Entity category attribute value URIs
MUST be treated as opaque strings *for the purpose of comparison*.
B.5. Since draft-young-entity-category-01
Changes from REFEDS consultation process:
1. Simplify title from "The Entity Category SAML Entity Metadata
Attribute Types" to "The Entity Category SAML Attribute Types".
2. Clarify the use of [SAML2MetadataRPI] in Section 6 by indicating
the elements and attributes to be used, and the sections of
[SAML2MetadataRPI] in which they are defined.
3. Remove any implication that category and category support claims
are necessarily being made "by" the entity itself.
4. Clarify that the origin of a category membership or support claim
may not always be the original registrar.
Grammar fix in Abstract.
Change the reference anchor for the SAML [SAML2MetadataRPI]
extension, as it now more commonly known as RPI than its original DRI
abbreviation.
B.6. Since draft-young-entity-category-00
Update affiliations for Leif Johansson and Scott Cantor.
Remove authors from acknowledgements.
Reorganize some of the introductory boilerplate sections.
B.7. Since draft-macedir-entity-category
Adopted as base for draft-young-entity-category-00.
Changed ipr from "pre5378Trust200902" to "trust200902" and submission
type from IETF to independent.
Designate Ian Young as editor for this version. Set more general
affiliation.
Modernised reference to RFC 2119 [BCP14] and moved that reference to
the introduction.
Adjusted layout of examples so that they don't exceed the RFC
standard line length.
Minor typographical nits but (intentionally) no substantive content
changes.</font></strike>
Authors' Addresses
Ian A. Young (editor)
Independent
<strike><font color='red'>EMail:</font></strike>
<strong><font color='green'>Email:</font></strong> [email protected]
Leif Johansson
SUNET
<strike><font color='red'>EMail:</font></strike>
<strong><font color='green'>Email:</font></strong> [email protected]
Scott Cantor
Shibboleth Consortium
<strike><font color='red'>EMail:</font></strike>
<strong><font color='green'>Email:</font></strong> [email protected]
</pre>
</body></html>