You have to consider this from two distinct points of view, which give opposite answers. You'll have to decide which answer works better for your schema/application.
From a purely RA (Relational Algebra) point of view, the two strong FKs (Foreign Keys) form a completely acceptable PK (Primary Key). The PK from this weak entity can certainly propagate to its dependant entities, so the to FKs can be used as the PK in those dependant entities. This is completely logical, and meets all of the requirements for good (normalized) relational design.
From a practical standpoint, it may be better to establish an SK (Surrogate Key). When I have full control of a schema, for every entity MyThings there will be a ThingId which is always a SK. I always declare an NK (Natural Key) using a UNIQUE CONSTRAINT to preserve the RA integrity too, but I use the PK instead of the NK. This has significant practical benefits within the database, but even more benefits within the application structure because an application framework can be built around the ability to quickly and easily manage tables and table operations based on the PK.
Pick the answer that works for your application/purpose.
In theory, theory and practice are identical. In practice, theory and practice are unrelated.