Open bretg opened 2 months ago
@jaredmoscow -- what forum should questions like this be surfaced?
Hi @bretg,
A couple of comments:
identifierType
for an EID, and should it be the eids.source
(typically a domain name) or something else? Or is there an expectation that publishers need only define and support deletion of their first-party IDs?Adding to what Jared posted above:
- Each deletion request needs to be an atomic unit with a single identifier in the body.
We originally included support for multiple identifiers in the early versions of the spec, but realized doing so would cause problems in cases where intermediaries needed to communicate subsets of IDs they'd received to different partners. The model depends upon the idJWT being signed by the 1st-party and if it contained multiple IDs, intermediaries would not be able to forward it to a partner with whom it shared only a subset of the IDs due to the risk of participants learning about other IDs a user is known by. Limiting the request transactions to a single ID also simplifies communication of outcomes and issues: if multiple IDs were allowed, responses would have to specify which identifiers were accepted and which failed; with a single identifier successes and failures occur at the transactions level rather than a sub-transaction, identifier level.
- Good question here about the sub claim. In the JWT spec I believe the sub claim is formatted as a string. With the multiple items here, this might just require the current object to be relabeled or have it separated into three claims.
Per this a sub claim is any JSON value: "In a JWT, a claim appears as a name/value pair where the name is always a string and the value can be any JSON value."
- The specification does not define how participants map a shared identifier to other identifiers in their own system. Each pair of participants in a request will communicate a supported ID (based off the dsrdelete.json information) to propagate a request.
Partnering participants could agree to use the Prebid list of EID sources as basis for defining the identifier type. We didn't define a the allowed types because they aren't standardized and are often unique to partnerships.
Thanks @bmayd @jaredmoscow:
sub
field, my apologies I'm still not clear -- which of the following is a correct way of writing the value?
{ "identifierValue": "28f6dc889e...fe167", "identifierType": "email", "identifierFormat": "sha256" }
"{ \"identifierValue\": \"28f6dc889e...fe167\", \"identifierType\": \"email\", \"identifierFormat\": \"sha256\" }"
sub
object, there is no specification, only examples. It would be helpful to get more detail in the spec, especially to point out that the values for identifierValue
are defined by the caller. (It would be problematic to allow these to vary by caller-recipient combination.)
Reviewing the doc for Prebid Server implementation, several questions came up.
1) Can deletion requests contain more than one ID at once, or must there be multiple requests? The text seems to indicate there can be more than one, but the actual protocol doesn't define arrays.
Specifically, doc says "1st Party determines what identifiers are subject to the request." but then the
sub
field is defined as a string rather than array of strings.It would be quite nice if multiple IDs could be in the same request rather than having to process many separate requests since they're going to overlap significantly.
2) The
sub
field is listed as being a string, but is shown in the examples as an object.yet
3) How do data deletion requests map to ExtendedIDs? The document example indicates the
sub
field "contains the identifier type". e.g. "email" in the example.Is it intended that the
identifierType
match the value in user.eids.source? e.g. pubcid.org, id5-sync.com, etc. Prebid has a list of many EID sources. Entities will need to know where to look for the identifierValue and there are often many EIDs in a single request.thanks