You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
The text was updated successfully, but these errors were encountered:
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'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?Now the PIP needs API keys valid for each AA or to sign the requests in some AA-verifiable fashion...
The text was updated successfully, but these errors were encountered: