About signed claims


#1

What are the specs for signatures over claims? Are there any restrictions?

Will only the holder (or owner) of the claim be able to sign it? Can other parties put their signatures too? Can multiple parties sign a claim?

Any interesting use case examples for signed claims?


#2

Carlos: your question is not so much one for Sovrin as it is for Sovrin agents, since they are the actors that will be exchanging signed claims. Sovrin is for the identifiers, keys, pointers (service endpoints), and proofs you need for agents to be able to exchange signed claims.

And on that score, the best answer I can give you is to point to the work of the W3C Verifiable Claims Task Force. “Verifiable” means “signed”, so this work is all about the exchange of signed claims.

The VCTF has applied to become a full W3C Working Group, which should happen by the end of the year. But they have been working on verifiable claims for over two years now, so check out their draft specs.


#3

Hi Drummond,

Yes, I’ve been checking the Verifiable Claims specs and that’s from where most of my questions arise.

I don’t see why you make a differentiation here about Sovrin (the ledger I assume) and Sovrin agents for this case. Wouldn’t signed claims be stored on the ledger as well? Or are these meant to be somehow “private”?

In any case, my questions is more related to the functional scope of having claims that can be signed. Can I have claims signed by multiple parties? Or is it only the claim holder (or subject (or creator)) the one who can sign the claim?

Example: A trust anchor is setting up a new identity for a bank customer on the ledger (genesis claim), this trust anchor is the creator of such claim, and the holder in this case is the customer, but such claim might be signed by a bank (or even by multiple banks and/or other relevant authorities) after going through KYC verification process…

In a more general case, I as an identity owner might also store a self-attested claim about a given attribute for myself, and third parties could “sign” such claim as a form of attestation over it… Does that make any sense? Or should attestations correspond to new claims and the signature scheme for claims is designed with a totally different use case in mind?


#4

Carlos, that’s about 5 different questions. To take each one:

  • Yes, there is a big difference between a claim stored on the ledger and claims stored off-ledger. The simple rule is: no private data should be stored on the Sovrin ledger. Any private claim—any claim containing data that the identity owner does not want to be public (even if encrypted) should NOT be stored on the ledger, but be stored privately by a Sovrin app or agent.

  • For a verifiable claim, yes, it can be signed by multiple parties. For example, you could have 5 verifiable claims for your residential address. However typically that’s 5 different verifiable claims, all signed by one party, all containing the same claim data being signed by each of them.

  • The term claim holder usually applies to the identity owner. The party issuing a verifiable claim is called the issuer. The issuer is the one who signs the claim. If the identity owner is also the issuer of a claim, then it’s called a self-issued (or self-asserted) claim, and it’s signed by the identity owner.

  • A trust anchor is responsible for the “genesis claim” for a Sovrin identity (the registration of a new DID), but the term “genesis claim” is just an analogy. It’s not a formal verifiable claim as the W3C Verifiable Claims Task Force defines it. Rather the trust anchor signs the Sovrin transation that registers the DID.

  • Yes, a identity owner could create a self-attested claim and give it to third parties to see if they will sign it. But in that case, those third parties are the actual issuer of the claim—it doesn’t matter that it started with the identity owner asking them to sign it. For example, I could tell a bank that I live at my home address. But only after the bank got enough evidence that it really was my home address would the bank sign a claim to that effect. And in that case, the bank is the issuer.


#5

Thanks, that’s a good answer, Drummond.

I’ll allow myself to follow up with a couple more questions:

  • If an originally self-attested claim is signed by multiple parties, which one is the “issuer”? (might be the last one to sign?)
  • What is the recommended model for the use case depicted before (possible multiple institutions attesting to one or more attributes of a single identity owner)? What would be the pros and cons (and the Sovrin team recommendation) on multiple claims vs multiple signatures over one attribute?

#6

Carlos:

  1. On your first question, whoever signs a verifiable claim is the issuer. I haven’t heard yet of a use case where a verifiable claim is signed by one issuer and then THAT complete package is signed by a second issuer. I’m not saying it wouldn’t happen, just that I haven’t heard of it. But you may want to ask the Verifiable Claims Task Force members directly.

  2. If we are sticking with VCTF architecture, then the answer to your second question is that each claim (or a set of claims) about a Sovrin identity must be signed separately by each issuer. This does means the claim data is duplicated each time it is signed by a new issuer. (In a more advanced addressable graph model such as XDI, one set of claims could be signed by multiple issuers, but the VCTF is not using the XDI graph model yet.)


#7

Thanks, it’s very much clear now.

Now, this brings me to ask the following question:

Can claims be made about other claims? Or does the concept of claim only apply to identities?

It seems to me that multiple attestations of a given claim could be done if signing parties claim on the validity of the claim in question, without necessarily replicating the whole content. Is that possible?


#8

Carlos, you are a man made for graph models :wink:

So here’s my answer: if the underlying graph model supports it, then yes, you can make claims about claims. In RDF this is called reification, and it’s one of the most complex topics in semantic graphs. See this Wikipedia page for a full explanation.

Because reification is so hard in RDF, the W3C Verifiable Claims Task Force (VCTF) specs (which use JSON-LD, which uses the RDF graph model) do not support it. So you can’t make a claim about a claim using the Verifiable Claims model.

In XDI (disclaimer: I’m co-chair of the OASIS XDI Technical Committee), reification is dramatically simpler, and therefore it’s easy to make a claim about a claim. But XDI is still very young, so its not the model the VCTF is likely to use anytime soon.


#9

And I assume that the VCTF is the approach to be taken for the Sovrin development. Therefore, the answer is the “duplication” of claims.

Now, in such case, is there a convenient way to correlate/link/group those claims about the same attribute(s)?


#10

That’s a great question. One way I can think of is to assign the attribute its own unique URI. I would recommend a path under the DID, e.g., something like did:sov:X2v8rvzoCxayhYV5mhESQ1/claim/1.

Using this URI, the identity owner can issue his/her own self-signed claim that points to the different verifiable claims about this attribute. So, for example, if Alice has a home address, and five issuers issue a verifiable claim about Alice’s home address, Alice could issue her own verifiable claim (i.e., self-signed) that points to these other five claims.


#11

Drummond, that makes perfect sense.

Now, can these paths defined in an arbitrary way, let’s say did:sov:X2v8rvzoCxayhYV5mhESQ1/signed_claims/home_address/, for example?


#12

Carlos, yes, section 5.3 of the DID specification specifies that a DID path uses exactly the same ABNF as a URI path, so it can contain anything you can put in a typical Web URL. The path you describe is a perfect example.


#13

Excellent! Thanks again.


#14

I noticed that https://w3c.github.io/webpayments-ig/VCTF/charter/
plans for verifiable claim specifcation in a long time (ending october 2018)
What are the claim format presently implemented in sovrin sw?
Thanks


#15

@luca I haven’t seen anyone from the Architecture team answer this question yet. Right now the claim format on Sovrin is quite simple—I believe it’s just an enumerated list of data types—but one of the architects can verify that. Claim definitions are stored publicly on Sovrin so that any relying party can understand the semantics of a zero-knowledge proof that is made against a particular claim definition.