Changeset 2242 for draft-ietf-httpbis/latest/p7-auth.xml
- Timestamp:
- 07/05/13 14:04:14 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.xml
r2232 r2242 314 314 </section> 315 315 316 <section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">317 <t>318 The HTTP Authentication Scheme Registry defines the name space for the319 authentication schemes in challenges and credentials.320 </t>321 <t>322 Registrations &MUST; include the following fields:323 <list style="symbols">324 <t>Authentication Scheme Name</t>325 <t>Pointer to specification text</t>326 <t>Notes (optional)</t>327 </list>328 </t>329 <t>330 Values to be added to this name space require IETF Review331 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).332 </t>333 <t>334 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.335 </t>336 337 <section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">338 <t>339 There are certain aspects of the HTTP Authentication Framework that put340 constraints on how new authentication schemes can work:341 </t>342 <t>343 <list style="symbols">344 <x:lt>345 <t>346 HTTP authentication is presumed to be stateless: all of the information347 necessary to authenticate a request &MUST; be provided in the request,348 rather than be dependent on the server remembering prior requests.349 Authentication based on, or bound to, the underlying connection is350 outside the scope of this specification and inherently flawed unless351 steps are taken to ensure that the connection cannot be used by any352 party other than the authenticated user353 (see &msg-orient-and-buffering;).354 </t>355 </x:lt>356 <x:lt>357 <t>358 The authentication parameter "realm" is reserved for defining Protection359 Spaces as defined in <xref target="protection.space"/>. New schemes360 &MUST-NOT; use it in a way incompatible with that definition.361 </t>362 </x:lt>363 <x:lt>364 <t>365 The "token68" notation was introduced for compatibility with existing366 authentication schemes and can only be used once per challenge or credential.367 New schemes thus ought to use the "auth-param" syntax instead, because368 otherwise future extensions will be impossible.369 </t>370 </x:lt>371 <x:lt>372 <t>373 The parsing of challenges and credentials is defined by this specification,374 and cannot be modified by new authentication schemes. When the auth-param375 syntax is used, all parameters ought to support both token and376 quoted-string syntax, and syntactical constraints ought to be defined on377 the field value after parsing (i.e., quoted-string processing). This is378 necessary so that recipients can use a generic parser that applies to379 all authentication schemes.380 </t>381 <t>382 &Note; The fact that the value syntax for the "realm" parameter383 is restricted to quoted-string was a bad design choice not to be repeated384 for new parameters.385 </t>386 </x:lt>387 <x:lt>388 <t>389 Definitions of new schemes ought to define the treatment of unknown390 extension parameters. In general, a "must-ignore" rule is preferable391 over "must-understand", because otherwise it will be hard to introduce392 new parameters in the presence of legacy recipients. Furthermore,393 it's good to describe the policy for defining new parameters (such394 as "update the specification", or "use this registry").395 </t>396 </x:lt>397 <x:lt>398 <t>399 Authentication schemes need to document whether they are usable in400 origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),401 and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).402 </t>403 </x:lt>404 <x:lt>405 <t>406 The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to407 the User Agent, and therefore have the same effect on HTTP caches as the408 "private" Cache-Control response directive (&caching-rsd-private;),409 within the scope of the request they appear in.410 </t>411 <t>412 Therefore, new authentication schemes that choose not to carry413 credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined414 header field) will need to explicitly disallow caching, by mandating the use of415 either Cache-Control request directives (e.g., "no-store",416 &caching-rqd-no-store;) or response directives (e.g., "private").417 </t>418 </x:lt>419 </list>420 </t>421 </section>422 423 </section>424 425 316 </section> 426 317 … … 597 488 <section title="IANA Considerations" anchor="IANA.considerations"> 598 489 599 <section title="Authentication Scheme Registry" anchor="authentication.scheme.registration"> 600 <t> 601 The registration procedure for HTTP Authentication Schemes is defined by 602 <xref target="authentication.scheme.registry"/> of this document. 603 </t> 604 <t> 605 The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>. 606 </t> 490 <section title="Authentication Scheme Registry" anchor="authentication.scheme.registry"> 491 <t> 492 The HTTP Authentication Scheme Registry defines the name space for the 493 authentication schemes in challenges and credentials. It is maintained at 494 <eref target="http://www.iana.org/assignments/http-authschemes"/>. 495 </t> 496 497 <section title="Procedure" anchor="authentication.scheme.registry.procedure"> 498 <t> 499 Registrations &MUST; include the following fields: 500 <list style="symbols"> 501 <t>Authentication Scheme Name</t> 502 <t>Pointer to specification text</t> 503 <t>Notes (optional)</t> 504 </list> 505 </t> 506 <t> 507 Values to be added to this name space require IETF Review 508 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). 509 </t> 510 </section> 511 512 <section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes"> 513 <t> 514 There are certain aspects of the HTTP Authentication Framework that put 515 constraints on how new authentication schemes can work: 516 </t> 517 <t> 518 <list style="symbols"> 519 <x:lt> 520 <t> 521 HTTP authentication is presumed to be stateless: all of the information 522 necessary to authenticate a request &MUST; be provided in the request, 523 rather than be dependent on the server remembering prior requests. 524 Authentication based on, or bound to, the underlying connection is 525 outside the scope of this specification and inherently flawed unless 526 steps are taken to ensure that the connection cannot be used by any 527 party other than the authenticated user 528 (see &msg-orient-and-buffering;). 529 </t> 530 </x:lt> 531 <x:lt> 532 <t> 533 The authentication parameter "realm" is reserved for defining Protection 534 Spaces as defined in <xref target="protection.space"/>. New schemes 535 &MUST-NOT; use it in a way incompatible with that definition. 536 </t> 537 </x:lt> 538 <x:lt> 539 <t> 540 The "token68" notation was introduced for compatibility with existing 541 authentication schemes and can only be used once per challenge or credential. 542 New schemes thus ought to use the "auth-param" syntax instead, because 543 otherwise future extensions will be impossible. 544 </t> 545 </x:lt> 546 <x:lt> 547 <t> 548 The parsing of challenges and credentials is defined by this specification, 549 and cannot be modified by new authentication schemes. When the auth-param 550 syntax is used, all parameters ought to support both token and 551 quoted-string syntax, and syntactical constraints ought to be defined on 552 the field value after parsing (i.e., quoted-string processing). This is 553 necessary so that recipients can use a generic parser that applies to 554 all authentication schemes. 555 </t> 556 <t> 557 &Note; The fact that the value syntax for the "realm" parameter 558 is restricted to quoted-string was a bad design choice not to be repeated 559 for new parameters. 560 </t> 561 </x:lt> 562 <x:lt> 563 <t> 564 Definitions of new schemes ought to define the treatment of unknown 565 extension parameters. In general, a "must-ignore" rule is preferable 566 over "must-understand", because otherwise it will be hard to introduce 567 new parameters in the presence of legacy recipients. Furthermore, 568 it's good to describe the policy for defining new parameters (such 569 as "update the specification", or "use this registry"). 570 </t> 571 </x:lt> 572 <x:lt> 573 <t> 574 Authentication schemes need to document whether they are usable in 575 origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>), 576 and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>). 577 </t> 578 </x:lt> 579 <x:lt> 580 <t> 581 The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to 582 the User Agent, and therefore have the same effect on HTTP caches as the 583 "private" Cache-Control response directive (&caching-rsd-private;), 584 within the scope of the request they appear in. 585 </t> 586 <t> 587 Therefore, new authentication schemes that choose not to carry 588 credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined 589 header field) will need to explicitly disallow caching, by mandating the use of 590 either Cache-Control request directives (e.g., "no-store", 591 &caching-rqd-no-store;) or response directives (e.g., "private"). 592 </t> 593 </x:lt> 594 </list> 595 </t> 596 </section> 607 597 </section> 608 598 … … 1176 1166 "Editorial suggestions" 1177 1167 </t> 1168 <t> 1169 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/464"/>: 1170 "placement of extension point considerations" 1171 </t> 1178 1172 </list> 1179 1173 </t>
Note: See TracChangeset
for help on using the changeset viewer.