Remove trailing whitespace

Author: danielfett

.vscode/settings.json

@@ -0,0 +1,6 @@
+{
+    "yaml.customTags": [
+        "!sd scalar"
+    ],
+    "files.trimTrailingWhitespace": true
+}

attacks-and-mitigations.md

@@ -31,7 +31,7 @@
    * Clarified references to attacker model by including a link to (#secmodel)
    * Clarified description of "CSRF tokens" and reference to RFC6819
    * Described that OIDC can prevent access token injection
-   * Updated references 
+   * Updated references
 
    -19
 
@@ -44,7 +44,7 @@
    * Change wording for disallowing HTTP redirect URIs.
 
    -17
-   
+
    * Make the use of metadata RECOMMENDED for both servers and clients
    * Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)
    * AS also MUST NOT expose open redirectors.
@@ -54,7 +54,7 @@
    * Make HTTPS mandatory for most redirect URIs.
 
    -16
-   
+
    * Make MTLS a suggestion, not RECOMMENDED.
    * Add important requirements when using nonce for code injection protection.
    * Highlight requirements for refresh token sender-constraining.
@@ -67,16 +67,16 @@
    * Update reference to DPoP
    * Fix reference to RFC8414
    * Move to xml2rfcv3
-   
+
    -14
-   
+
    * Added info about using CSP to prevent clickjacking
    * Changes from WGLC feedback
    * Editorial changes
    * AS MUST announce PKCE support either in metadata or using deployment-specific ways (before: SHOULD)
-   
+
    -13
-   
+
    * Discourage use of Resource Owner Password Credentials Grant
    * Added text on client impersonating resource owner
    * Recommend asymmetric methods for client authentication
@@ -85,18 +85,18 @@
    * AS SHOULD publish PKCE support
    * Cleaned up discussion on auth code injection
    * AS MUST support PKCE
-   
+
    -12
-   
+
    * Added updated attacker model
-   
+
    -11
-   
+
    * Adapted section 2.1.2 to outcome of consensus call
    * more text on refresh token inactivity and implementation note on refresh token replay detection via refresh token rotation
 
    -10
-   
+
    * incorporated feedback by Joseph Heenan
    * changed occurrences of SHALL to MUST
    * added text on lack of token/cert binding support tokens issued in

documenthistory.md

@@ -27,7 +27,7 @@ fullname="John Bradley"
 organization="Yubico"
     [author.address]
     email = "[email protected]"
-    
+
 [[author]]
 initials="A."
 surname="Labunets"
@@ -43,10 +43,10 @@ fullname="Daniel Fett"
 organization="Authlete"
     [author.address]
     email = "[email protected]"
-    
+
 %%%
 
-.# Abstract 
+.# Abstract
 
 This document describes best current security practice for OAuth 2.0.
 It updates and extends the OAuth 2.0 Security Threat Model to

draft-ietf-oauth-security-topics.md

@@ -12,16 +12,16 @@ challenges can be observed:
 	  in the OAuth 2.0 Threat Model and Security Considerations [@!RFC6819],
    	continued exploitation demonstrates a need for more specific
 	  recommendations, easier to implement mitigations, and more defense in depth.
-    
+
   * OAuth is being used in environments with higher security requirements than
     considered initially, such as Open Banking, eHealth, eGovernment, and
     Electronic Signatures. Those use cases call for stricter guidelines and
     additional protection.
-	  
+
   * OAuth is being used in much more dynamic setups than originally anticipated,
 	  creating new challenges with respect to security. Those challenges go beyond
 	  the original scope of [@!RFC6749], [@!RFC6750], and [@!RFC6819].
-    
+
     OAuth initially assumed static relationships between client,
     authorization server, and resource servers. The URLs of the AS and RS were
     known to the client at deployment time and built an anchor for the
@@ -39,11 +39,11 @@ challenges can be observed:
     Protocol [@RFC7591] and OAuth 2.0 Authorization Server Metadata
     [@RFC8414] were developed to support the use of OAuth in
     dynamic scenarios.
-	  
+
   * Technology has changed. For example, the way browsers treat fragments when
 	  redirecting requests has changed, and with it, the implicit grant's
 	  underlying security model.
-	  
+
 This document provides updated security recommendations to address
 these challenges. It does not supplant the security advice given in
 [@!RFC6749], [@!RFC6750], and [@!RFC6819], but complements those
@@ -56,7 +56,7 @@ insecure. Naturally, not all existing ecosystems and implementations are
 compatible with the new requirements and following the best practices described in
 this document may break interoperability. Nonetheless, it is RECOMMENDED that
 implementers upgrade their implementations and ecosystems when feasible.
-	  
+
 ## Structure
 
 The remainder of this document is organized as follows: The next section

introduction.md

@@ -8,8 +8,8 @@
 {{attacks-and-mitigations.md}}
 
 # Acknowledgements {#Acknowledgements}
-      
-We would like to thank 
+
+We would like to thank
 Brock Allen,
 Annabelle Richard Backman,
 Dominick Baier,
@@ -46,14 +46,14 @@ Tim Wuertele,
 David Waite and
 Hans Zandbelt
 for their valuable feedback.
-    
+
 
 # IANA Considerations {#IANA}
-      
+
 This draft makes no requests to IANA.
-    
+
 
 # Security Considerations {#Security}
-      
+
 Security considerations are described in (#recommendations), (#secmodel), and (#attacks_and_mitigations).
-    
+

mainmatter.md

@@ -1,5 +1,5 @@
 # Best Practices {#recommendations}
-    
+
 This section describes the set of security mechanisms and measures the OAuth
 working group considers best practices at the time of writing.
 
@@ -27,13 +27,13 @@ the `nonce` parameter provides CSRF protection. Otherwise, one-time
 use CSRF tokens carried in the `state` parameter that are securely
 bound to the user agent MUST be used for CSRF protection (see
 (#csrf_countermeasures)).
-        
+
 When an OAuth client can interact with more than one authorization server, a
 defense against mix-up attacks (see (#mix_up)) is REQUIRED. To this end, clients
-SHOULD 
+SHOULD
 
   * use the `iss` parameter as a countermeasure according to
-    [@!RFC9207], or 
+    [@!RFC9207], or
   * use an alternative countermeasure based on an `iss` value in the
     authorization response (such as the `iss` Claim in the ID Token in
     [@!OpenID.Core] or in [@JARM] responses), processing it as described in
@@ -54,15 +54,15 @@ Clients MUST prevent authorization code
 injection attacks (see (#code_injection)) and misuse of authorization codes using one of the following options:
 
  * Public clients MUST use PKCE [@!RFC7636] to this end, as motivated in
-   (#pkce_as_injection_protection). 
+   (#pkce_as_injection_protection).
  * For confidential clients, the use of PKCE [@!RFC7636] is RECOMMENDED, as it
    provides a strong protection against misuse and injection of authorization
    codes as described in (#pkce_as_injection_protection) and, as a side-effect,
    prevents CSRF even in presence of strong attackers as described in
-   (#csrf_countermeasures). 
+   (#csrf_countermeasures).
  * With additional precautions, described in (#nonce_as_injection_protection),
    confidential OpenID Connect [@!OpenID.Core] clients MAY use the `nonce` parameter and the
-   respective Claim in the ID Token instead. 
+   respective Claim in the ID Token instead.
 
 In any case, the PKCE challenge or OpenID Connect `nonce` MUST be
 transaction-specific and securely bound to the client and the user agent in
@@ -97,20 +97,20 @@ the client to detect PKCE support). ASs MAY instead provide a
 deployment-specific way to ensure or determine PKCE support by the AS.
 
 ### Implicit Grant {#implicit_grant_recommendation}
-    
+
 The implicit grant (response type "token") and other response types
 causing the authorization server to issue access tokens in the
 authorization response are vulnerable to access token leakage and
 access token replay as described in (#insufficient_uri_validation),
 (#credential_leakage_referrer), (#browser_history), and
 (#access_token_injection).
-    
-Moreover, no viable method for sender-constraining exists to 
+
+Moreover, no viable method for sender-constraining exists to
 bind access tokens to a specific client (as recommended in
 (#token_replay_prevention)) when the access tokens are issued in the
 authorization response. This means that an attacker can use leaked or stolen
 access token at a resource endpoint.
-    
+
 In order to avoid these issues, clients SHOULD NOT use the implicit
 grant (response type "token") or other response types issuing
 access tokens in the authorization response, unless access token injection
@@ -129,7 +129,7 @@ sender-constrain the issued tokens (see next section).
 ## Token Replay Prevention {#token_replay_prevention}
 
 ### Access Tokens
- 
+
 A sender-constrained access token scopes the applicability of an access
 token to a certain sender. This sender is obliged to demonstrate knowledge
 of a certain secret as prerequisite for the acceptance of that token at
@@ -164,7 +164,7 @@ the access token with certain resource servers and every resource
 server is obliged to verify, for every request, whether the access
 token sent with that request was meant to be used for that particular
 resource server. If not, the resource server MUST refuse to serve the
-respective request. The `aud` claim as defined in [@!RFC9068] MAY be 
+respective request. The `aud` claim as defined in [@!RFC9068] MAY be
 used to audience-restrict access tokens. Clients and authorization servers MAY utilize the
 parameters `scope` or `resource` as specified in [@!RFC6749] and
 [@RFC8707], respectively, to determine the
@@ -211,10 +211,10 @@ methods more robust against a number of attacks.
 ## Other Recommendations
 
 The use of OAuth Metadata [@!RFC8414] can help to improve the security of OAuth
-deployments: 
+deployments:
 
  * It ensures that security features and other new OAuth features can be enabled
-   automatically by compliant software libraries. 
+   automatically by compliant software libraries.
  * It reduces chances for misconfigurations, for example misconfigured endpoint
    URLs (that might belong to an attacker) or misconfigured security features.
  * It can help to facilitate rotation of cryptographic keys and to ensure

recommendations.md

@@ -95,7 +95,7 @@
     </author>
     <date day="27" month="April" year="2015"/>
   </front>
-</reference>       
+</reference>
 
 
 <reference anchor="oauth_security_ubc" target="http://passwordresearch.com/papers/paper267.html">
@@ -110,7 +110,7 @@
     <date month="October" year="2012"/>
   </front>
   <format target="http://passwordresearch.com/papers/paper267.html" type="HTML" />
-</reference> 
+</reference>
 
 <reference anchor="oauth_security_cmu" target="http://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf">
   <front>
@@ -126,7 +126,7 @@
     </author>
     <author initials="Y." surname="Tian" fullname="Yuan Tian">
       <organization abbrev="CMU">Carnegie Mellon University</organization>
-    </author>          
+    </author>
     <author initials="R." surname="Kotcher" fullname="Robert Kotcher">
       <organization abbrev="CMU">Carnegie Mellon University</organization>
     </author>
@@ -208,7 +208,7 @@
 
 <reference anchor="WebAuthn" target="https://www.w3.org/TR/2019/REC-webauthn-1-20190304/">
   <front>
-    <title>Web Authentication: An API for accessing Public Key Credentials Level 1</title>    
+    <title>Web Authentication: An API for accessing Public Key Credentials Level 1</title>
     <author fullname="Dirk Balfanz" surname="Balfanz" initials="D."><organization>Google</organization></author>
     <author fullname="Alexei Czeskis" surname="Czeskis" initials="A."><organization>Google</organization></author>
     <author fullname="Jeff Hodges" surname="Hodges" initials="J."><organization>Google</organization></author>

references.md

@@ -16,41 +16,41 @@ least against the following attackers:
     of network endpoints including browsers and servers (except for
     the concrete RO, AS, and RS). Web attackers may set up web sites
     that are visited by the RO, operate their own user agents, and
-    participate in the protocol. 
-    
+    participate in the protocol.
+
     Web attackers may, in particular, operate OAuth clients that are
     registered at AS, and operate their own authorization and resource
     servers that can be used (in parallel) by the RO and other
     resource owners.
-    
+
     It must also be assumed that web attackers can lure the user to
     open arbitrary attacker-chosen URIs at any time. In practice, this
     can be achieved in many ways, for example, by injecting malicious
     advertisements into advertisement networks, or by sending
     legitimate-looking emails.
-    
+
     Web attackers can use their own user credentials to create new
     messages as well as any secrets they learned previously. For
     example, if a web attacker learns an authorization code of a user
     through a misconfigured redirect URI, the web attacker can then
     try to redeem that code for an access token.
-    
+
     They cannot, however, read or manipulate messages that are not
     targeted towards them (e.g., sent to a URL controlled by a
     non-attacker controlled AS).
-    
+
   * (A2) Network Attackers that additionally have full control over
     the network over which protocol participants communicate. They can
     eavesdrop on, manipulate, and spoof messages, except when these
     are properly protected by cryptographic methods (e.g., TLS).
     Network attackers can also block arbitrary messages.
-    
+
 While an example for a web attacker would be a customer of an internet
 service provider, network attackers could be the internet service
 provider itself, an attacker in a public (wifi) network using ARP
 spoofing, or a state-sponsored attacker with access to internet
 exchange points, for instance.
-    
+
 These attackers conform to the attacker model that was used in formal analysis
 efforts for OAuth [@arXiv.1601.01229]. This is a minimal attacker model.
 Implementers MUST take into account all possible types of attackers in the
@@ -61,7 +61,7 @@ the following, stronger attackers in addition to those listed above:
   * (A3) Attackers that can read, but not modify, the contents of the
     authorization response (i.e., the authorization response can leak
     to an attacker).
-    
+
     Examples for such attacks include open redirector attacks, insufficient
     checking of redirect URIs (see (#insufficient_uri_validation)), problems
     existing on mobile operating systems (where different apps can register
@@ -77,9 +77,9 @@ the following, stronger attackers in addition to those listed above:
     access token may be sent to an attacker-controlled resource server
     due to a misconfiguration, or an RO is social-engineered into
     using a attacker-controlled RS. See also (#comp_res_server).
-    
+
 (A3), (A4) and (A5) typically occur together with either (A1) or (A2).
-Attackers can collaborate to reach a common goal. 
+Attackers can collaborate to reach a common goal.
 
 Note that in this attacker model, an attacker (see A1) can be a RO or
 act as one. For example, an attacker can use his own browser to replay
@@ -89,4 +89,4 @@ above at the client or RS.
 This document focusses on threats resulting from these attackers.
 Attacks in an even stronger attacker model are discussed, for example,
 in [@arXiv.1901.11520].
-    
+