Remove the metadata key from the file upload session creation request

* The file's contents are always the authoritative source of truth
* PyPI is actively moving toward extracting metadata from the file.

Also, add a little clarifying text to the Security Implications section.

Author: warsaw

peps/pep-0694.rst

@@ -733,7 +733,6 @@ The request looks like:
       "filename": "foo-1.0.tar.gz",
       "size": 1000,
       "hashes": {"sha256": "...", "blake2b": "..."},
-      "metadata": "...",
       "mechanism": "http-post-bytes"
     }
 
@@ -769,16 +768,11 @@ Besides the standard ``meta`` key, the request JSON has the following additional
     A client **MAY** send a mechanism that is not advertised in cases where server operators have
     documented a new or upcoming mechanism that is available for use on a "pre-release" basis.
 
-``metadata`` (**optional**)
-    If given, this is a string value containing the file's `core metadata
-    <https://packaging.python.org/en/latest/specifications/core-metadata/>`_.
-
 Servers **MAY** use the data provided in this request to do some sanity checking prior to allowing
 the file to be uploaded.  These checks may include, but are not limited to:
 
 - checking if the ``filename`` already exists in a published release;
-- checking if the ``size`` would exceed any project or file quota;
-- checking if the contents of the ``metadata``, if provided, are valid.
+- checking if the ``size`` would exceed any project or file quota.
 
 A publishing session **MAY** be created for a ``name`` and ``version`` that has already been published, for
 example to add wheels for additional platforms to an existing release.  However, because published artifacts
@@ -1305,6 +1299,9 @@ A suggested approach:
 Security Implications
 =====================
 
+Name squatting potential
+------------------------
+
 Does PEP 694 make it easier to (maliciously) register project names, i.e. to name- or typo-squat?  The authors
 do not believe so.  With the legacy API, it's trivially easy to create and upload a dummy package to register
 a project name.  This PEP does not effectively change that equation either way, nor does it aim to.  That
@@ -1313,6 +1310,9 @@ rate limiting either the legacy API or Upload 2.0 API for empty packages or sess
 which supports organizations or :pep:`752`-style implicit namespaces, could implement different rate limiting
 rules for different actors.  Such implementations are left as index-specific policy decisions.
 
+Session authorization
+---------------------
+
 Session access is authorized contemporaneously rather than being bound to the credentials that created the
 session (see :ref:`authentication`).  Indexes **MUST** re-validate authorization on each session request --
 including artifact uploads, file upload session completion, session extension requests, and publishing -- so
@@ -1328,15 +1328,22 @@ but who has already obtained the stage URL -- retains read-only preview access t
 session is published or canceled.  This is a narrow and accepted limitation; an index that considers it a
 concern can mitigate it by canceling the affected session, or by limiting session lifetimes and extensions.
 
+Malware hosting potential
+-------------------------
+
 Staged releases, while useful for testing and embargoes, do provide some potential for larger scale hosting of
-malware which isn't detectable by third party, external scanning tools, because staged artifacts are only
+malware which isn't detectable by third party external scanning tools, because staged artifacts are only
 visible to clients which hold the stage token/url.  It's not clear how much proactive malware scanning is
 actually going on today with indexes such as PyPI, so it's unclear whether the (optional) staging feature is
 much of an additional malware vector.  Indexes should likely do some amount of proactive malware scanning on
-all artifacts, regardless of the protocol used to upload them.  Indexes can also mitigate the problem by
-putting limits on session extensions, which might differ between projects depending on the user or (in the
-case of PyPI) organization which owns the project.  Indexes can refuse to extend sessions, and they can use
-this to limit the availability of packages with unverified contents.
+all artifacts, regardless of the protocol used to upload them.  Because of the multi-step protocol proposed in
+this PEP, indexes could share session links or uploaded staged files to trusted third party security partners
+who could assist in scanning.
+
+Indexes can also mitigate the problem by putting limits on session extensions, which might differ between
+projects depending on the user or (in the case of PyPI) organization which owns the project.  Indexes can
+refuse to extend sessions, and they can use this to limit the availability of packages with unverified
+contents.
 
 Considering the testing and embargoed use cases may lead to different session expiry choices.  Testing a
 release can have a relatively short session lifespan, e.g. on the order of hours.  Embargoed sessions may need
@@ -1489,6 +1496,8 @@ Change History
     project, evaluated contemporaneously on each request.  Adds an **Authentication and Authorization** model,
     handles permission changes mid-session, supports rotating Trusted Publishing tokens and multiple
     publishers contributing to one session, and notes the related security implications.
+  * Remove the optional ``metadata`` key from the file upload session creation request.  The uploaded file is
+    the authoritative source of metadata, which the index extracts from the file itself.
 
 * `07-Dec-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/35>`__