forked from leifj/draft-johansson-areg-reqs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-johansson-areg-reqs.html
619 lines (581 loc) · 31.6 KB
/
draft-johansson-areg-reqs.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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Requirements on an
Attribute Registry</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Requirements on an
Attribute Registry">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Internet Engineering Task Force</td><td class="header">L. Johansson, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">NORDUnet</td></tr>
<tr><td class="header">Intended status: Informational</td><td class="header">H. Flanagan</td></tr>
<tr><td class="header">Expires: January 31, 2013</td><td class="header">Internet2</td></tr>
<tr><td class="header"> </td><td class="header">July 30, 2012</td></tr>
</table></td></tr></table>
<h1><br />Requirements on an
Attribute Registry<br />draft-johansson-areg-reqs-00</h1>
<h3>Abstract</h3>
<p>This document establishes requirements for a registry of attributes
type definitions.
</p>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on January 31, 2013.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<p>
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction and Motivation<br />
<a href="#anchor2">2.</a>
Core Concerns<br />
<a href="#anchor3">2.1.</a>
Naming<br />
<a href="#anchor4">2.2.</a>
Use<br />
<a href="#anchor5">2.3.</a>
Data Locality<br />
<a href="#anchor6">2.4.</a>
Schema<br />
<a href="#anchor7">2.5.</a>
Lookup and Search<br />
<a href="#anchor8">3.</a>
Requrements<br />
<a href="#anchor9">3.1.</a>
Use<br />
<a href="#anchor10">3.2.</a>
Data Locality<br />
<a href="#anchor11">3.3.</a>
Naming<br />
<a href="#anchor12">3.4.</a>
Schema<br />
<a href="#anchor13">3.5.</a>
Lookup and Search<br />
<a href="#Acknowledgements">4.</a>
Acknowledgements<br />
<a href="#Contributors">5.</a>
Contributors<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#rfc.references1">8.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction and Motivation</h3>
<p>An attribute is a representation of a single datum of information
associated with an entity. The type of the attribute (the 'attribute
type') is defined by semantics and syntax that allow it to be used in a
variety of protocols and representations.
</p>
<p>This document lists requrements for a registry of such attribute type
definitions. For a long time, protocols that rely on the transfer of
attributes (like OpenID Connect, OAUTH, WS-Federation or SAML) often
rely on, at least in the case of attributes associated with accounts and
persons, attribute type definitions that are borrowed from LDAP or X.509
schema even though those particular protocols no longer represent the
common method to transfer and consume attributes.
</p>
<p>Claims-based protocols (for instance SAML or OpenID Connect) are
widely used on the Internet today. A common use-case for such protocols
is to establish identity federations that rely on the transfer of
attribute-values as a means to communicate subject information. Identity
federations are often purposed to specific communities. Increasingly
such communities need to engage in transactions across federation
boundries (eg when sharing services with other communities). This
practice is called inter-federation. Inter-federation raises the need
for a way to discover information about the attributes used in the
protocols employed inside and between federations.
</p>
<p>This document attempts to address these problems by establishing a
set of requirements for an Internet-wide registry of attribute-type
definitions. This document does not attempt to establish the registry,
that will be the work of future specifications.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Core Concerns</h3>
<p>In order to set the stage for, and properly frame the registry
requirements the following section lists a set of core concerns that
MUST be address by the registry requirements proper:
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Naming</h3>
<p>It is implied that attribute types have names that uniquely
identify them. This requirement will be spelled out in detail below. A
core concern implied by the existence of names is one of name
management. A common way to implement name management is to structure
the names in such a way as to establish name-spaces - parts of the
name that can be allocated, delegated and used to stablish global
uniqueness.
</p>
<p>There are examples of attribute type definitions that are in common
use today that employ a variety of name spaces including both OIDs,
http-based URIs and URNs.
</p>
<p>Another aspect of naming is name agility. Depending on the protocol
use to represent the name it is sometimes necessary to have to create
an alias for a name within another namespace. Name agility has
implication for the structure and contents of an attribute
registry.
</p>
<p>Attribute names sometime need human-readable (aka "friendly")
labels. This leads to questions of internationalization and possibly
security considerations in analogy to how IDNs can result in new
attack-vectors when used in URIs.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Use</h3>
<p>The core usage-question is this: will the attribute registry be
used in conjunction with individual transactions or as a tool for
configuration, discovery and information related to the task of
setting up federations and other relationships using claims-based
protocols. The former use-case requires a global service available 247
while the latter requires the availability typically found in a
website providing documentation.
</p>
<p>This document is skewed towards the former use-case. The authors
believe that the operational issues involved in the latter type of
registry would be daunting to say the least and it is only presented
here for completeness.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Data Locality</h3>
<p>There are two fundamental models for registries (as for any data
store): centralized and distributed. In a central registry all the
information is kept and maintained in one place whereas a distributed
registry shares information in the registry over multiple cooperative
instances that together make up the full registry. It is possible to
concieve of hybrid models where for instance a central index is used
to store referrals to a set of distributed nodes.
</p>
<p>The distributed model is most often used when there expected use of
the registry would imply a very high load on a single registry
instance. An example of a system with this property is the DNS. A
distributed registry model has implications for requirements on lookup
(cf below). Specifically the registry may need a central or well-known
entry-point unless there is a mechanism for performing lookups.
</p>
<p>The central model by contrast is simpler in that no protocol needs
to be specified for communicating between registry instances and that
lookup can be handled to a single well know instance. This model may
be preferred if the total amount of data in the registry is relatively
small (at least compared to the DNS or systems of similar scale). The
fact that the registry is operated in a single instance does not
necessarily imply lowered requirements on availability and security.
An example of this type of registry is the Time Zone Database <a class='info' href='#RFC6557'>[RFC6557]<span> (</span><span class='info'>Lear, E. and P. Eggert, “Procedures for Maintaining the Time Zone Database,” February 2012.</span><span>)</span></a>.
</p>
<p>One possible basis for a distributed registry is the Dynamic
Delegation Discovery System (DDDS) as described in <a class='info' href='#RFC3401'>[RFC3401]<span> (</span><span class='info'>Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” October 2002.</span><span>)</span></a><a class='info' href='#RFC3402'>,<span> (</span><span class='info'>Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.</span><span>)</span></a> [RFC3402]<a class='info' href='#RFC3403'>,<span> (</span><span class='info'>Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.</span><span>)</span></a> [RFC3403]<a class='info' href='#RFC3404'>and<span> (</span><span class='info'>Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI),” October 2002.</span><span>)</span></a> [RFC3404].
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4"></a><h3>2.4.
Schema</h3>
<p>As was stated in the introduction LDAP and X.509 attribute schema
is commonly used to describe attribute-types for claims-based
protocols. Recently however there is a trend towards defining "raw
attributes", i.e attribute types that are not supported by a
corresponding directory schema. Thus there may be a need to define a
"directory-neutral" attribute-type schema langue. In either case there
will probably be a need to support multiple schema in the
registry.
</p>
<p>Note that LDAP and X.509 schema have a property that is not
currently used in claims-based protocols: objectClass definitions.
These are schema elements that often list a set of mandatory and/or
optional associated attributes.
</p>
<p>Depending on he intended use of the registry there may need to
exist a native attribute schema for the registry which may or may not
need to represent the complete set of properties of each attribute
type. For instance if the intended use of the registry is to support
configuration and setup of federation, rather than in-transaction
discovery of attribute properties, the registry native schema may not
have to include all information of each attribute. Instead it would be
possible to maintain a minimal set of core properties in the registry
and provide references to external information sources that could be
chaised for additional information.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5"></a><h3>2.5.
Lookup and Search</h3>
<p>Lookup and Search may appear to be very similar operations but they
are in fact quite dissimilar in that they place very different
requirements on the representation and schema of the data to be
searched. To draw an example from the DNS again: The DNS supports
lookup but not search. In other words it is possible to, given a
domain name, lookup the corresponding records in the DNS but it is not
in general possible to search for records given knowledge of part of a
domain name.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Requrements</h3>
<p>The following terminology is used in this section:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>registry</dt>
<dd>An instance of an attribute registry
fulfilling these requirements.
</dd>
<dt>consumer</dt>
<dd>A user, device, process or other entity that
consumes information from the registry.
</dd>
<dt>attribute type</dt>
<dd>An element of the registry.
</dd>
<dt>attribute name</dt>
<dd>Synonymous with attribute type name
</dd>
</dl></blockquote>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Use</h3>
<p></p>
<ul class="text">
<li>A consumer MUST NOT directly use the registry for
in-transaction lookup.
</li>
</ul><p>The registry is primarily intended for use as a tool to help
discover attribute type information related to setup and configuration
of federations. While services that directly tie in to authentication
events (for instance in order to provide i18n of attribute friendly
names) may be needed, such services can always be developed as
commercial spin-offs from the basic registry.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Data Locality</h3>
<p></p>
<ul class="text">
<li>The registry SHOULD be established as a central,
non-distributed registry.
</li>
</ul><p>Since the primary use of the registry is not for
in-transaction lookups the registry does not need to be distributed
which reduces the complexity of the registry.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.
Naming</h3>
<p></p>
<ul class="text">
<li>The registry MUST support multiple name spaces for naming
attribute types.
</li>
<li>The registry MUST support attribute type name aliases.
</li>
<li>The registry MAY support aliases that are namespace-free short
names.
</li>
<li>The registry SHOULD (if such names are supported) impose
restrictions on registering short names.
</li>
</ul>
<p>
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.
Schema</h3>
<p></p>
<ul class="text">
<li>The registry SHOULD support a native attribute type schema.
</li>
<li>The native attribute type schema MUST map cleanly (in)to
X.520/LDAP schema for attribute types
</li>
<li>The native attribute type schema MAY only represent a subset of
the features of X.520/LDAP schema
</li>
<li>The native attribute type schema SHOULD support multiple
serializations (XML,JSON,etc)
</li>
</ul>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5.
Lookup and Search</h3>
<p></p>
<ul class="text">
<li>The registry MUST support lookup based on attribute type
name.
</li>
<li>The registry MUST support lookup based on attribute type
aliases if they are provided.
</li>
<li>The registry MAY support search but registry consumers MUST NOT
assume support for search.
</li>
</ul>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Acknowledgements</h3>
<p>This work was inspired by discussions at the ISOC identity ecosystem
workshops held in Amsterdam and Gathersburgh MD in 2011 and 2012.
</p>
<a name="Contributors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Contributors</h3>
<p>Main contributors for this work has been</p>
<ul class="text">
<li>Heather Flanagan (ISOC/Internet2)
</li>
<li>James Bryce Clark (OASIS)
</li>
</ul>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
IANA Considerations</h3>
<p>This memo includes no request to IANA.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Security Considerations</h3>
<p>Attributes are often used to carry sensitive information as part of
claims-based protocols. It is common for claims to contain attribute
values that are used to allow or deny access to a protected resource.
Some attributes carry identifiers as values. A discussion of the
security implications of handling identifiers can be found in <a class='info' href='#I-D.iab-identifier-comparison'>draft-iab-identifier-comparison<span> (</span><span class='info'>Thaler, D., “Issues in Identifier Comparison for Security Purposes,” March 2012.</span><span>)</span></a> [I‑D.iab‑identifier‑comparison].
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.iab-identifier-comparison">[I-D.iab-identifier-comparison]</a></td>
<td class="author-text">Thaler, D., “<a href="http://tools.ietf.org/html/draft-iab-identifier-comparison-01">Issues in Identifier Comparison for Security Purposes</a>,” draft-iab-identifier-comparison-01 (work in progress), March 2012 (<a href="http://www.ietf.org/internet-drafts/draft-iab-identifier-comparison-01.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3401">[RFC3401]</a></td>
<td class="author-text">Mealling, M., “<a href="http://tools.ietf.org/html/rfc3401">Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS</a>,” RFC 3401, October 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3401.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3402">[RFC3402]</a></td>
<td class="author-text">Mealling, M., “<a href="http://tools.ietf.org/html/rfc3402">Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm</a>,” RFC 3402, October 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3402.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3403">[RFC3403]</a></td>
<td class="author-text">Mealling, M., “<a href="http://tools.ietf.org/html/rfc3403">Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database</a>,” RFC 3403, October 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3403.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3404">[RFC3404]</a></td>
<td class="author-text">Mealling, M., “<a href="http://tools.ietf.org/html/rfc3404">Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</a>,” RFC 3404, October 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3404.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6557">[RFC6557]</a></td>
<td class="author-text">Lear, E. and P. Eggert, “<a href="http://tools.ietf.org/html/rfc6557">Procedures for Maintaining the Time Zone Database</a>,” BCP 175, RFC 6557, February 2012 (<a href="http://www.rfc-editor.org/rfc/rfc6557.txt">TXT</a>).</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Leif Johansson (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">NORDUnet</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:leifj@nordu.net">leifj@nordu.net</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Heather Flanagan</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Internet2</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">1000 Oakbrook Drive Suite 300</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ann Arbor, MI 48104</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+1-360-562-0319</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:hlflanagan@internet2.edu">hlflanagan@internet2.edu</a></td></tr>
</table>
</body></html>