jiebi/CodeConvo huggingface dataset:
Code change:
fixes URL
Thanks NAME I like it, I updated the PR
Because the UI and the backend APIs can be hosted from the same backend application, Anti-forgery tokens can also be used to protect against CSRF.
There are indeed various CSRF defenses that could be used in this architecture. The two options discussed in the current document explicitly focus on defenses that are part of the core web platform, and require minimal effort from the developer to implement. The use of anti-forgery cookies requires code on both the frontend and the backend to guarantee their effectiveness. Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?
I thought it would be good to add this as it is per default supported in some tech stacks and so easy to use. People reading the doc might read it as only the mentioned ways protect against CSRF. Adding this would make the recommendations more complete. “Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?” In my opinion, there are no benefits compared with the other two options, just another option. Samesite cookies/ anti-forgery cookies are also a viable option. If the used tech stack has this already supported per default, then there is less to do as a developer. This would make it an option.
NAME I am open to listing out this option as well for the scenario you mention. Do you have text you could suggest that captures this?
Hi NAME I'll write something Kind regards Damien
NAME NAME I created a PR with an initial draft. I don't think we should explain how it works because this is not the scope of this doc. kind regards Damien
Thanks for the suggestion NAME I believe it is important to explain why this addition is there, so I've taken a stab at rewording (see below). I have also removed some of the implementation details that are not necessarily relevant (e.g., the use of HTTPS). I also removed the note on encryption, since the value in the cookie is typically random, so there would be no need to encrypt the cookie. Let me know what you think.

Related discussion:
text: the frontend and the BFF do not require any preflights, so there's no additional overhead. <ins> 6.1.3.3.3. Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies.  This mechanism relies on a session- specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie.  The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identify legitimate requests.  When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. Note that this mechanism is not necessarily recommended over the CORS approach.  However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. </ins> 6.1.3.4. In the BFF pattern, all OAuth responsibilities have been moved to the
Code change:
The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.

Related discussion:
text: 6.3.2.4.2. <ins> In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. 6.3.2.4.3. </ins> Browser-based applications MUST prevent CSRF attacks against their redirect URI.  This can be accomplished by any of the below:
Code change:
The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.

Related discussion:
text: Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <del> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run hidden iframe-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </del> 10. This document does not require any IANA actions.
Code change:
This PR offers an alternative to . Compared to PR it makes two changes: I removed the newly added text to avoid creating confusion between the responsibilities of a BFF. While it is technically possible to deploy a BFF as part of an API gateway, I believe this suggestion may create confusion for someone trying to grasp the pattern. An API Gateway is closely linked to an API, while a BFF is (in theory) closely linked to a frontend. Reworded the benefits of the Token Mediating Backend to more accurately represent the advantages/disadvantages of the pattern, as correctly suggested by this PR If this PR is merged, can be closed.

Related discussion:
text: The token-mediating backend pattern is more lightweight than the BFF pattern (See pattern-bff), since it does not require the proxying of <del> all requests to a resource server, which improves latency and significantly simplifies deployment.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </del> <ins> all requests and responses between the JavaScript application and the resource server.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </ins> If an attacker is able to execute malicious code within the JavaScript application, the application architecture is able to
Code change:
Arrow C is referenced in the text "[The code in the browser] obtains an access token via a POST request (C).". The arrow should have an arrowhead on both ends as it symbolizes both the token request and token response. "The JavaScript app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs." I think this sentence was misleading, because as of today there is no way for the app to store tokens securely in the browser. Arrow E was not referenced in the text.

Related discussion:
text: The code in the browser initiates the authorization code flow with the PKCE extension (described in authorization_code_flow) (B) above, and obtains an access token via a POST request (C).  The JavaScript <del> app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs. </del> <ins> application is then responsible for storing the access token (and optional refresh token) as securely as possible using appropriate browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </ins> When the JavaScript application in the browser wants to make a <del> request to the Resource Server, it can include the access token in the request (D) and make the request directly. </del> <ins> request to the Resource Server, it can interact with the Resource Server directly.  It includes the access token in the request (D) and receives the Resource Server's response (E). </ins> In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to
Code change:
Refined the trusted device section to make it clear that restricting to a specific device type is another option to limit the impact of deploying cross-device flows (issue )
Limit it to specific devices.

Related discussion:
text: described in this document.  By restricting the protocol to only be executed on devices trusted by the authorization server, it prevents attackers from using arbitrary devices, or by mimicking devices to <del> initiate the protocol.  Trusted devices include devices that are pre- registered with the authorization server or are subject to device management policies.  Device management policies may enforce </del> <ins> initiate the protocol. Authorization Servers MAY use different mechanisms to establish which devices it trusts.  This includes limiting cross-device flows to specific device types such as intractive whiteboards or smart TVs, pre-registering devices with the authorization server or only allow cross-device flows on devices managed through device management systems.  Device management systems may enforce policies that govern </ins> patching, version updates, on-device anti-malware deployment, revocation status and device location amongst others.  Trusted <del> devices may have their identities rooted in hardware (e.g., a TPM or equivalent technology).  By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </del> <ins> devices MAY have their identities rooted in hardware (e.g., a TPM or equivalent technology). By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </ins> An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to
Code change:
Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.

Related discussion:
text: credential.  In preserving the context, it should be clear to the user who invoked the flow, why it was invoked and what the consequence of completing the authorization, authentication or <del> credential presentation is.  The user experience should reinforce the </del> <ins> credential presentation is.  The user experience SHOULD reinforce the </ins> message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> This information MAY be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under
Code change:
Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.

Related discussion:
text: trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). <del> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </del> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. <del> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.
Code change:
Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.

Related discussion:
text: it in the CAD application, after which the CAD application displays the user's most recent designs. <ins> 2.4.9. A network administrator wants to access an adminstration portal used to configure network assets and deploy new applications.  When attempting to access the service, the network administrator receives a notification in an app on their mobile device, requesting them to confirm access to the portal.  The network administrator approves the request on their mobile phone and is granted access to the portal. </ins> 3. Attackers exploit cross-device flows by initiating an authorization
Code change:
Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.

Related discussion:
text: 3.4.10. <ins> An attacker attempts to access an adminstration portal repeatedly, generating a stream of authorization requests to the network administrator.  The attempts are timed to occur while the administrator is asleep.  The administrator is woken by the incoming requests on their phone, and, in an attempt to stop the notifications, they accidentally approve access and the attacker gains access to the portal. 3.4.11. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications and
Code change:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Related discussion:
text: 3.4.5. <ins> An attacker obtains the contact information for a user and contacts them, pretending to be a representative of the user's financial institution.  The attacker informs the user that there were a number of fraudulent transactions against their account and asks them to review these transactions by approving or rejecting them.  The attacker then triggers a sequence of transactions.  The user receives an authorization request for each transaction and declines them as they do not recognize them.  The attacker then informs the user that they need to close the users account and transfer all the funds to a new account to prevent further fraudulent transactions.  The user receives another authorization request which they approve, or provide additional authorization information to the attacker which enables the attacker to complete their attack and defraud the user. 3.4.6. </ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code
Code change:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Related discussion:
text: access as an entry point and perform lateral moves to obtain additional privileges and access to restricted resources. <del> 3.4.6. </del> <ins> 3.4.7. </ins> An attacker initiates an employee onboarding flow and obtains a QR code from the onboarding portal to invoke a digital wallet and
Code change:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Related discussion:
text: to obtain the QR code displays a message to the attacker with instructions on how to access their account. <del> 3.4.7. </del> <ins> 3.4.8. </ins> An attacker creates a message to all employees of a company, claiming to be from the company's IT service provider.  They claim that they
Code change:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Related discussion:
text: send the QR code to the attacker.  The attacker scans the QR code with their mobile phone and access the users data and resources. <del> 3.4.8. </del> <ins> 3.4.9. </ins> An attacker wants to use some website which requires presentation of a verifiable credential for authentication.  The attacker creates a
Code change:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Related discussion:
text: the credentials are presented, the original session from the attackers device is authorized with the user's credentials. <del> 3.4.9. </del> <ins> 3.4.10. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding
Code change:
Alternative name for authenticated flow (see )
Can we find a better name for the "Authenticated Flow" mitigation?
Additional authentication on consumption device Initial authentication on consumption device Authenticate before initiating cross-device flow. Authenticate on consumption device before initiating cross-device flow. Cross-Device Flow with previous authentication Authenticate before initiating cross-device flow.
Thanks, approved with minor editorial changes

Related discussion:
text: phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow. <del> Starting with an authenticated flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </del> <ins> Authenticating on the Consumption Device before starting a cross- device flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. </ins> 5.1.16.
Code change:
See issue
Closing issue
Add reference to VC presenation specs in section 4 and section 2.2.1
Only adding references to section 4. Adding this in section 2.2.1 will be confusing, even though a QR code is being scanned in these protocols, unlike device code flow, the session does not revert back to the consumption device.
Addressed in PR
Looks good to me, one small editorial change.

Related discussion:
text: The Device Authorization Grant (RFC8628) is an example of a cross- device flow that relies on the user copying information from the <del> Consumption Device to the Authorization Device.  The figure below shows a typical example of this flow: </del> <ins> Consumption Device to the Authorization Device by either entering data manually or scanning a QR code.  The figure below shows a typical example of this flow: </ins> 2.1.2.