Change Details

### Background Although we have documented stability policies that indicate a variety of use cases, by default, Wikimedia endpoints are public. There are no technical limitations or access control in cases where endpoints are intended for internal usage; similarly, there are not well supported pathways for defining truly private endpoints, such as those that may pass PII or other sensitive information. As a result, many external systems end up utilizing endpoints marked as internal, which causes challenges when internal flexibility is desired or content should be controlled. The scope of this work is to explore what different privacy, stability, and access control models might look like from a module definition perspective. Module definitions specifically control things like how and where a generated API spec is published, as well as expectations for stability and versioning. ### Conditions of acceptance [] Determine which existing extensions may benefit from 'internal' and 'private' module designations **//--> Halley facilitate this//** [] Define the technical boundaries of 'private' and 'internal' modules [] Document assumptions for stability, access, and usage of the different audience types //**--> Halley will help with this **// [] Create at least one proof of concept module that demonstrate 'private' and 'internal' constraints ### Implementation details This work exclusively applies to module creation. We will not yet be surfacing audiences through the route themselves, nor enforcing access control related to audience designation at this time. //**Related documents:**// * [[ https://docs.google.com/document/d/1yarF_xQkFzQJUOvP3rMooFTFL6tKgK3C-Bf8zV00QR4/edit?tab=t.0 | Audience exploration whitepaper (GDoc) ]] * [T409517]

### Background Although we have documented stability policies that indicate a variety of use cases, by default, Wikimedia endpoints are public. There are no technical limitations or access control in cases where endpoints are intended for internal usage; similarly, there are not well supported pathways for defining truly private endpoints, such as those that may pass PII or other sensitive information. As a result, many external systems end up utilizing endpoints marked as internal, which causes challenges when internal flexibility is desired or content should be controlled. The scope of this work is to explore what different privacy, stability, and access control models might look like from a module definition perspective. Module definitions specifically control things like how and where a generated API spec is published, as well as expectations for stability and versioning. ### Conditions of acceptance [] Determine which existing extensions may benefit from 'internal' and 'private' module designations **//--> Halley facilitate this//** [] Define the technical boundaries of 'private' and 'internal' modules [] Document assumptions for stability, access, and usage of the different audience types //**--> Halley will help with this **// [] Create at least one proof of concept module that demonstrate 'private' and 'internal' constraints [] Document how to utilize 'private' and 'internal' designations for API Authors ### Implementation details This work exclusively applies to module creation. We will not yet be surfacing audiences through the route themselves, nor enforcing access control related to audience designation at this time. //**Related documents:**// * [[ https://docs.google.com/document/d/1yarF_xQkFzQJUOvP3rMooFTFL6tKgK3C-Bf8zV00QR4/edit?tab=t.0 | Audience exploration whitepaper (GDoc) ]] * [T409517]

### Background Although we have documented stability policies that indicate a variety of use cases, by default, Wikimedia endpoints are public. There are no technical limitations or access control in cases where endpoints are intended for internal usage; similarly, there are not well supported pathways for defining truly private endpoints, such as those that may pass PII or other sensitive information. As a result, many external systems end up utilizing endpoints marked as internal, which causes challenges when internal flexibility is desired or content should be controlled. The scope of this work is to explore what different privacy, stability, and access control models might look like from a module definition perspective. Module definitions specifically control things like how and where a generated API spec is published, as well as expectations for stability and versioning. ### Conditions of acceptance [] Determine which existing extensions may benefit from 'internal' and 'private' module designations **//--> Halley facilitate this//** [] Define the technical boundaries of 'private' and 'internal' modules [] Document assumptions for stability, access, and usage of the different audience types //**--> Halley will help with this **// [] Create at least one proof of concept module that demonstrate 'private' and 'internal' constraints [] Document how to utilize 'private' and 'internal' designations for API Authors ### Implementation details This work exclusively applies to module creation. We will not yet be surfacing audiences through the route themselves, nor enforcing access control related to audience designation at this time. //**Related documents:**// * [[ https://docs.google.com/document/d/1yarF_xQkFzQJUOvP3rMooFTFL6tKgK3C-Bf8zV00QR4/edit?tab=t.0 | Audience exploration whitepaper (GDoc) ]] * [T409517]