Partial contact information sharing

[elf-pavlik]

In many cases user might only want to share part of the information about some specific contact. We can see it taken into account in the Contact Picker API (demonstrated in this video)

As I understand vCard ontology provides an n-ary mechanism, given Solid resource level access control, we may require that each detail of contact information should be stored in a separate resource.

Taking an example from https://www.w3.org/TR/vcard-rdf/#Examples

    @prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
    @prefix rdfa: <http://www.w3.org/ns/rdfa#> .
    <http://example.com/me/corky> a vcard:Individual;
      vcard:hasEmail <mailto:corky@example.com>;
      vcard:fn "Corky Crystal";
      vcard:hasAddress [ a vcard:Home;
        vcard:country-name "Australia";
        vcard:locality "WonderCity";
        vcard:postal-code "5555";
        vcard:street-address "111 Lake Drive" ];
      vcard:hasTelephone [ a vcard:Home,
        vcard:Voice;
        vcard:hasValue <tel:+61755555555> ];
      vcard:nickname "Corks" .

it could be stored as discrete resources (omitting prefixes for simplicity)

    <http://example.com/me/corky>
      a vcard:Individual;
      vcard:hasEmail <http://example.com/me/corky/home-email>;
      vcard:hasAddress <http://example.com/me/corky/home-address>;
      vcard:hasTelephone <http://example.com/me/corky/home-address>.

    <http://example.com/me/corky/home-email>
      a vcard:Email, vcard:Home;
      vcard:hasValue<mailto:corky@example.com>.

    <http://example.com/me/corky/home-address>
      a card:Address, vcard:Home;
      vcard:country-name "Australia";
      vcard:locality "WonderCity";
      vcard:postal-code "5555";
      vcard:street-address "111 Lake Drive".

    <http://example.com/me/corky/home-email>
      a vcard:Email, vcard:Home, vcard:Voice;
      vcard:hasValue <tel:+61755555555> ].

etc.

[angelo-v]

I like this approach a lot, since it gives more control over which data to share with whom.

Unfortunately this does not work with SolidOS currently. SolidOS stores everything in a single document and also does not fetch the linked documents when reading a contact.

I think it could easily be extended to support splitting up the data into multiple documents, but I wonder if there has been any particular reason not to do it in the first place. Perhaps @timbl can clarify this?

I would like a future client-to-client spec for contacts to support both variants.

[michielbdejong]

Hold on! What about data-at-the-source?
If you copy my home address into your own storage, and I move house, how do you make sure your record doesn't get outdated?

A much nicer pattern is if I give you access to an RDF doc on my storage where you can at any time retrieve my current home address.

So then in your address book you just have a minimal entry for me, with a hyperlink to my WebID profile including all the public and private data I choose to give you access to.

Forget Copied Data, use Linked Data! :)

[csarven]

This is all possible today. All information in one resource or split into separate resources. Copied or linked. There are obvious advantages and disadvantages to either approach.

"Copied Data" (linked data) would enable the sharer (i.e., the copier) to set access controls on resources they control for specific agents, whereas "Linked Data" (only referencing the authoritative resource) would not enable the sharer to do that on someone else's data out of the box. It would require the controller of the authoritative data to extend permissions to a set of agents, who could then further extend permissions on their resources. This has the benefit of allowing the original owner to monitor who can potentially access their data, but it will ultimately not prevent copying, which is a separate problem altogether. The minimal approach of referencing leads to employing Web of Trust mechanisms (and sending access request notifications as needed).

Putting that aside, if there is a requirement for an application to partition the data such that units of information is spread across different resources, then they would also need to have the means to manage access controls. This is all possible but naturally more complicated than a single resource. Both approaches can be taken since the vocabulary at the very least does not impose any such constraint. Applications need to be smart enough to follow their nose either way.

[elf-pavlik]

So then in your address book you just have a minimal entry for me, with a hyperlink to my WebID profile including all the public and private data I choose to give you access to.

While this makes sense for a phone, email, address, and other details, it is a no-go for a nickname/full name and an optional note. I say it from the perspective of showing contact information on a resource-sharing screen. The user who will share the data needs control over the labels they use for their contacts.
Otherwise, if you let others control under what names they appear on your authorization screen, having many contacts one could get tricked or just mistaken, and share the data with a wrong person who has changed their nickname/full name.

We should add it to the upcoming Best Security Practice document.

BTW shouldn't WebID profile spec and Contacts spec be aligned? Those two specs must be designed to work well together to achieve your proposal.

[michielbdejong]

Yes. https://github.com/solid/contacts should build on https://github.com/solid/webid-profile so that if Alice knows Bob, then she has Bob as a contact, but all the details about Bob (except indeed maybe nickname) live at the source, i.e. Bob's pod.

And then https://solid.github.io/data-interoperability-panel/specification/ should allow two flows:

• share something with a stranger by entering their WebID (and then this stranger should become a contact in the process)
• share something with a contact

And then https://github.com/solid-contrib/data-modules/tree/main/contacts and other implementations should follow https://github.com/solid/contacts

And then everything will work! :)

[michielbdejong]

@csarven:

the sharer (i.e., the copier)

I think you're talking about something else. Resharing maybe?