"regime" needs to be an enumerated value with a defined domain

[jernst]

If there is indeed a wave of privacy legislation coming world-wide, as Gartner predicted, the possible values will quickly go into the dozens and maybe hundreds. Multinationals will need to know which law to apply to particular requests, so a defined list of possible values should be created. (Maybe this can wait until 5min before V1.0 is being released; so I think a placeholder is fine for now.)

[rrix]

Have to agree 100% here, we know that there are some big blind spots in how we model this. We're treating it as a placeholder right now since we're leaning on the CCPA's provisions right now.

[rrix]

In conversation with @dazzaji : the list of regimes and their implementation is ultimately something which is derived through regularly (monthly/quarterly) conversations with business + their GRC + legal teams to develop a "centralized" taxonomy which we can bake in to the protocol -- and perhaps other data rights tools.

[dazzaji]

I think the best word for this is "periodic" (rather than regular monthly or quarterly) communications among the participants, the cadence and method for which is really whatever is simplest and agreed among the organizations that are deploying the protocol together in the same trust network. The cadence could just be as one of the agenda items on occasion sync up meetings just "as needed" or once it becomes routine, even asynchronously such as by updating a shared spreadsheet which gets curated and occasionally rolled into protocol updates.

[jernst]

IMHO ultimately it needs to be something like IANA: maintains a list of enumerated values.

[dmarti]

Is it possible for more than one regime to apply to a single request? For example, if a user in California wants to opt out of sale (CCPA/CPRA) and object to processing (GDPR) by a company in Europe?