Thanks Tim for another thoughtful post, where you have distinguished different classes of architecture for trusting (i.e. verifying) digital identities.

Increasingly it seems to me this is all about data supply chains. The common thread in all IDAM architectures (or “trust frameworks”) is the data and metadata required to support authentication decisions.

As you explain, digital identities are composed of precise pieces of data (i.e. claims) which Relying Parties need to know about their counter-parties (aka Subjects) in each transaction. To verify each of these claims requires metadata about the claims data. Different architectures deliver the metadata in different ways, with controls and rules that work to make claims data reliable.

For completeness, I would add to your account that the adequacy of claims, and of the verification of claims, is a decision for the Relying Parties (RPs). No claim is ever truly “unique” but the trick is to make sure each claim is unique enough for the RP’s purpose. An IDAM architecture will embody security controls and rules about how reliable all the relevant claims need to be.

Consider payment cards, especially the newer PIN-less contactless cards. No merchant is ever 100% sure the customer is the true account holder but that’s not the real question. Rather, is the risk of fraud low enough that the bank will honour the transaction?