Allow end users to control visibility of attributes

[coolbung]

It should be possible to allow end users to control the attribute visibility

[rahul101001000]

Currently, the config for an entity only defines visibility at a per-entity, per-attribute level, not at a per user-per attribute-per entity level as @coolbung suggests.

Curious to know if the current architecture of Sunbird-RC can be extended to add this functionality or this there is a fundamental design choice made - would be good to capture the thought process here. @dileepbapat @pramodkvarma

Edit: Changed from Changed from "visibility at a per-entity level" to "visibility at a per-entity, per-attribute level"

[pramodkvarma]

That's not my understanding. See https://github.com/Sunbird-RC/community/blob/main/learn/technical-specification-draft.md#visibility-scope

[rahul101001000]

My understanding is we currently are 'per entity, per attribute', we're not 'per entity, per attribute, per user' - right? If the later, could you please give an example. Thanks!

@pramodkvarma

[pramodkvarma]

What does per user mean? Who is "user" in the case of registry? You mean the "subject" represented in the registry? Or adopter of Sunbird-RC?

[rahul101001000]

Triggered by @coolbung 's question, here are the two use cases I had in mind -

Scenario: Let's say I have my email as an attribute in the unemployed registry. Right now, the engineer configuring/deploying Sunbird-RC will decide whether the attribute is public, private (shareable with consent), or internal.

Use case 1: The engineer configures the email attribute for everyone in the registry to be public. I, as an individual unemployed candidate, would like to make it private. My understanding is that I can't do that today.

Use case 2: The engineer configures the phone attribute for everyone to be private. I, an an individual unemployed candidate, would like to make it public. My understanding is that I can't do that today.

Not critical, but would be good to know whether these use cases are possible today with Sunbird-RC, and if not, what the best way to implement them would be for an engineer adopter of Sunbird-RC.

Thanks!

@pramodkvarma

[coolbung]

Yes this is indeed in the pipeline. Once this is implemented, the adopter may configure attributes as public, private or user defined. Details will be fleshed out once this story gets picked up.

[dileepbapat]

Yes per subject visibility is not implemented yet.

However in usecase 1: If policy of the registry is to declare some attribute as public then it should be same for every subject. It is like contract to be advertised and available if exists. If such exclusions are allowed it may have unexpected semantic misalignment like lookup by email would fail in public context which means that subject doesn't exist in the registry (which is equivalent of de-listing)

in usecase 2 if certain field is marked as private by policy, allowing to make it public is violation of policy. Since most of the registry usecases require uniform enforcement of policy this might end up with unintended data exposure etc.

@coolbung as we discussed, when we allow such feature it should be configurable and should come with enough warning that strict policy enforcement is not possible.

probably selective-public or userdefined as separate visibility type which can allow user to configure so that there will be no conflict with policy. thoughts?

[parthlawate]

Is it possible that in addition to allowing the 'default' privacy configuration to be set on an attribute level; we can also introduce a configuration which specifically lets the engineer configure 'user control' of that attribute. This will ensure Policy can be enforced ?

[pramodkvarma]

Agree with @parthlawate

[pramodkvarma]

OK got it. This is not yet built. But, in pipeline as I understand. @dileepbapat

[pramodkvarma]

@dileepbapat @coolbung have you moved this to issue tracker. We should close this discussion thread.

[parthlawate]

Issue created #89