I'm not sure if you're looking for ideas on the spec or on the implementation (or both!). Without having thought about it a lot, I have a few ideas about each – but I've never contributed to a spec for this sort of thing before so I'm sure I'm overlooking a lot about how it works.
Spec ideas
I'm not sure what is needed beyond specifying that for every provider, more than one verification method can be specified. Ideally, as much implementation detail as possible should be left up to the implementation, so the spec should only contain what's necessary to (a) ensure proofs are valid and (b) ensure compatibility / idempotence between implementations.
Implementation ideas
Without any consideration to the current implementation, if I was coding this myself from scratch (in JS or TS), my first instinct would be something like this:
- Each
Provider registers one or more Methods (Maybe a reserved word, and at least confusing… think of a better name).
- A
Method has:
- a
match method to test whether it matches the claim URI (or it could be a property which is a regex to check against the claim URI)
- a
verify method which performs the actual verification.
- Most
Methods should be able to inherit from a few basic abstract classes without needing too much in the way of logic of their own.
To perform a verification (pseudocode):
let result = false;
let matchedMethods = methods.filter(method => method.match(claimUri));
if (matchedMethods.length === 1) {
result = matchedMethods[0].verify(claimUri, fingerprint);
// could be true (valid) or false (invalid) but is unambiguous
} else if (matchedMethods.length) {
let verifiedMethods = matchedMethods.filter(method => method.verify(claimUri, fingerprint));
if (verifiedMethods.length === 1) {
result = verifiedMethods[0];
// could be true (valid) or false (invalid) but is unambiguous
} else if (verifiedMethods.length) {
// more than one match was successfully validated
} else {
// more than one method matched the claim URI, but none of them could be validated
}
} else {
// no methods matched the claim URI
}
Of course, that leaves a lot of details out. Rather than a boolean, for example, the output of Method.match() will need to be an object with details about the match. Potentially multiple methods could match for the same provider, so each method will need to have a property which names the provider, and the results will have to be filtered on that too because multiple matches for one provider might not be a problem, whereas multiple matches for different providers is an issue that will need some consideration (but is hopefully unlikely).
I'm sure there's lots of things to think about that I haven't considered 😆
see above!