DSA initialization

[bretg]

Publishers are generally responsible for creating the DSA object in the Prebid.js, but in some use cases, they can't, including App and AMP. And some Publishers might find it difficult to update their Prebid.js configuration across a broad network of sites in a short period.

Prebid Server host companies can help resolve this with stored request updates, but making a broad update across potentially thousands of DB entries in a short period might be difficult or undesirable.

So we propose a couple of new DSA account config flags:

privacy.dsa.default: >
    {
                    "required": 1,
                    "pubrender": 1,
                    "datatopub": 1,
                    "transparency": [{
                        "domain": "example.com",
                        "params":[1]
                    }]
   }
privacy.dsa.gdpr_only: true

1. If regs.ext.dsa exists and is not null, use it. We're done.
2. else, if privacy.dsa.default exists and is not null:
   1. If privacy.dsa.gdpr_only is false (defaults to false) copy the default value into regs.ext.dsa. Done.
   2. If privacy.dsa.gdpr_only is true (defaults to false) check the internal_gdpr flag, and if true, copy the default value into regs.ext.dsa. Done.

Note that the internal_gdpr flag is defined in the first flow chart of https://docs.google.com/document/d/1g0zAYc_EfqyilKD8N2qQ47uz0hdahY-t8vfb-vxZL5w/edit#heading=h.yjh8s4sv17vv . In short, it's true (1) when GDPR is enabled for the account and any of these are true:

• regs.ext.gdpr:1
• regs.gdpr:1
• configured to treat existence of TCF consent string as in-scope and consent string is present (PBS-Java only)
• device.geo.country is in EEA list

[SyntaxNode]

Edge Case

To keep this logic simple, an empty dsa object counts as "exists". In the following case privacy.dsa.default would not be used.

"regs": {
  "ext": {
    "dsa": {}
  }
}

[bretg]

does an empty dsa object count as "exists"?

Whatever's easier/more consistent with similar edge cases. I don't have a lot of sympathy for a request that comes in with an empty DSA object.

I think exists is ok, but if you prefer exists and not null, can go with that.

[SyntaxNode]

It's easier to define "exists" as "not null", such that an empty object {} would be considered as "exists". This keeps the origin check simple.

[Net-burst]

Gentlemen, IAB updated the spec and changed the names of 2 fields:

regs.ext.dsa.required --> regs.ext.dsa.dsarequired
regs.ext.dsa.transparency[].params --> regs.ext.dsa.transparency[].dsaparams

[Net-burst]

Support for this was released as part of https://github.com/prebid/prebid-server-java/releases/tag/2.10.0
The only deviation from this spec in PBS-Java is the use of the kebab-case instead of the snake_case: privacy.dsa.gdpr_only -> privacy.dsa.gdpr-only. This was done to be in line with all other account config options in PBS Java.

[bsardo]

I assume copying the default into the bid should happen before validation which means a bid with the defaults could still be discarded if DSA validation fails.

[bretg]

I assume copying the default into the bid should happen before validation which means a bid with the defaults could still be discarded if DSA validation fails.

correct

[bsardo]

@bretg If a host specifies a default DSA object and it is missing one of the integer fields (dsarequired, pubrender, datatopub), should we set these to some default value or should we omit them from the the DSA object injected into the bid requests? This impacts the validation logic that compares what is set in the request with what is set in a bid response (i.e. pubrender vs adrender, dsarequired vs whether the object is present).

If we set them to defaults, the validation logic is ok as is. If we omit, what is the validation behavior? If dsarequired or pubrender are not specified, do we skip any validation rules involving that omitted field? There's also the possibility we could always discard the bid.

This is also relevant to a DSA specified on the incoming request. We previously said we don't care about the contents, we will just pass it through, but given that we have expanded the validation rules beyond just dsarequired, we need to consider either defaults or a change to the validation logic.

[bretg]

should we set these to some default value or should we omit them from the the DSA object

omit. No one really knows how this is going to work in the real world, so no defaults are feasible for now.

If we omit, what is the validation behavior? If dsarequired or pubrender are not specified, do we skip any validation rules involving that omitted field?

Easy - if the field that triggers the validation isn't specified, skip the validation. This is perfectly reasonable and under control of the publisher. Will update the other issue.

[bretg]

FWIW, the initial issue said "If the request didn't contain regs.ext.dsa.dsarequired doesn't exist, then no response validation is done.

Updated #3438