Makato, Thanks for your interest, you’ve made several good observations. As to your question about Identity vs Claims, the short answer is that knowing everything about a person is not necessary for them to make a verifiable claim. A certificate embodies a claim nicely because it contains the salient details that Issuer X gave Recipient Y the Certificate Z at a certain point in time, and that nothing has since been altered. This is why the entire contents of a certificate are hashed, time stamped, and recorded on the blockchain. This helps to provide permanence for the entire certificate and removes any ongoing dependence on the issuer for it to be reliably verified.
Of course, all of this depends on getting a Recipient’s public key prior to issuance. If an Issuer simply generates public keys for Recipients, without Recipients owning the corresponding private key, then these individuals don’t really own their certificates. They are relying on the Issuer to verify the claim by virtue of hosting the certificate on their domain. In your example, the “To” address isn’t even a recipient ID, but a reference to the contract itself.
Recipient control is the cornerstone of the Blockcerts project, consistent with the principles of Self-Sovereign Identity. This means that Recipients must have control/ownership over their certificates. And true ownership comes from the underlying private keys being managed by the Recipient. This empowers individuals to reveal and conceal their identifying attributes as they see fit, and no one else.
Another motivation behind this approach is connected to Blockcerts serving as an operational standard and resource for others to use across a wide diversity of domains that desire Recipients to hold/own proof of something.
From the Blockcerts FAQ about identity:
The primary reason is that separation of identity is desirable from an architectural layering perspective. For a certification system, it’s reasonable that adopters will want to establish identity in different ways, and we want to give them this flexibility. At the same time, our design doesn’t preclude identity association. Since the Bitcoin addresses can be any address, recipients and issuers can choose ones associated with a curated profile (e.g. Blockstack profiles).
The case of an insurance company is interesting, because proof of insurance (certificate) isn’t something that needs to be “owned” by Recipients. They simply need to use it safely when required, without revealing too much information about themselves. Because proof of insurance is actually owned by the insurance company, and doesn’t need to last a lifetime, using Ethereum potentially makes sense. However, it’s not clear to me why a blockchain is actually required in this scenario?