Issue credentials to members

If you're a firm, bar association, law school, legal publisher, or any other organization that gives members or contributors something they would list on a CV, you can publish that attestation as an OLPN credential. Once you do, those members can claim the credential in their own entity documents and resolvers will independently verify it.

What you need

1. An OLPN entity at your organization's domain. See Publish an entity at your domain.
2. An olpn-property.json at your domain, with your organization's entity in ownership[].
3. A URL convention for each member. Typically a short, stable handle (j.doe, jane, a member number).
4. Ability to serve a file at /{handle}/olpn-credential.json.

Credential document shape

One file per credential, at https://{your-domain}/{handle}/olpn-credential.json:

{
  "olpn_entity_id": "§:entity:janedoe.law",
  "olpn_credential": {
    "id": "@[email protected]/attorneys",
    "title": "Attorney",
    "type": "Employment",
    "description": "Associate attorney, employment law.",
    "property": {
      "id": "§:property:firm.com",
      "name": "Example Firm LLP",
      "url": "https://firm.com",
      "type": "Law Firm Website",
      "ownership": [
        { "network_id": "§:entity:firm.com" }
      ]
    },
    "dataset": {
      "id": "§:dataset:firm.com/attorneys",
      "name": "Attorneys"
    },
    "profile_url": "https://firm.com/attorneys/jane-doe"
  }
}

The two critical fields are:

• olpn_entity_id — the network ID of the credential subject. This is the back-link.
• olpn_credential.id — the credential ID. Must match the URL path.

Datasets for your issuer

If you issue more than one kind of credential (attorneys, of counsel, alumni, emeritus), group them into datasets. Pick stable, slug-safe paths:

• §:dataset:firm.com/attorneys
• §:dataset:firm.com/of-counsel
• §:dataset:firm.com/alumni
• §:dataset:firm.com/staff

Reflect the dataset in the credential ID path: @[email protected]/attorneys, @[email protected]/alumni. Consumers can then tell at a glance which kind of credential they're looking at.

Publishing options

Static files

For small issuers (a firm with a dozen attorneys), static files in your repo are fine. Write them by hand, commit, deploy. Member onboarding becomes "add a file".

Generated from a members table

For larger issuers (bar associations, law schools), generate credential documents from your canonical member database. A nightly job that reads the members table and writes one JSON file per member works well. This keeps the data current without requiring a live endpoint.

Live endpoint

For issuers that care about real-time accuracy (a bar that needs "active member" to flip immediately on bar-status change), serve credentials from a dynamic endpoint. Pattern:

// Express
app.get('/:handle/olpn-credential.json', async (req, res) => {
  const member = await db.findMember(req.params.handle);
  if (!member || !member.active) return res.status(404).end();

  res.type('application/json').json({
    olpn_entity_id: member.network_id,
    olpn_credential: {
      id: `@${member.handle}@bar.example.com/active`,
      title: 'Active Member',
      type: 'Member',
      description: 'Active member in good standing.',
      property: BAR_PROPERTY,
      dataset: { id: '§:dataset:bar.example.com/active', name: 'Active Members' },
      profile_url: `https://bar.example.com/members/${member.handle}`,
    },
  });
});

Revocation

To revoke: remove the credential document (or serve a 404). The next time a resolver fetches, verification stops. Downstream consumers see the credential disappear.

For issuers that want to keep a history, redirect the credential URL to an archive endpoint that explicitly returns 410 Gone or 404. Do not serve a credential document with olpn_entity_id set to a sentinel value (like "revoked"); that will just produce a verification error, not a clean "no longer issued" signal.

Best practices

• Use stable handles. Once a credential has been issued at @[email protected], don't change jane. If you renumber, you invalidate every back-link that pointed at the old ID.
• Keep datasets narrow. Two or three datasets per issuer is typical. Consumers don't need a complex taxonomy; they need to know if the credential is an employment attestation or an educational one.
• Document your dataset semantics. Publish a short page on your site explaining what each dataset means. The protocol doesn't carry that; it's editorial.
• Update promptly. If an attorney leaves the firm, remove the credential the same day. Back-links that outlive the employment relationship damage the signal.