profile credentials proposal

[pixelplex]

No description provided.

[meiersi-da]

Thanks a lot for the nice work. Neat and tight. 💪

[leonidr-c7]

Feedback

[leonidr-c7]

Similar to the above, and applies to other claims below so I won’t repeat, should we require that these values conform to their specifications?

[leonidr-c7]

Should we make Daml specific claims about an issuer or registrar?

Specifically, I would expect that the issuer gave authorization, is a signatory, on a contract that makes a claim about a user. Furthermore, it would be valuable for there to be more than one issuer; that would allow us to make stronger claims. Ex.

A token where both leonid::1220… and c7trust::1220… are issuers (signatories) on a claim that leo@c7.digital is my email address, that carries more weight then one where it is just leonid:1220… 😄

[meiersi-da]

Very nice work! Wow... I'm sooo looking forward to seeing the first real profile page in CC View!

I think this is already a great basis, and I really like the direction in which this is going. If we manage to find a good answer to the issuer-published profile information and apply the remaining polish then we're done with this.

(And yes: I'll see that I get the CN Credential Standard done as well and kick-off it's implementation.)

[meiersi-da]

Consider adjusting to the standard defined in the repo: https://github.com/canton-foundation/cips/blob/main/cip-XXXX/cip-XXXX.md

[meiersi-da]

Suggested change

	Title: Canton Network Party Profile Credentials
	Title: Canton Network Party Profiles

[meiersi-da]

Suggested change

	**MUST NOT** be interpreted as verified identity attributes or used for
	**SHOULD NOT** be interpreted as verified identity attributes or used for

SHOULD as they may be used for these purposes if extra information about the issuer of the credential is known.

[meiersi-da]

Hmm... I see that you restrict the profile below to self-published credentials. It remember we had some conversation about this; and I might have pushed in this direction. However, I think this might be too limiting in the following sense: we would like to create space for app providers to publish metadata about parties they interact with. We should do so in a form that (a) makes it easy for app providers to start doing so at their own pace and (b) allows apps to converge on common metadata keys.

Given this context, I'd propose that we extend the display rules such that the profile consist of sections, where the first section contains the self-published information under well-known keys, and then there's one section per issuer known to the displaying app (i.e. whitelisted by them), and then there follow sections for data from unknown issuers. For each of the sections, they first show the known claims, and afterwards the unknown claims.

wdyt?

[meiersi-da]

Suggested change

	For social fields, this CIP uses grouped claim keys (for example,
	`cip-<nr>/social:discord`) to align naming conventions with
	[CPRP (CIP PR #171)](https://github.com/canton-foundation/cips/pull/171)-style
	field organization while keeping this CIP namespace prefix.

This was removed from the CPRP PR.

[meiersi-da]

Suggested change

	query additional registries according to an explicit local policy. When
	query additional registries according to an explicit application specific policy. When

[meiersi-da]

Some profile properties like email make sense to be set multiple times or not? One can probably argue both ways. It would though be good to give a clear argument in the rationale section.

Also consider adding subsection titles or section headings that summarize what's being specified. Here for example "Claim deduplication:"

[VladislavKokosh]

For now I’m going with a simple rule in the spec: one value per well-known key inside a single issuer section (dedup / last-write-wins). Multiple values still show up across issuers, because each issuer is its own section. So email from self-published and email from a whitelisted app can both appear; two emails from the same issuer collapse to one.
Сlaims are a map, and a section stays predictable if each key has at most one value. If someone needs a second email under the same issuer, that can be a later key/amendment rather than making every field multi-value now.
I’ll put this in the rationale under Claim deduplication. If you’d rather allow multiple emails from the same issuer, we can change it.

[meiersi-da]

Suggested change

	A self-published credential, for which `issuer = holder`, contains:
	A self-published credential, for which `issuer = holder = <pixelplex-party>`, contains:

Question: what kind of PixelPlex party would have the profile you show here? I'm asking as the profile is kind of very top-level and doesn't leave a lot of space for other parties owned by PixelPlex.

Consider giving an example of a party representing the Console wallet, your explorer, or your public facing treasury (assuming you'd want to have a profile for that). Also consider giving an example for the profile of a Console wallet user.

[pixelplex]

@meiersi-da i was thinking about example with our console wallet for instance, where
issuer = holder = consolewallet.cns (party pixelplex-mainnet-3::12209a8ec282ec94bc941172f3052221413031f27394685693e2d83e4bfab6423ac6)

so the wallet users eventually can own a record something like alice.consolewallet.cns