Schema for Blockchain ID User Profiles - v3

#1

I’m posting here to start a discussion about v3 of the schema for Blockchain ID user profiles.

Here is the documentation on GitHub:

Here is a sample profile:

https://github.com/blockstack/blockchain-id-js/blob/master/docs/profile.md

The schema comes from http://schema.org/Person and has a few additional attributes, including the “account”, “key”, “policy”, “id”, and “publicKey” fields.

To make this expanded format self-defining, we’d have to publish an updated schema definition to a different location that superclasses the schema.org Person definition. Then we would add a field to the schema that looks something like this:

@context”: “https://blockstack.org/schemas/Person

Further context:

The profile is loaded by first grabbing the zone file in the DHT, then interpreting the instructions in the zone file for how to find the user’s token file. The token file is then parsed with blockchain-id-js to combine the individual signed statements and render the profile.

Here is a sample zone file:

https://github.com/blockstack/blockchain-id-js/blob/master/docs/zone-file.md

…and here is a sample token file:

https://github.com/blockstack/blockchain-id-js/blob/master/docs/token-file.md

I have a few big questions in my mind about this schema that I’ve been trying to work out. Here are some proposed changes to the existing schema that I’ve been thinking about:

  1. Change “accounts” to “identities”, remove the “keys” attribute and add all keys to the list of “identities”. PGP keys and bitcoin addresses are both identities just like usernames on other sites. They all are related in the way that a user needs to prove that they have access to the other accounts with some identity statement.
  2. Remove the “policy” field and put that in the zone file instead.

Welcoming other suggestions.

1 Like
Programmatic updating of user profile
#2

People will probably want to create Blockchain IDs for non-human entities.

Some already have https://onename.com/team:

Is the .id namespace the place for non-human entities?

Should we come up with conventions for other entities either in the id namespace or others?

I don’t think of my identity in terms of my bitcoin address or PGP, but I know many do :slight_smile: Sounds fine to me!

Is the thinking behind this that it would speed up and remove a point of failure Blockchain ID Auth? No need to retrieve the profile and if profile becomes unavailable (eg. hosted on S3…S3 is down), user can still log in?

Namespace Conventions