Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Permissions Business Use Cases

David Moore edited this page · 11 revisions
Clone this wiki locally

Overview

The PMP's purpose is to facilitate sharing of content both within public media and with external partners. At the same time, content producers must feel confident that their content is only seen by authorized entities. This protection scheme is called "permissions", and producers have full control over their content.

The PMP permissions design has its origins in the permissions implementation of the NPR Story API. The business and technical problems of such implementation are extremely challenging, therefore we sought to simplify the technical scheme and the user integration. We entertained dozens of permissions scenarios and were able to cluster them into three key content permission use cases that can be applied to individual content pieces. These are:

  • Public - The content is available for everyone.
  • Private - Only the owner may use the content (e.g. to syndicate to a mobile app)
  • Protected - content is visible to some parties, but not to others, depending on whether the accessing user/organization is in one of the two kinds of lists:
    • White List - organizations that can see the content (inclusive list)
    • Black List - organizations that cannot see the content (exclusive list)

Each station, partner, producer, or other entity will have a user ID in the PMP. This user ID will determine content ownership and content syndication rights.

PMP rights management is a role-based security system: the association of users and/or organizations within certain Permission Groups are the basis of PMP content permissions. Content producers create permission groups and then assign organizations to those groups. Content producers modify content permissions by applying or removing "whitelist" and "blacklist" relationships with the permissions groups (and consequently users/organizations in those groups). For example, a station maya apply a whitelist to a story to restrict it to a list of preferred partners.

The PMP will go a step further than the NPR Story API and allow for asset-level permissions for a story. The text, photos, audio, and video contained in a story could all have differing permissions. A real-world scenario could be that a story's text can be seen by anyone, but Associated Press photos, used in the story, may only syndicate to contractual partners.

Whitelists can satisfy many types of long and short-term business relationships. Many producers and stations are in content partnerships. This might be long-term partnerships around a program, a member station ecosystem, a short-term content licensing deal, or a Local Journalism Center (LJC, a regional group of stations working to cover a certain topic.)

Publishers can create their own white lists, or they can used shared white lists. In keeping with the DRY principle, we wouldn't want each of the 300 members of the NPR Member Station system to create their own "NPR Member Station whitelist", nor should each station in a 10 station regional LJC create their own version of the same whitelist for that LJC. The owner entity will create one shared whitelist that any member of the group may use, and anytime members are added or leave the group, the owner will update the list and ensure that everyone always has the most up-to-date version.

Something went wrong with that request. Please try again.