Re: Regarding ownership of Verifiable claims.

*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>
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>
> *Sent:* dinsdag 25 juni 2019 17:32
> *To:* sethi shivam <sethishivam27@gmail.com>
> *Cc:* W3C Credentials CG (Public List) <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>
> wrote:
>
>
>
> ---------- Forwarded message ---------
> From: *sethi shivam* <sethishivam27@gmail.com>
> Date: Tue, 25 Jun 2019 at 16:01
> Subject: Regarding ownership of Verifiable claims.
> To: Markus Sabadello <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)
>
> *Schedule a Meeting: https://calendly.com/swcurran
> <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.
>
>