profile credentials proposal#169
Conversation
pixelplex
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
meiersi-da
left a comment
meiersi-da
left a comment
There was a problem hiding this comment.
Thanks a lot for the nice work. Neat and tight. 💪
| - MUST treat the value as informational metadata | ||
| - MAY link to a GitHub profile URL | ||
|
|
||
| ## `cip-<nr>/discord` |
There was a problem hiding this comment.
Align with the cip-<nr>/social:discord option proposed by @pdomenighetti in https://github.com/canton-foundation/cips/pull/171/changes#diff-61ffc4e4aebcc43b28d4313bde9119f70c719de2e26bd1357d0d365787f0acabR109
There was a problem hiding this comment.
Hi, @meiersi-da, CPRP (#171) already calls cprp/social:* compatible with this Party Profile CIP, so we’re not pulling in different directions - we just used separate cip-<nr>/discord (etc.) keys while CPRP uses cprp/social:discord (etc.). I’d probably lean toward aligning our social/contact fields with CPRP’s cprp/social: convention so we don’t have two ways to encode the same thing - what do you think? If that sounds good, I’ll update this PR accordingly
There was a problem hiding this comment.
hmm... the convention to use cip-<nr>/ prefixes is proving quite valuable, as it makes it very easy to go from data observed in prod to the explanation of the data. I'd rather have your fields be prefixed by the cip-<nr> of your CIP.
| - a specific issuer party ID | ||
| - `self` (meaning issuer = holder party) | ||
|
|
||
| ## Resolution Algorithm |
There was a problem hiding this comment.
It seems that this is a specialized variant of the resolution algorithm proposed by @pdomenighetti in #171
Can you connect with him and figure out how to best split work and definitions between the two CIPs?
There was a problem hiding this comment.
Makes sense - we probably shouldn’t repeat the full merge/resolution story here when CPRP (#171) already covers the composition side in depth. I’m going to shorten the Resolution section in this CIP and point readers to #171 for the detailed flow, and keep this PR focused on profile claim keys + how to interpret them in the UI. If that sounds off to you, say the word
There was a problem hiding this comment.
I’d second @meiersi-da request to split out the resolution algorithm to a separate CIP.
|
|
||
| This CIP standardizes a portable representation of **party profile | ||
| metadata** for user‑interface rendering on the Canton Network based on | ||
| the **Canton Network Credentials Standard**. |
There was a problem hiding this comment.
Since the standard is still in draft, I didn’t think an explicit reference was necessary at this stage, but I can add it.
There was a problem hiding this comment.
Thanks @vkokosh I found Simon’s gdoc for this.
|
|
||
| - MUST treat the value as informational metadata | ||
| - MUST NOT treat it as an authoritative identifier | ||
| - SHOULD expect an `https://` URL |
There was a problem hiding this comment.
Should we tighten the language here and require a URL that conforms to a spec?
There was a problem hiding this comment.
As far as I remember, Simon and I discussed this as a separate standard, but I could be wrong. However, I will clarify the wording and add more strict guidelines for verification.
|
|
||
| ## `cip-<nr>/email` | ||
|
|
||
| Informational contact email. |
There was a problem hiding this comment.
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?
| - a specific issuer party ID | ||
| - `self` (meaning issuer = holder party) | ||
|
|
||
| ## Resolution Algorithm |
There was a problem hiding this comment.
I’d second @meiersi-da request to split out the resolution algorithm to a separate CIP.
| # Party Profile Resolution | ||
|
|
||
| Applications may obtain profile credentials for a party **P** from | ||
| multiple registries and issuers. |
There was a problem hiding this comment.
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… 😄
| - enables efficient querying | ||
| - allows extensibility | ||
|
|
||
| Future profile attributes can be added under the same namespace. |
There was a problem hiding this comment.
But wouldn’t future attributes have to come from a different CIP?
There was a problem hiding this comment.
As Simon and I discussed, new well-known attributes don’t have to mean a brand-new CIP every time - they can be added via amendments to this CIP. The namespace is mainly to keep clients forward-compatible with unknown keys.
4 participants
No description provided.