It would be great to come up with an improved syntax and keep it consistent across DOIP libraries (JS in 0.x, RS in the works)

As an example, here's the current syntax for JS to verify an identity claim:

// Generate the claim
const claim = new doip.Claim("dns:doip.rocks", "3637202523e7c1309ab79e99ef2dc5827b445f4b")

// Match it to candidate service providers
claim.match()

// Verify the claim
await claim.verify()

// Log the claims of the first UID
console.log(claim)

How to fetch a key and verify its identity claims:

// Fetch the key using HKP
const key = await doip.keys.fetchHKP("test@doip.rocks")

// Process it to extract the UIDs and their claims
const obj = await doip.keys.process(key)

// Process every claim for every user
obj.users.forEach(async user => {
    user.claims.forEach(async claim => {
        // Match the claim
        await claim.match()

        // Verify the claim
        await claim.verify()
        console.log(claim)
    })
})

Overall, I don't think it's too bad but I do believe it could be more intuitive.

So, what does the library need to do:

  1. resolve an identifier and fetch a key (or a signature)
  2. if a signature, fetch the key that goes with it(optional)
  3. extract the identity claims
  4. match each claim to one or more services
  5. verify each claim

Things the library needs to be able to do:

  • do steps sequentially and with intermediary results/output (handy to make UIs that can show intermediate states, nice since claims can take seconds to verify)
  • handle ambiguous claims (sometimes, claims — which are just URIs — could match to different services, usually with selfhosted services
  • handle a variety of profile sources (HKP, WKD, upcoming signature distribution protocol)
  • non-OpenPGP cryptography keys (mostly for signatures)

Things that need to be decided:

  • classes or not
  • scheme of objects