Endpoint to notify the data owner of a new Delegated Data Grant

[srosset81]

Context

The 12/03/2025, we had a meeting with @elf-pavlik where we discussed this:

What do you think of the scenario outlined here ?

• eP: In SAI we assume people have reciprocal Social Agent Registration. I have webhooks for that. We would have dataGrants and delegated Data Grants.
• SR: Is there a need for an acceptation from Alice ?
• eP: Yes. Bob would need to first notify Alice. And there would need to be some kind of acknowledgment. It's important indeed. (VC would be nicer because you don't need this acknowlegment.)
• SR: If the delegation chain is logger, it will require many user-to-user exchanges because Craig does not have a Social Agent Registration with Alice. So the acceptance of the DDG needs to go through Bob.
• eP: Yes.
• eP: With ActivityPub, is there some signature to ensure the user has the right ?
• SR: There is the HTTP signature to ensure Craig is indeed Craig. And then Alice just need to check that the DDG has a correct delegation chain until a Data Grant created by herself.
• eP: Maybe we could consider some kind of endpoint, so that David could communicate directly with Alice. And receive some kind of receipts.
• SR: You already have Access Receipts in SAI ?
• eP: We don't use them anymore. At some point we considered to have some kind of inbox. But then we realized there is no need for such receipts.
• eP: The easiest solution would probably be to use a simple HTTP code on the endpoint. So the user would quickly know if, yes or no, the DDG has been accepted.

So it seems we agreed it would be useful to attach (to the user's AuthorizationAgent) an endpoint to validate a Delegated Data Grant (DDG), and also to add the permissions so that the DDG grantee will indeed have access to the resource.

Proposal

Add a interop:hasDelegatedDataGrantValidationEndpoint predicate to the AuthorizationAgent, pointing to a AA-managed URL.

When creating a interop:DelegatedDataGrant, the logged user's AuthorizationAgent MUST call the data owner's endpoint.

To use this endpoint, the Authorization Agent POST an x-www-form-urlencoded id parameter with the value being the URL of the newly-created DDG.

If the endpoint returns a 200 HTTP code, it means the Delegated Data Grant is valid and that the related permissions have been added.

If the endpoint returns any other HTTP code, the DDG is not valid. It SHOULD be deleted and the grantee should be warned.

To verify if a Delegated Data Grant is valid, the Authorization Agent should take into account the delegation attenuation predicates.

[elf-pavlik]

1. We can include the delegated data grant in the body to avoid dealing with ensuring access to it by the AuthAgent of data owner.
2. Data owner (their auth system) needs to keep a copy of that grant. This needs to be defined, possibly in Social Agent Registration who is delegating.
3. Access Grant grant should be created after Delegated Grant that will be included was successfully verified.
4. HTTP 200 should occur after data owner propagated it into their authorization system, especially the storage. Data grant is always for a specific storage/data registry so this should be straight forward. Together with point 3 it should prevent race conditions when final application makes a request.
5. interop:hasDelegatedDataGrantValidationEndpoint doesn't need DataGrant in the name. We only use DataGrants and in the future if something else is used it could reuse the same endpoint.
6. Revocation and Registration endpoints, or registration POST responds with Location and DELETE is used for revocation. Revocation endpoints seems easier, for example if location gets lost.
7. (TAL) data owner's authorization agent could notify all grantees when their delegated data grans were revoked by the data owner. This would remove reliance of propagating it, especially if there are bad actors in the chain.

[srosset81]

As discussed on Friday with @elf-pavlik:

• It could make sense to have delegated data grants in the owner storage, because for the authorization system, they need to be stored there anyway.
• So instead of having a "validation endpoint", we could provide an issuance endpoint (linked from the AA with the predicate interop:hasDelegationIssuanceEndpoint)
• The user would need to send the whole delegated data grant, without the ID. It would return a Location header.
• The DDG creator could delete them with a DELETE request.
• The authorization agent will be responsible for deleting associated data grants.