Discussion: Profile Expansion

[wilwade]

DSNP Activity Content Profiles are fairly sparse. As DSNP grows, different applications will want to add different information to the profile.

1. Should app specific information be added to the DSNP profile?
   • General feeling is that it would be good as it promotes user ownership of that information.
   • If so, how should other apps that might be updating the profile handle that?
   • Could app specific profile information be namespaced and announced separately? (MRC allows for additional schemas to be generated)
     2. How could the profile handle private profile information that is only shared with certain applications?
     3. How could the profile handle private profile information that is only shared with private graph connections?
   • Sub-question: Is it possible to do secondary connections? "Friend of a friend" could see it? This could happen on an application basis, but I'm not sure if is possible from a DSNP layer.

Misc ideas:

• Namespacing profile fields
• Apps registering new profile fields
• Self-describing schemas for extended profiles

[wesbiggs]

The attribute set proposal (#257) gives us one option for answering some of these questions.

• Providers can define (and uniquely namespace) their own schema for user profile data (as Verifiable Credential Schema documents). They can then announce User Attribute Sets that reference the specific data points for a given user in Verifiable Credential format.
• There is no protocol-level restrictions that prevent other apps from announcing their own Attribute Sets with that schema, but because sender and issuer fields are preserved at the announcement level, an application can decide which announcements it cares about, and might have schema-specific semantics to determine whether 3rd-party announcements should be ignored, or aggregated with or even replace their own (e.g. most recent wins).
• You could see this evolving such that the schema was known and shared between multiple providers who agreed on its semantics so data could be shared across applications. If data was private, it could be encrypted with a key shared between the collaborating providers (with attendant group key management concerns, but doable).
• Similarly, attribute set data could be encrypted with a group key covering private connections, or other well defined groups (group and group key management protocol details are TBD, but "friend of a friend" access representation is something we hope to address).