[Technical] The recommended “UE fetches external resources directly over HTTPS” conflicts with the IMS Data Channel concept if the UE is expected to be confined to the DC media plane; the contribution does not state whether such external HTTPS uses the normal IP bearer outside IMS, nor how this aligns with any assumed operator policy that DC apps’ traffic stays within the IMS/DC path.

[Technical] The proposal assumes the DC AS can reliably enforce security by sending CSP, but it does not address the trust model for the DC AS itself (authentication of the DC AS origin, integrity of delivered headers/content, and binding of the web origin to the DC AS) which is essential before CSP can be meaningful in a 3GPP-delivered web app context.

[Technical] “Fully compatible with all web browsers” is overstated: CSP enforcement and especially nonce/strict-dynamic behavior varies across engines and embedded WebViews, and the document does not discuss minimum browser requirements or fallback behavior for UEs that do not support the needed CSP directives.

[Technical] The document treats CORS as a straightforward opt-in by the external origin, but OAuth flows often involve redirects, iframes/popups, and third-party cookies; the contribution does not analyze modern browser privacy restrictions (e.g., third‑party cookie blocking, Storage Access API) that can break the proposed “frame-src/form-action to auth domain” patterns.

[Technical] The proxy-tunnel critique assumes “one external destination maps to one application data channel” and requires SDP renegotiation per destination; this is not justified against TS 26.114/SDP usage (e.g., multiplexing multiple HTTP/TLS connections over a single SCTP stream or multiple streams under one negotiated data channel), so the scaling argument may be partially based on an unnecessarily constrained design.

[Technical] The MF egress-IP attribution issues (rate limiting, geolocation, abuse) are valid for a centralized proxy, but the document does not consider mitigations that could preserve per-user attribution without TLS termination (e.g., CONNECT-style tunneling with per-UE source identity signaling, or IPv6 prefix delegation/unique egress per UE), weakening the “rejected approach” conclusion.

[Technical] The CSP examples omit directives relevant to the stated use cases: WebSockets/SSE/HTTP streaming are covered by connect-src, but if the app loads external scripts/fonts/images as claimed, the example policies still default most resource classes to 'self' and do not show the necessary script-src/img-src/font-src allowances for third-party subresources.

[Technical] The contribution proposes TR 26.814 clarifications but does not identify exact clauses to change nor normative impact; without pinpointing where TR text currently constrains external fetching, it’s unclear whether this is a genuine spec gap or simply an implementation guidance note.

[Technical] The “application origin = DC AS” statement needs precision: web origin is scheme+host+port, but DC delivery over IMS DC is not inherently an HTTPS origin; the document does not specify how the browser maps DC-delivered content to an origin (e.g., https://dcas.example), which is critical for same-origin, CSP, and CORS to function.

[Technical] The LI discussion is hand-wavy and potentially contradictory: recommending end-to-end TLS to external origins while also suggesting SA4 document “decrypted content at network element” cases needs clearer separation of scenarios (DC media vs external HTTPS) and explicit statement of what 3GPP can/cannot require for LI in each.

[Editorial] Several claims are absolute without qualification (e.g., “extreme security risks,” “fully compatible with all web browsers,” “keeps OAuth flows predictable”); these should be softened or backed by concrete references to web standards and known browser behaviors.

[Editorial] References are incomplete/inconsistent: the text cites TS 26.114 and TS 24.229 for SDP and SIP procedures but does not cite the specific clauses, nor does it reference the relevant W3C specs for CSP/CORS/OAuth redirect handling, making it hard to validate the proposed “standard web security model” alignment.