Formatting

proposals/4108-oidc-qr-login.md

@@ -24,7 +24,7 @@ In order for the new device to be fully set up, it needs to exchange information
 
 It is proposed that an HTTP-based protocol be used to establish an ephemeral bi-directional communication session over
 which the two devices can exchange the necessary data. This session is described as "insecure" as it provides no
-end-to-end confidentiality nor authenticity by itself—these are layered on top of it.
+end-to-end confidentiality nor authenticity by itself---these are layered on top of it.
 
 #### High-level description
 
@@ -242,7 +242,7 @@ Access-Control-Expose-Headers: ETag
 ```
 
 To support usage from web browsers the rendezvous URLs should allow CORS requests from any origin and expose the headers
-which aren’t on the CORS [request header](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header) and 
+which aren't on the CORS [request header](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header) and 
 [response header](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header) safelists:
 
 ```http
@@ -394,8 +394,8 @@ with an empty payload. It parses the **id** and **server** received.
 
 Device G displays a QR code containing:
 
-- its public key **Gp**
+- Its public key **Gp**
-- the insecure rendezvous session **URL**
+- The insecure rendezvous session **URL**
 - An indicator (the **intent**) to say if this is a new device which wishes to "initiate" a login, or an existing device
 that wishes to "reciprocate" a login
 - If the intent is to reciprocate a login, then the **homeserver base URL**
@@ -618,9 +618,9 @@ Since Device G has no way of authenticating Device S, an attacker present for th
 attempt to mimic Device S in order to get their Device S signed in instead.
 
 - In step 3, Specter can shoulder surf the QR code scanning to obtain **Gp**.
-- In step 4, Specter can intercept S’s payload and replace it with a payload of their own, replacing  **Sp** with its
+- In step 4, Specter can intercept S's payload and replace it with a payload of their own, replacing  **Sp** with its
 own key.
-- The attack is only thwarted in step 7, because Device S won’t ever display the indicator of success to the user. The
+- The attack is only thwarted in step 7, because Device S won't ever display the indicator of success to the user. The
 user then must cancel the process on Device G, preventing it from sharing any sensitive material.
 
 ### The OIDC login part and set up of E2EE
@@ -928,10 +928,10 @@ Then we continue with the actual login:
 On receipt of the `m.login.protocol_accepted` message:
 
 - In accordance with [RFC8628](https://datatracker.ietf.org/doc/html/rfc8628#section-3.3.1) the new device must display
-the user_code in order that the user can confirm it on the OIDC Provider if required.
+the `user_code` in order that the user can confirm it on the OIDC Provider if required.
 - The new device then starts to poll the OIDC Provider by making
 [Device Access Token Requests](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) using the interval and bounded
-by expires_in.
+by `expires_in`.
 
 *New device => OIDC Provider via HTTP*
 
@@ -962,7 +962,7 @@ and expecting to receive an HTTP 404 response.
 If the device already exists then the login request should be rejected with an `m.login.failure` and reason `device_already_exists`.
 
 If no existing device was found then the existing device opens the `verification_uri_complete` - falling back to the
-`verification_uri`, if `verification_uri_complete` isn’t present - in a system browser.
+`verification_uri`, if `verification_uri_complete` isn't present - in a system browser.
 
 Ideally this is in a trusted/secure environment where the cookie jar and password manager features are available. e.g.
 on iOS this could be a `ASWebAuthenticationSession`
@@ -1050,7 +1050,7 @@ with the corresponding device_id (from the `m.login.protocol` message).
 It does so by calling [GET /_matrix/client/v3/devices/<device_id>](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3devicesdeviceid)
 and expecting to receive an HTTP 200 response.
 
-If the device isn’t immediately visible it can repeat the `GET` request for up to, say, 10 seconds to allow for any latency.
+If the device isn't immediately visible it can repeat the `GET` request for up to, say, 10 seconds to allow for any latency.
 
 If no device is found then the process should be stopped.