TypeIndexen and DataRegistrationen

[jeff-zucker]

In thinking about how the profile discovery process can be most compatible with interop proposals, I am wondering about combining approaches.

A typeIndex links a type and data e.g.

[] a s:TypeRegistration; 
    s:forClass bk:Bookmark; 
    s:instanceContainer  [a ldp:Container] .

So suppose we could also say

[] a s:TypeRegistration;
    s:forClass s:SoftwareApplication;
    s:instanceRegistration  [a interop:DataRegistration] .

This allows apps to keep all information about the type and location of the data in a separately controllable resource without divulging that information to all who read the type Index, solving, I believe the interop panel's main objection to the type indexes.

The big advantage of allowing this path to the DataRegistration is that the profile discovery process will be the same except for the final steps.

1. Load the WebID document
2. Load the privateTypeIndex.
3. Look for s:instance* predicates
4. Follow them to a resource, to a Container, or to a DataRegistration with a link to a shape tree.

This would support existing apps, new-style apps, an easy transition from one to the other, and the ability of both styles of apps to find the data they have access to regardless of which style app created it.

[jeff-zucker]

This wouldn't necessarily change anything about the way the AA operates other than having it drop an instanceRegistration link in the typeIndex.

[elf-pavlik]

I don't understand the change in your snippet, it just seems to use a different value for s:forClass and a different predicate.

Load the privateTypeIndex.

How does the user authorize the app to access the private index, also how does the user control what specifically given app can discover there?

This allows apps to keep all information about the type and location of the data in a separately controllable resource without divulging that information to all who read the type Index, solving, I believe the interop panel's main objection to the type indexes.

I don't understand how your example does it. Could you expand it to an example where there are 2 different apps and 4 different types of data? One app should only have access to 2 types of data and doesn't know of the existence of the other 2. The other app the opposite, can access other 2 and doesn't even know that first 2 exist.

Besides that, neither app should know that the user is also using the other app.

[jeff-zucker]

it just seems to use a different value for s:forClass and a different predicate.

The change in class is important because It uses the generic s:SolidSoftware application rather than the specifc bk:Bookmark which means that other apps with access to the Type Index do not know the specific type of data handled by the app. It uses a different predicate because it points to an interop:DataRegistration rather than to a Container or to some other kind of resource.

How does the user authorize the app to access the private index

This proposal does not change anything about authorization - AA would operate as y'all propose with the only change being that it also drops a link to the DataRegistration in the Type Index.

also how does the user control what specifically given app can discover there?

If it's an AA app the only thing they will be able to discover in the Type Index is the fact that it is an app and the location of its DataRegistration. It's name, purpose, data type/location are all still in exactly the same place AA wants them, and they are not exposed to any app that does not have permission on the DataRegistration. So app X will not know the user is also using app Y from the type index.

[jeff-zucker]

One app should only have access to 2 types of data and doesn't know of the exis\ tence of the other 2. The other app the opposite, can access other 2 and doesn'\ t even know that first 2 exist.

Nothing will change here. For apps wanting that level of privacy, nothing about the types of data or their location is kept in the Type Index.

I have the reverse question for you - two apps both store bookmarks, one using an AA in a complex shape tree described in their DataRegistration and the other using the type index pointing to a simple container. A third app, operating on behalf of the owner wants to look at all the owner's bookmarks. How does it do that without being aware of both the Type Index and the DataRegistration? If it is aware of both, why should they not both be accessed from the same place with a similar predicate?

[elf-pavlik]

For apps wanting that level of privacy, nothing about the types of data or their location is kept in the Type Index.

I don't think apps are entitled to make any decisions about the level of privacy. This is up to the user to control access to their data, Authorization Agent acts as the place to go for setting all the access policies.

The change in class is important because It uses the generic s:SolidSoftware application rather than the specifc bk:Bookmark which means that other apps with access to the Type Index do not know the specific type of data handled by the app.

I still fail to understand what purpose such generic type registration would serve. Looking at your snippet

[] a s:TypeRegistration;
    s:forClass s:SoftwareApplication;
    s:instanceRegistration  [a interop:DataRegistration] .

It doesn't seem to say anything else that there is some unknown data registration. Could you elaborate on how this type of registration would be used?

If it's an AA app the only thing they will be able to discover in the Type Index is the fact that it is an app and the location of its DataRegistration.

Apps don't have their DataRegistration, they have dedicated ApplicationRegistration. Data Registrations are coupled to a specific Shape Tree and have no coupling to any specific app. Registered app can find Access Grant in their Agent Registration which through Data Grants allows the app to discover all the data user granted it access to. If you like you can take a look at application module in sai-js to see how the application finds Data Registrations they have access to (or just some selected data instances in them) based on Shape Tree definition used as a common reference.

I have the reverse question for you - two apps both store bookmarks, one using an AA in a complex shape tree described in their DataRegistration and the other using the type index pointing to a simple container. A third app, operating on behalf of the owner wants to look at all the owner's bookmarks. How does it do that without being aware of both the Type Index and the DataRegistration?

I see a problem here that the app seem to have any say in where the user stores their bookmarks. Users should be able to store bookmarks where they choose to. Interop spec specifies a DataRegistration associated with specific Bookmarks Shape Tree. User can have one of those in any instance of solid storage they own. Apps should be able to access and manipulate that data without having any say in where it gets stored.

I would always think user stores the data in ... using some application, today they use app X tomorrow app Y. They share data with other social agents who use apps Z, T and U. Interop spec put apps in the position of such tools which just help the user get the job done the way user wants to get it done. It's not up to app to impose anything on the user.

If it is aware of both, why should they not both be accessed from the same place with a similar predicate?

If the app supports inerop spec it discovers all the data based on Access Grant found in ApplicationRegistration of this app. As I mentioned before I still need to understand what purpose that turtle snippet above is supposed to serve.

[jeff-zucker]

Yes, users decide things, not apps. Where I've said above "an app that wants ..." means "an app operating on behalf of a user who wants ..."

I am confusing the app with the data, so it should be :

[] a s:TypeRegistration;
    s:forClass interop:DataRegistration;
    s:instanceRegistration  [a interop:DataRegistration] .

The purpose of a statement like this is to allow an app that is not aware of the AA to read the Type Index and follow an instance predicate to the DataRegistration. If it has access, it could then learn about the shape tree and the location of data.

If the app supports inerop spec it discovers all the data based on Access Grant found in ApplicationRegistration of this app.

Understood, and nothing about that will change. What you consistently fail to address is what will happen to an app that does not support the interop spec (such as all the apps currently in existence) and what will happen to the data they produce. My proposal would let AA-unaware apps find out about data that they have access to without divulging anything about the data except in the DataRegistration. Without something like this, are you proposing that AA-unaware apps be denied access to all data created with an AA-aware app?

[elf-pavlik]

Without something like this, are you proposing that AA-unaware apps be denied access to all data created with an AA-aware app?

I think any app should have no access to any data unless the user granted that specific app some specific access. How do you imagine users who set access policies using their AA authorizing an AA-unaware app?

To be honest I think following

1. Users should use actively maintained apps, using unmaintained apps will most likely end up in poor experience (sooner or later)
2. Actively maintained app should be able with minimal work add support for interop spec, we minimized burden on applications and most burned was put on AA. I believe SAI: Application Primer showcases well the relatively low burden on app developers.
3. Putting a burden on a user to manage their access policies with AA and some additional means will just lead to them having lower confidence and poorer experience. Thinking about regular users who might have never heard about Unix filesystem and mostly use apps on their mobile devices and tablets.

Do you see a way for a user to use AA-unaware app while still only needing to use AA to set their access policies? I think this would not only require more burden on AA to handle AA-unaware apps but can't be done in a way transparent to the user. Even just due to the fact that an app that hasn't received a grant with the user has to redirect them to AA. Also, those apps wouldn't provide Access Needs to AA so users would need to have some manual way to set policies for them.

I believe experience should be prioritized in the following order

1. regular users
2. power users
3. app developers
4. aa developers

I'm afraid that you propose to move some burden from app developers onto the users. I believe we should avoid that whenever possible, especially since SAI really puts the minimal burden on app developers and we will provide at least one open source AA implementation that solid providers can offer to users with storages, authorization servers and openid providers.

[jeff-zucker]

Even just due to the fact that an app that hasn't received a grant with the user has to redirect them to AA.

What "has to redirect them"? Are you proposing server changes? Are you proposing that there be AA-servers and non-AA-servers?

The interop proposal is

WebID Document (public) -> DataRegistry (private) -> DataRegistration (private)

My proposal is

WebID Document (public) -> Private Type Index (private) -> DataRegistration (private)

What is going to prevent any app that can do one from doing the other?

[jeff-zucker]

What I am proposing is in addition to interop's proposal, I am not suggesting any changes to anything about the AA or DatatRegistry, only an additional link to the DataRegistration.

[TallTed]

Tangential to the focus here on AA...

@elf-pavlik wrote --

1. Users should use actively maintained apps, using unmaintained apps will most likely end up in poor experience (sooner or later)

That's an awfully snarky comment. A user chooses an app because it performs a desired or necessary task. Time passes, and the author of that app ceases to work on it. For whatever reason, no other available app addresses the same need. Through no fault of their own, the user is then stuck using an app without active maintenance.

How do I know this? It's happened to me multiple times over the course of 40 years as a user.

Yes, those unmaintained apps do end up in poor experience, in various ways — but they still perform the function for which they were originally chosen, if their operating environment continues to support their use (e.g., in the near future, a 32-bit app will likely not be useable in any current OS, because they're all moving to 64-bit only, and gradually dropping their support for 32-bit binaries). I maintain a VERY old environment on an SMTP + POP3 + IMAP4 + DNS + mailing-list server that's been running since roughly 1999 (OK, I've rotated the hardware somewhat over that time) because it mostly still serves most of its purpose. Yahoo and other gorilla corps on the Internet have forced changes to how mailing lists are handled, which is killing that aspect of this server. This is a VERY poor experience -- without much of an escape route, only available if I invest many hours and dollars.

[elf-pavlik]

What "has to redirect them"? Are you proposing server changes? Are you proposing that there be AA-servers and non-AA-servers?

The application discovers if it has an application registration with access grant, if it doesn't it needs to redirect the user to AA so that the user can authorize access for that application.

What is going to prevent any app that can do one from doing the other?

Regular apps don't get access to Data Registry, depending on the scope o the Data Grant they can access a specific Data Registration for a specific Shape Tree (AllFromRegistry), or just certain Data Instances in a Data Registration (SelectedFromRegistry or Inherited).

@jeff-zucker would it be possible for you to join the next interop panel meeting? We could try talking it over during the call.

[jeff-zucker]

The application discovers if it has an application registration with access grant, if it doesn't it needs to redirect the user ...

I'll ask again - what is the "it" in "it needs to redirect the user"? And what enforces the "needs to". If there is no server-enforced redirection, an app can do whatever it wants. My point is that given the current way ACLs work, the route profile -> DataRegistry -> DataRegistration is accessible to exactly the same apps which would use the route profile -> TypeIndex -> DataRegistration.

@jeff-zucker would it be possible for you to join the next interop panel meeting? We could try talking it over during the call.

I'll try to make tomorrow's meeting though I am even less coherent than usual at 7am.

[elf-pavlik]

I'll ask again - what is the "it" in "it needs to redirect the user"?

The application

If there is no server-enforced redirection, an app can do whatever it wants.

If the user doesn't authorize the app, the app will not even know where to look for data. Apps follow path

profile -> Authorization Agent -> Application Registration -> Access Grant => Data Grants -> Data Registration | Data Instances

Application has no access to Data Registry. interop:hasRegistrySet in user's profile is only used by the Authorization Agent, regular applications will not be able to access the Registry Set so they will also not know locations of any Data Registries.

[elf-pavlik]

I should have mentioned that Authorization Server (associated with Resource Server / Storage) would be most likely the exclusive party setting ACRs/ACLs based on Data Grants. So if Data Grants don't exist, giving the application access to specific data, this application will also not be whitelisted in any of ACRs/ACLs (since AS would generate them out of Data Grants created by AA).

[jeff-zucker]

Application has no access to Data Registry

How is that enforced? If I give an app that I trust rights to read my entire pod, what is to prevent that app from reading the Data Registry directly rather than asking the AA?

[elf-pavlik]

I have an impression that you bringing up use cases discussed in #237

I see no reason why a user would give such broad access to some app operating on data conforming to couple of specific shape trees. I believe this will be the case for the majority of apps.

[jeff-zucker]

Yes, related to #237. If the conclusion of #237 is that there are some apps that a user can fully trust which are not also AAs, then my questions relate to those apps.

I see no reason why a user would give such broad access to some app

Other than the #237 case, that's true in some future perfect world. Currently, most Solid users have given such access to many apps. There will be a transition period when some apps don't interoperate with the AA. There may be future apps that work the old way no matter how much we promote a new way. For these reasons I want to know if there's a way for fully trusted apps to use the interop-style data shapes independently of how far along the app is in the process of conforming to the AA process for consent.

[jeff-zucker]

This would allow apps to start using interop-style shape trees immediately, perhaps speeding up eventual adoption of interop-proposed processes.

[elf-pavlik]

My proposal is

WebID Document (public) -> Private Type Index (private) -> DataRegistration (private)

I don't see how we could use a Private Type Index in place of a Data Registry.

I want to point out again that for regular apps the path of discovery is:

profile -> Authorization Agent -> Application Registration -> Access Grant => Data Grants -> Data Registration | Data Instances

So they actually don't ever go through Data Registry at all.

[jeff-zucker]

I don't see how we could use a Private Type Index in place of a Data Registry.

I am not at all suggesting instead, I am suggesting "in addition".

So they actually don't ever go through Data Registry at all.

My bad, I misunderstood that path, thanks for the clarification.