+
+
+
Prebid User Identity
+
Supporting the open web while respecting user privacy.
+
View Docs
+
+
diff --git a/assets/images/sharedid5.png b/assets/images/sharedid5.png
new file mode 100644
index 0000000000..ee38138acb
Binary files /dev/null and b/assets/images/sharedid5.png differ
diff --git a/assets/images/user-identity.png b/assets/images/user-identity.png
new file mode 100644
index 0000000000..d737d17693
Binary files /dev/null and b/assets/images/user-identity.png differ
diff --git a/identity/prebid-identity.md b/identity/prebid-identity.md
new file mode 100644
index 0000000000..d83d63b126
--- /dev/null
+++ b/identity/prebid-identity.md
@@ -0,0 +1,63 @@
+---
+layout: page_v2
+title: Prebid User Identity
+description: What is Prebid User Identity
+sidebarType: 9
+---
+
+# Prebid User Identity Overview
+
+Prebid's aim is to enable the protection of user privacy while still supporting publisher's ability to make revenue,
+keeping the Open Web healthy.
+
+To do this, Prebid offers a number of identity-related products that encourage awareness of privacy regulations such as GDPR, CCPA, and COPPA. The most important projects are:
+
+- [Prebid.js User Identity Module](/dev-docs/modules/userId.html). This module supports more than 20 different flavors of global IDs with different features that publishers can work with.
+- [SharedID](/identity/sharedid.html). This native hosted ID offering from Prebid is simple, free, robust, and privacy-minded.
+- **Coming soon:** [Unified ID 2.0](https://prebid.org/blog/prebid-org-to-serve-as-operator-of-unified-id-2-0/)
+
+## Prebid.js and Identity
+
+Publishers have several ways to include user identity as part of
+the header bidding auction:
+
+1. Install one or more [User ID modules](/dev-docs/modules/userId.html). These modules obtain
+the user's ID from the service and make it available to participating bidders. Publishers
+can define [permissions](/dev-docs/modules/userId.html#permissions) to control which bidders receive which IDs.
+2. Install the [ID Import Module](/dev-docs/modules/idLibrary.html). This module can be
+used to generate a map of identities present on the page.
+3. Pass [First Party Data](/features/firstPartyData.html), such as interests, to bidders for more relevant advertising.
+4. Include [User Syncing](/dev-docs/publisher-api-reference/setConfig.html#setConfig-Configure-User-Syncing) to allow bid adapters to establish IDs. Publishers have control over which bidders may sync, which syncing mechanisms are allowed, and when the syncing occurs. Syncing is subject to privacy controls such as GDPR, CCPA, and COPPA.
+
+## Prebid Server and Identity
+
+Prebid Server has user sync functionality, allowing server-side bidders to establish
+IDs given appropriate permission from the user for setting cookies.
+
+Prebid Server can receive extended ID arrays (eids) from Prebid.js and provide them to
+participating server-side bid adapters. It also supports permissioning to determine
+which eids can be sent to which bidders.
+
+User IDs are not sent to bid adapters in privacy scenarios such as COPPA and
+GDPR requests lacking appropriate consent. For more details see [Prebid Server Privacy](/prebid-server/features/pbs-privacy.html).
+
+## Prebid SDK and Identity
+
+In application environments, performance-based advertisers rely on a device’s IDFA to target,
+frequency cap, and determine attribution, similar to how cookies are used in desktop
+environments. However, IDFAs are persistent to the device. Prebid SDK will read the IDFA from
+the device when available. Additionally, Prebid SDK supports third party identity IDs.
+
+Prebid Server will strip the IDFA and/or third party identity IDs when enforcing regulations such as GDPR and CCPA.
+
+## AMP, Prebid, and Identity
+
+Prebid Server supports a user [cookie-sync](/prebid-server/developers/pbs-cookie-sync.html) functionality, including integration with
+a consent management platform. This allows server-side bidders to establish IDs given
+the appropriate cookie-setting permissions from the user.
+
+## Further Reading
+
+- [PBJS User ID module](/dev-docs/modules/userId.html)
+- [SharedID](/identity/sharedid.html)
+- [Prebid Server Privacy](/prebid-server/features/pbs-privacy.html)
diff --git a/identity/sharedid.md b/identity/sharedid.md
new file mode 100644
index 0000000000..900f27da75
--- /dev/null
+++ b/identity/sharedid.md
@@ -0,0 +1,141 @@
+---
+layout: page_v2
+title: SharedID
+description: What is SharedID
+sidebarType: 9
+---
+
+# Prebid SharedID
+{: .no_toc}
+
+* TOC
+{:toc}
+
+{: .alert.alert-warning :}
+As of Prebid.js 5.0, PubCommon ID is no longer supported -- it's been merged into SharedID. Also, SharedID no longer syncs to sharedid.org like it did in Prebid.js 4.x.
+
+## What is it?
+
+SharedId is a convenient Prebid-owned first party identifier within the [Prebid UserId Module framework](/dev-docs/modules/userId.html).
+
+## How does it work?
+
+The SharedID ID system sets a user id cookie in the publisher’s domain.
+Since the cookie is set in the publisher's first party domain it does not fall in scope of browser restrictions on third party cookies.
+
+### Prebid.js 5.x
+
+The SharedID module reads and/or sets a random ID in
+the cookie name defined by the publisher when initializing
+the module:
+
+```
+pbjs.setConfig({
+ userSync: {
+ userIds: [{
+ name: 'sharedId',
+ storage: {
+ name: '_sharedID', // name of the 1st party cookie
+ type: 'cookie',
+ expires: 30
+ }
+ }]
+ }
+});
+```
+
+The 'source' value transmitted through OpenRTB (user.ext.eids) is pubcid.org. For example:
+```
+user: {
+ ext: {
+ eids: {
+ "source":"pubcid.org",
+ "uids":[
+ {
+ "id":"01EAJWWNEPN3CYMM5N8M5VXY22",
+ "atype":1
+ }
+ ]
+ }
+ }
+}
+```
+
+{: .alert.alert-info :}
+The 'pubcid.org' EID source was adopted by more buyers than 'sharedid.org', so
+when PubCommon was folded into SharedID, we kept the more commonly recognized
+source value.
+
+### Before Prebid.js 5.0
+
+In addition to setting a first party cookie, SharedID in Prebid.js 4.x also sets a third party cookie where possible, syncing the first and third party cookies (subject to browser capability and user opt-out).
+
+SharedID in Prebid.js 4.x was transmitted through the header-bidding ecosystem on user.ext.eids with a different 'source':
+```
+user: {
+ ext: {
+ eids: {
+ "source":"sharedid.org",
+ "uids":[
+ {
+ "id":"01EAJWWNEPN3CYMM5N8M5VXY22",
+ "atype":1,
+ "ext":{
+ "third":"01EAJWWNEPN3CYMM5N8M5VXY22"
+ }
+ }
+ ]
+ }
+ }
+}
+```
+
+### Detailed Walkthrough
+
+This diagram summarizes the workflow for SharedID:
+
+{: .pb-lg-img :}
+
+1. The page loads the Prebid.js package, which includes the SharedId module.
+2. The page enables one or more user ID modules with pbjs.setConfig({usersync}) per the module documentation. The publisher can control which bidders are allowed to receive each type of ID.
+3. If permitted, the SharedID module retrieves and/or sets the designated first party cookie for this user.
+4. When a header bidding auction is run, the ID modules are invoked to add their IDs into the bid requests.
+5. Bid adapters send the additional IDs to the bidding endpoints, along with other privacy information such as GDPR consent, US Privacy consent, and the Global Privacy Control header.
+6. SharedID is used by the bidder for ad targeting, frequency capping, and/or sequential ads.
+7. Bids are sent to the publisher's ad server, where the best ad is chosen for rendering.
+
+{: .alert.alert-info :}
+In Prebid.js 4.x, when SharedID performed third-party syncing there
+was an extra step in the diagram between steps 3 and 4 where the module would connect to a server on sharedid.org. This step was
+removed in Prebid.js 5.0.
+
+### Privacy Discussion
+
+There are several privacy scenarios in which a user ID is not created or read:
+
+1. The User ID module suppresses all cookie reading and setting activity
+when the [GDPR Enforcement Module](/dev-docs/modules/gdprEnforcement.html) is in place and there's no consent for Purpose 1.
+2. The User ID module infrastructure supports a first-party opt-out, by setting the `_pbjs_id_optout` cookie or local storage to any value. No other cookies will be set if this one is set.
+3. The SharedID module will suppress the ID when the COPPA flag is set.
+
+For all other privacy-sensitive scenarios, it is encumbent upon bid adapters and endpoints
+to be aware of and enforce relevant regulations such as CCPA and Global Privacy Control.
+
+## Opt-Out
+
+Prebid recommends that publishers provide their users with information about how IDs are utilized, including targeting, frequency capping, and special ad features like sequential ads.
+
+If the publisher's legal staff has determined that a user opt-out is necessary beyond existing
+mechanisms like GDPR and CCPA, the use of first party cookies requires that opt-out flow be owned
+by the publisher.
+
+Publishers that decide to build a first-party opt-out workflow might follow a process like this:
+- User is presented with an option to turn off ad targeting
+- If the user opts out, the page can do one of two things:
+ - set a _pbjs_id_optout first party cookie
+ - avoid calling pbjs.setConfig to initialize the user ID modules
+
+## Related Topics
+
+- [Prebid Identity Overview](/identity/prebid-identity.html)
+- [Prebid.js User ID modules](/dev-docs/modules/userId.html)
diff --git a/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
index c1c95680b3..ab4b1efccf 100644
--- a/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
@@ -893,6 +893,27 @@ In order to pull AMP parameters out into targeting, Prebid Server places AMP que
}
```
+#### EID Permissions (PBS-Go only)
+
+This feature allows publishers to specify ext.prebid.eidpermissions, defining which extended ID
+in user.ext.eids is allowed to be passed to which bid adapter. For example:
+
+```
+{
+ ext: {
+ prebid: {
+ data: {
+ eidpermissions: [ // prebid server will use this to filter user.ext.eids
+ {"source": "sharedid.org", "bidders": ["*"]}, // * is the default
+ {"source": "neustar.biz", "bidders": ["bidderB"]},
+ {"source": "id5-sync.com", "bidders": ["bidderA","bidderC"]}
+ ]
+ }
+ }
+ }
+}
+```
+
##### MultiBid (PBS-Java only)
Allows a single bidder to bid more than once into an auction and have extra bids passed
@@ -1065,7 +1086,6 @@ This section describes the ways in which Prebid Server **implements** OpenRTB sp
- `request.cur`: If `request.cur` is not specified in the bid request, Prebid Server will consider it as being `USD` whereas OpenRTB spec doesn't mention any default currency for bid request.
```request.cur: ['USD'] // Default value if not set```
-
### OpenRTB Differences
This section describes the ways in which Prebid Server **breaks** the OpenRTB spec.
diff --git a/prebid-server/features/pbs-feature-idx.md b/prebid-server/features/pbs-feature-idx.md
index 04a1fa9ff1..b16f3a55ca 100644
--- a/prebid-server/features/pbs-feature-idx.md
+++ b/prebid-server/features/pbs-feature-idx.md
@@ -62,6 +62,7 @@ title: Prebid Server | Features
| [User ID Sync](/prebid-server/developers/pbs-cookie-sync.html) | Core | Implements the /cookie_sync and /setuid endpoints. Bidders may choose either redirect or iframe method. |
|
|
| User ID Sync | Multi-Method | Bidders can supply both pixel redirects as well as iframe syncs. | |
|
| User ID Sync | Cooperative sync | Does a pixel sync with more than just the bidders on the page. | |
|
+| User ID Permissions | Extended ID Permissions | Allows publishers to determine which bidders are allowed to receive which extended ID. |
| |
| User ID Sync | Account override | Allows accounts to override the cooperative sync feature and bidder limits. | |
|
| User ID | [EID Permissions](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#eid-permissions) | The Publisher can define which bidders receive which extended user IDs. |
|
|
| [Events](https://docs.google.com/document/d/1ry0X4C2EV-R0pMrm1IQk9BstxaT395UCl3KKqTGa5c8/edit#heading=h.7w5yevygp2gz) | Events | Ability to process the /event endpoint, place /event URLs in the OpenRTB response, and place /event URLs in VAST XML. | |
|
