API to expose to AAs which identity attributes businesses want to accept

[rrix]

One piece of really salient feedback we heard at DEFCON was that businesses don't need or even want to accept all identity attributes. I've been thinking about this for a while and it's time to work through this.

It seems simple off-hand to extend data-rights.json to include a list of claims:

{
  "version": "0.6",
  "actions": ["sale:opt-out", "sale:opt-in", "access", "deletion"],
  "user-attributes": ["name", "email"]  
}

But CCPA for example has different verification requirements for data sale opt-out requests compared to deletion or access. So maybe:

{
    "version": "0.6",
    "actions": {
        "sale:opt-out": ["email", "email_verified"],
        "sale:opt-in": ["email", "email_verified"],
        "access": ["name", "email", "email_verified",
                   "phone_number", "phone_number_verified",
                   "power_of_attorney"],
        "deletion": ["name", "email", "email_verified",
                     "phone_number", "phone_number_verified",
                     "power_of_attorney"]
    }
}

But this is verbose, while exposing yet more nuance

• should the business be able to signal required attributes? ("we accept POA but require verified email") or is this over-optimizing?
• what about custom claims?
• should this new schema have a new field name, if so what?

[rrix]

these claims could further have information attached to them to say "oh this is your loyalty card ID" -- eventually these could become DRP-standard claims when enough businesses point to the same sort of claims, but in the meantime they could contain (localized? ugh) strings for the agent to prompt consumer to add them at request time

[rrix]

should GET .well-known/data-rights.json be expected/asked to respect Accept-Language header to localize these responses?

[rrix]

ugh didn't notice this is duplicate of #43...

I'd shied away from this early on to keep the API-surface simple and to allow for Agents to function without a backend server, but I do see this as a protocol weakness. despite there being legal guardrails around the use of the identity claims submitted for data rights actions, there's no technical guardrails and it would be difficult to detect misuse of these identifiers except in the case of incomplete deletion requests.

in each data rights request, an authorized agent may embed a status_callback_url field which is used to POST the state of a request to an AA's backend, is there a similar equivalent of this for requesting identity tokens?

PIP does a GET call to AA backend asking for "hey the CB wants the end user's email address" and the end user can either pre-approve this sharing action or the CB can be asked to retry in a while after the user has a chance to consent or contest the transfer?

Now the PIP needs API keys valid for each AA or to sign the requests in some AA-verifiable fashion...

and

i don't think it's as simple as listing in the Discovery endpoint "here are the identity claims we want" because it may depend on the user's relationship with the company or any other number of internal situations

i am still not sure how to express this "multivariate" requirement...

[kevinr]

should GET .well-known/data-rights.json be expected/asked to respect Accept-Language header to localize these responses?

No; Accept-Language is semantically about what natural language should be returned in the response, not about what legal jurisdiction the requester is in or asking about, and should return the same thing regardless, just translated.

[rrix]

You're correct. I am asking whether the documents' strings should be linguistically localized, not legally localized :) -> #31

[rrix]

If we include custom claims from businesses, those need to be presented to the user somehow and not all of them will speak english nor will AA's customer support necessarily be able to help users navigate these claims without localized metadata about them

[rrix]

coming back to this after productive discussion with an implementer... wondering if we should have an PIP API in 1.1 or later on that takes in consumer relationships, data rights to exercise, and the CB would return a list of identity attributes they would want to have validated for the request to streamline, or return an error code if they would not support the particular combination (i.e. "we are not allowed to do a delete request on employee data, sorry!")