R: Regarding ownership of Verifiable claims.

Hi,
The association between the subject of the VC and the entity presenting it to the verifier is a well known concept from SAML, where it is referred to as “SubjectConfirmation” (http://docs.oasis-open.org/wss-m/wss/v1.1.1/cos01/wss-SAMLTokenProfile-v1.1.1-cos01.pdf par 3.5)

“The SubjectConfirmation element provides the means for a relying party to verify the correspondence of the subject of the assertion with the party with whom the relying party is communicating”

SAML provides 3 standard values: holder-of-key, bearer, sender-vouches.
holder-of-key has the same semantics that Stephan describes: the entity needs to prove to the verifier that she knows some key, in order to be able to use the VC.

Best,

--luca


Da: Stephen Curran <swcurran@cloudcompass.ca>
Inviato: mercoledì 26 giugno 2019 17:17
A: sethi shivam <sethishivam27@gmail.com>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
Oggetto: Re: Regarding ownership of Verifiable claims.

I'm not exactly clear on what you are asking - not sure they are best for a public mailing list as they are getting into specific use cases.  Here's a try:

"How does this happen?":  Not sure what you aren't clear on (what is "this").  As Holder I send a public DID (the literal string) over to the Issuer, who puts that string into the data structure (presumably JSON) of the credential and signs the credential before issuing it to the Holder.

"Share my secret": If another person has both your secret (or the public DID you used) and credentials issued with that embedded secret/DID then yes, they can prove the claims in the credentials.  Anytime you distributed your private key, others may be able to use that private key to be you.

"DID not public": For the verifiable credential model to work, the DIDs involved (the Issuers in the ZKP approach, the Issuer and Holder in the non-ZKP approach) must be public for the Prover/Verifier interaction to be able to prove the claims in the credential. Without that, the Verifier must go back to the Issuer for the details - defeating the whole model.  Private DIDs are extremely useful for establishing secure communication channels (over which verifiable credentials can be exchanged), and in the work we are doing (BC Gov, and the Hyperledger Aries project) we are using pairwise (private) DIDs extensively - except for Verifiable Credentials exchange. In the VerfCred case, the DIDs used in issuing/proving the verifiable credentials must by Public.

Hope that helps.

On Wed, Jun 26, 2019 at 4:43 AM sethi shivam <sethishivam27@gmail.com<mailto:sethishivam27@gmail.com>> wrote:
The Issuer embeds the DID in the credential, along with their own DID and signs the credential.

How does this happen?

and If i share my secret with someone else  than will he able to proove the holder of those credentials?
because as Stephen said  "Verifier in sovrin follows blinded secret approach and there is no other attribute available  like DID"

and my third question is :

What if someone is sharing a DID which is not publc .Will this affect the flow ?  If yes than how ?


Regards
Sethi Shivam



On Wed, 26 Jun 2019 at 12:12, Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
Reading the explanation of Stephen, in particular the phrase "The Issuer embeds the DID in the credential", I wondered if I could find the place where this embedding occurs in the current vc-data-model description. Looking at the version of March 19th<https://w3c.github.io/vc-data-model/#identifiers>, there only seems to be room for credentialSubject-ids (as in Example 4<https://w3c.github.io/vc-data-model/#example-4-usage-of-the-id-property>). However, the subject entity that such an id refers to may very well not be the entity to which the VC is issued – this is obvious taking into account that a VC may contain claims for different subjects, or by imagining the situation where my vet issues a VC to me (so I am the holder) that is (exclusively) about my dog (who is then the subject of the claims in the VC).

Should we better distinguish between holder and subject(s) when it comes to VCs?

From: Stephen Curran <swcurran@cloudcompass.ca<mailto:swcurran@cloudcompass.ca>>
Sent: dinsdag 25 juni 2019 17:32
To: sethi shivam <sethishivam27@gmail.com<mailto:sethishivam27@gmail.com>>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Regarding ownership of Verifiable claims.

Both are mechanisms to prove that the entity (the Holder) holding/proving the claims is the entity to whom the credential (containing claims) was given by the Issuer.  Common handling is something like this:

In the case of the DID, the Holder publishes a public DID somewhere, and gives that DID to the Issuer prior to the issuance of the credential. The Issuer has the Holder prove that they control the private key to that DID. The Issuer embeds the DID in the credential, along with their own DID and signs the credential.  When a Verifier is given the credential by the Holder (now acting as a Prover), the verifier can:

- Know that the data in the credential was not altered (checking the signing using the keys in the DIDDoc of the Issuer)
- Extract and resolve the Issuers DID and make sure that the signed data has not been altered.
- Extract and resolve the Holders DID and then have the Holder prove that they control the private key for that DID - proving the credential was issued to them.

In the case of the link secret, the Holder gives the Issuer a "blinded link secret" (see https://en.wikipedia.org/wiki/Commitment_scheme), a piece of signed data that created from a private key (the link secret) that they hold. The Issuer puts that into the credential and issues it to the Holder. When proving the claims from the credential, the Holder (now the Prover) proves in zero knowledge that they have the link secret used to create the linked secret. The proof also has a reference back to the Issuer's DID and the claims are all signed using private keys on the public ledger. The proof, checked by the verifier proves:

- Claims were not altered by checking the signing by checking private keys on the ledger associated with each claim.
- Identify the DID of the Issuer of the claim.
- The Prover has the private key (link secret) used in the blinded link secret.

The difference between the two is that DID of the Holder in the first case is public knowledge and known to all of the Verifiers presented with that credential. With the blinded link secret approach, the Verifiers do not get a common identifier for the Holder and so multiple Verifiers of the claims cannot correlate the common identiifer to a single entity.

The intent of the Holder having one link secret is that they use blinded link secrets based on that link secret in all credentials issued to them, and thus can prove to the Verifier that claims from many credentials where all issued to the one Holder, all in zero knowledge. Colluding Issuers and Verifiers cannot correlate the Holder/Provers identity based on the credential issuances/proofs.

On Tue, Jun 25, 2019 at 8:08 AM sethi shivam <sethishivam27@gmail.com<mailto:sethishivam27@gmail.com>> wrote:

---------- Forwarded message ---------
From: sethi shivam <sethishivam27@gmail.com<mailto:sethishivam27@gmail.com>>
Date: Tue, 25 Jun 2019 at 16:01
Subject: Regarding ownership of Verifiable claims.
To: Markus Sabadello <Markus@danubetech.com<mailto:Markus@danubetech.com>>

HI Team,

Thanks for the meeting last Thursday.  This is Shivam here. It was my first meeting and I find it very interesting. Hope, I won't miss the next meetings and try to learn more and more so that I can also raise myself to the same level and put my views also.

Markus, I have a doubt could you please help me to get more understanding?

My question is

 How does one establish ownership of a claims
as per my knowledge  Claim is tied to a DID but then there is this concept of a blinded secret where the user needs to know a secret to establishing ownership,
 I am confused with both scenarioes
________________________________
Regards
Sethi Shivam


--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org<http://sovrin.org>)

Schedule a Meeting: https://calendly.com/swcurran


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.


--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran