Come up with a common story/scenario

[elf-pavlik]

As discussed today we can use this issue to share stories/scenarios we currently are using in our work and try to come up with a unified one. This should make it easier for us and the audience to understand how our different projects relate and could fit together.

[elf-pavlik]

In https://sai.js.org and SAI Primers I tend to use:

• ACME, Yoyodyne, Encom - organizations
• Alice, Bob, Charlie - people
• Projectron, Performchart - applications

Now there also will be

• Mallory - https://github.com/elf-pavlik/mallory

It is very generic, usually Alice is affiliated with Acme and Bob with Yoyodyne. Roles and relations aren't really defined.
Pretty much sticking to the boring https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters

[uvdsl]

In MANDAT,, we had the following story line:

Organisations / Legal Persons:

• BigBank, a (generic) banking corporation
• SME, a (generic) small-medium enterprise
• TAO, a (generic) tax advisory office

Individuals / Natural Persons:

• Lisa, a clerk working at BigBank
• Tom, an employee of SME
• Max, a tax advisor of TAO

Goal:

• SME applies for a loan/credit with BigBank

Applications:

• Bank App, the loan process management app (used by Lisa to handle loan requests on behalf of BigBank)
• Loan App, the loan request app (used by Tom to request a loan on behalf of SME)
• Data Provision App, a (rather generic) data provision app (used by Max on behalf of TAO to provide certain tax information to SME)

Constraints:

• Organisations as purely legal persons are unable to act; a natural person, an employed individual, is able to act on behalf of the organisation.
• An audit trail should exist within an organisation to track which employee did what when why and -- of course -- to check if they are allowed to execute the action on behalf of an organisation before the action is allowed.
• In the interaction between organisations, it should not be visible which natural person acted, it is sufficient to know which legal person the action was executed for.
• In similar vein, when sharing data with 3rd parties, it should be possible to obscure the original source of the data.

Solution Components:

• We presented the building blocks of our solution in this Journal article: Solid Pods, Rights Delegation Proxy (RDP), Authorization Application (AuthApp), and Data Provision Proxy (DPP).

Response to comments, @elf-pavlik:

In similar vein, when sharing data with 3rd parties, it should be possible to obscure the original source of the data.

Especially how IRIs are handled here, is there some proxy IRI created that doesn't disclose the original IRI? What about orther IRIs in the data, they could indicate the orginal source of the data.

This is handled via the mentioned Data Provision Proxy (DPP).
The DPP offers a way to obscure/hide the URI of the original data (source). We coined the term data facade for this concept: The DPP mints a new URI and (after checking for usage control) internally forwards requests to the data source that is being "facaded" by the DPP. So, basically, a "proxy URI".

[elf-pavlik]

Awesome @uvdsl

Could you please shortly clarify

In similar vein, when sharing data with 3rd parties, it should be possible to obscure the original source of the data.

Especially how IRIs are handled here, is there some proxy IRI created that doesn't disclose the original IRI? What about orther IRIs in the data, they could indicate the orginal source of the data. I don't intend to go deep into that in this issue, you could even edit your comment and I would hide my comment here as resolved.

[elf-pavlik]

We presented the building blocks of our solution in this Journal article: Solid Pods, Rights Delegation Proxy (RDP), Authorization Application (AuthApp), and Data Provision Proxy (DPP).

Among other nice illustrations I see this one there

I will try to start from that and see if this setup provides sufficient background for what I would like to highlight.

@besteves4 @renyuneyun how do you see it as a starting point for a common scenario?

[elf-pavlik]

@uvdsl I would like to incorporate some specific security and privacy threats. Which could be as simple as adding simple mischievous actor (e.g., Mallory) that would be responsible for trying various exploits. Does MANDAT have some existing scenarios that illustrate specific threats?

[uvdsl]

Quick answer: We did not illustrate these threats

[elf-pavlik]

Thanks! I recall that your were mostly meeting requirements from legislations and not directly addressing specific threats on the Wild Wild Web 🤠

[elf-pavlik]

@uvdsl are the icons used in MANDAT diagrams part of some iconset we could reuse whenever we need to extend the scenario?

[uvdsl]

Behold my most useful tool for making shiny slides: https://www.flaticon.com/

I tend to use a particular style from freepik, I cant recall what it is called... I usually look for the Persons, pick the person icon I used, and check the style they used for this, and then continue my search :)

[renyuneyun]

The proposed story/scenario is very interesting and important, and captures different aspects of required actions involved in a single flow of data. I'll try to align psDToU with the scenario, and compose something demonstratable, or at least illustratable, in hopefully a week.

In addition to that, I would like to propose something more, as I feel the current scenario is not sufficient to show an important point of psDToU. I have written this LikeC4 diagram as a very simple example:
(It might be possible to illustrate using the same banking scenario, but I can't think of an intuitive way. Happy to discuss and adapt.)

Assume you are Alice, how do you know if you should authorise HappyShop or FlappyShop, given your own preference (not illustrated yet; can be added to make the diagram more complete)? I would like to check is that something SAI or MANDAT can support / ease the burden of the user, apart from letting the user to manually decide or write a policy from scratch for every app (which is the case for WAC and ACP, and probably also ODRL)?

Note the stage of this: it is before any agreement/contract has reached (see #3).

Apologise for the long delay. I have finally managed to catch up with things...

[elf-pavlik]

First a quick commend on naming. Happy & Floppy , Good & Duck sound/look quite similar, I would recommend that we use names that are very distinct which at least for me lowers cognitive load.

I would also like to understand if payment processor aspect is fundamendal here or just one possible example of user's preference. I haven't put that much thought into vendors using solid but I would imagine that the Resource Owner (controller) and not the app would dictate how payments can be processed. Or the assumption here is that vendor accepts both GoodPay and DuckPay and user's preference should influence which app they will choose? Also is there an aspect here of both apps requesting access to any of user's data, if yes what they need to access and do they provide some purpose.

I'm trying to understand how various app features e.g. specific accessibility support, language support, platform compatibility etc. fit into those preferences. And do you see it as a part of authorization process.

[elf-pavlik]

Re icons

orgs

https://www.flaticon.com/authors/special/lineal-color?author_id=1&type=standard
https://www.flaticon.com/authors/detailed-rounded/lineal-color?author_id=1&type=standard

• BigBank
• SME
• TAO
• ACME

characters

https://www.flaticon.com/packs/avatars-83

• Lisa
• Tom
• Max