DID:PLC and Phone Verification

[kgzoom]

Will Bluesky issue a Verifiable Credential about a user's level of verification? For example, users might only want to only associate with other users that have verified their Bluesky account with their cell phone number. Is something like that being considered? Is Bluesky going to be issuing any sort of Verifiable Credentials at all?

[snarfed]

This is similar to #1904, and one answer is probably broadly the same: third parties can publish these kinds of attestations in account-level labels a la https://blueskyweb.xyz/blog/4-13-2023-moderation .

[bnewbold]

That is an interesting idea! Beyond phone verification I believe there are other proposed verifications, like affiliation with an institution.

This isn't something we are currently planning. We will probably do "vouching" via atproto labels, as snarfed mentions. We are also likely to do additional website/account cross-verification using things like HTML meta tags (like what Mastodon does) or special strings like keybase did in the past (there are a couple efforts towards standardizing account cross-linking, I don't have links at hand right now).

Doing Verifiable Credentials would be interesting in the long run. I don't think there has been much adoption yet, so will see how that standard and ecosystem evolves. Would potentially need to extend the DID PLC internal chain schema to support Verifiable Credentials. I would say that publicly and immutably tying personally identifiable information (PII) to a DID rubs me a bit the wrong way. There are also lifecycle considerations around things like phone numbers: you may not retain control of a phone number indefinitely (eg, if you cancel or lose your mobile plan). In the analogous case of domain handles, which are included in the DID document, it is necessary to constantly re-validate that the domain handle is valid, instead of trusting a signed attestation from an earlier point in time (which gets stale quickly).