Sharing access between social agents

[lem-onade]

When requesting access between social agents, for instance when I request access to Alice's photos, I would send them an access request, for which I ideally get a grant and receipt back. How can I know where the photos for which I have received access are located? (Is this the data grant's hasDataInstance?)

Sort of related to this: Should it be possible to request access to a specific set of their photos? How can I know which photos I can request access to if I have no access to them?
I know Alice can choose this when granting access, but could it be done with a more specific request?

[woutermont]

Specifically, the important questions here are:

• (how) is the access receipt sent to the requesting social agent? (to their AA? to their inbox?)
• what (if anything) happens upon receiving such a receipt? (is it transformed into a data registration? does it stick around?)
• how does an app with which I can view/handle such data (e.g. a data browser) discover the fact that new data is shared with me?

The answer to the related questions is probably: such a specific request will happen out-of-band (e.g. in conversation with Alice I discover that she has some photo's of last week's party, and I ask her to share them with me), upon which Alice gives the specific access to the WebID I provide.

[tomhgmns]

Isn't this related to the "Social Agent Shares Access" authorisation flow?

A Social Agent using an Application elects to share access to data in their control with another Social Agent that did not request it. Access Needs are provided by Application. Notification that access was shared is provided through an Access Receipt.

Is the panel already working on this type of authorisation flow? Is there a sequence diagram of this flow?

[justinwb]

How can I know where the photos for which I have received access are located?

See Access Receipts - "A Social Agent provides an Access Receipt to another Agent after granting them access to some scope of data in an Access Consent." As mentioned in access receipts, you can always query the authorization agent to determine whether the social agent has a registration for you, and if so, you can lookup what access you have based on the access grant in that registration. See Agent Registration Discovery.

Should it be possible to request access to a specific set of their photos?

See Access Needs. Specifically:

hasDataInstance	Data Instance	Request specific Data Instance of the registered shape tree. Requires advance knowledge of the Data Instance

How can I know which photos I can request access to if I have no access to them?

Per the point above - Requires advance knowledge of the Data Instance. You can't request access to things you don't know about, and you should only know about them if the data owner / controller wants you to.

(how) is the access receipt sent to the requesting social agent? (to their AA? to their inbox?)

There's no restriction to how the receipt is transferred, though in this spec we specify hasAccessInbox as discoverable from the webid of the social agent, and would be the default place to deliver them.

what (if anything) happens upon receiving such a receipt? (is it transformed into a data registration? does it stick around?)

It should be processed by the authorization agent. there's no requirement for it to be retained, though it can be for auditing if desired.

how does an app with which I can view/handle such data (e.g. a data browser) discover the fact that new data is shared with me?

It would need to be given access to that data, so the access grant in it's application registration would be updated.

Is the panel already working on this type of authorisation flow? Is there a sequence diagram of this flow?

I think the current authorization flow detailed in the spec covers this

[elf-pavlik]

what (if anything) happens upon receiving such a receipt? (is it transformed into a data registration? does it stick around?)

If social agent registration doesn't exist, for the social agent who issued the access receipt, AA should prompt the user if they want to create one (I think some aspects of #96 apply here as well). We discussed having a reverse invitation workflow to verify the identity of the social agent who issued the access recipe. This would rely on some existing communication channel between those agents (e-mail, phone nr, etc.)

Once the social agent who received the access receipt agrees to create social agent registration for the agent who issued it. The Authorization Agent would perform Agent Registration Discovery as @justinwb mentioned above. Discovered social registration would be added to the registration created by AA using interop:reciprocalRegistration. From now on any further access receipt for the same agent would not require user interaction. Given a clear use case where the user would want to set some preferences on accepting further access receipts from the same agent we could look into specifying what would be needed.

how does an app with which I can view/handle such data (e.g. a data browser) discover the fact that new data is shared with me?

If the user granted that app data consent with a broad scope like All, AllFromUser, AA should automatically update relevant delegated data grants. I already wrote basic code for that in sai-js, it might need some further optimization though. Sometimes this would also apply to data consent with AllFromRegistry, given access receipt was a result of sharing another data instance from the same data registry.

If data consent had SelectedFromRegistry scope or AllFromRegistry but incoming data was from another registry. User would need to trigger authorization flow again and update their consent to cover new incoming data.

[elf-pavlik]

From now on any further access receipt for the same agent would not require user interaction.

Actually, AA should just subscribe to notifications from the social agent registrations linked with interop:reciprocalRegistration, and no further access receipts are required from that social agent.

Public inboxes need to be spam-protected etc. We discussed a couple of times that they would mostly be used in first-contact scenarios and after that communication would move to a 'dedicated channel'. Subscribing to notification from social agent registration someone created for us pretty much acts as such 'dedicated channel' and doesn't rely on further access receipts being sent to the public (create) access inbox.

[woutermont]

There's no restriction to how the receipt is transferred, though in this spec we specify hasAccessInbox as discoverable from the webid of the social agent, and would be the default place to deliver them.

It should be processed by the authorization agent. there's no requirement for it to be retained, though it can be for auditing if desired.

If the AA should process Access Receipts, should there not be a specified way in which they must be delivered? If we do not specify that, for example, sharing party's AA should send the receipt to the inbox and the receiving party's AA should watch that inbox, how will they work together?

how does an app with which I can view/handle such data (e.g. a data browser) discover the fact that new data is shared with me?

It would need to be given access to that data, so the access grant in it's application registration would be updated.

So, if I understand @elf-pavlik correctly, the AA back-end listens for new receipts (either in inbox or on established channel) and updates existing grants. Makes sense!

Public inboxes need to be spam-protected etc.

Any idea on how this would work (given that new social agents will still need to be able to send you a receipt)?

[elf-pavlik]

Public inboxes need to be spam-protected etc.

Any idea on how this would work (given that new social agents will still need to be able to send you a receipt)?

I'm tempted to bounce that specific spam issue to the main solid specification and see where it lands. We consider only define interop:hasAccessInbox in interop spec. Any other inboxes would be defined in different specs, I would expect that some of them would also be public (create) and spam problems would also apply to them.

If we do not specify that, for example, sharing party's AA should send the receipt to the inbox and the receiving party's AA should watch that inbox, how will they work together?

I think we should review our current text and add any clarifications needed. Details on how AA subscribes to the inbox can be delegated to solid notifications spec. We would just need to specify that it should watch it and what is expected to happen after a new access receipt has been delivered, besides doing Agent Registration Discovery.