|
40 | 40 | </address>
|
41 | 41 | </author>
|
42 | 42 |
|
43 |
| - <date day="03" month="May" year="2024" /> |
| 43 | + <date day="8" month="July" year="2024" /> |
44 | 44 |
|
45 | 45 | <area>Security</area>
|
46 | 46 | <workgroup>OAuth Working Group</workgroup>
|
|
74 | 74 | This specification defines a metadata format
|
75 | 75 | enabling OAuth 2.0 clients and authorization servers to obtain information needed
|
76 | 76 | to interact with an OAuth 2.0 protected resource.
|
77 |
| - This specification is intentionally as parallel as possible to |
| 77 | + The structure and content of this specification is intentionally as parallel as possible to that of |
78 | 78 | <xref target="RFC7591">"OAuth 2.0 Dynamic Client Registration Protocol"</xref>,
|
79 | 79 | which enables a client to provide metadata about itself
|
80 | 80 | to an OAuth 2.0 authorization server and to
|
|
791 | 791 | </t>
|
792 | 792 | </section>
|
793 | 793 |
|
794 |
| - <section anchor="compatibility" title="Compatibility with other authentication methods"> |
| 794 | + <section anchor="compatibility" title="Compatibility with Other Authentication Methods"> |
795 | 795 | <t>
|
796 | 796 | Resource servers MAY return other <spanx style="verb">WWW-Authenticate</spanx> headers indicating various authentication schemes.
|
797 | 797 | This allows the resource server to support clients that may or may not implement this specification,
|
798 | 798 | and allows clients to choose their preferred authentication scheme.
|
799 | 799 | </t>
|
| 800 | + <t> |
| 801 | + A fair question is whether allowing clients to choose from among |
| 802 | + supported authentication methods represents an opportunity for a downgrade attack. |
| 803 | + Since resource servers will only enumerate authentication methods acceptable to them, by definition, |
| 804 | + any choice made by the client from among them is one that the resource server is OK with. |
| 805 | + Thus, the resource server allowing the use of different supported authentication methods |
| 806 | + does not represent an opportunity for a downgrade attack. |
| 807 | + </t> |
800 | 808 | </section>
|
801 | 809 |
|
802 | 810 | </section>
|
|
1544 | 1552 | George Fletcher,
|
1545 | 1553 | Pieter Kasselman,
|
1546 | 1554 | Tony Nadalin,
|
| 1555 | + Rifaat Shekh-Yusef, |
1547 | 1556 | Filip Skokan,
|
1548 | 1557 | and
|
1549 | 1558 | Atul Tulshibagwale
|
|
1554 | 1563 | <section anchor="History" title="Document History">
|
1555 | 1564 | <t>[[ to be removed by the RFC Editor before publication as an RFC ]]</t>
|
1556 | 1565 |
|
| 1566 | + <t> |
| 1567 | + -06 |
| 1568 | + <list style="symbols"> |
| 1569 | + <t> |
| 1570 | + Addressed shepherd review comments by Rifaat Shekh-Yusef. |
| 1571 | + </t> |
| 1572 | + </list> |
| 1573 | + </t> |
| 1574 | + |
1557 | 1575 | <t>
|
1558 | 1576 | -05
|
1559 | 1577 | <list style="symbols">
|
|
0 commit comments