- From: Adrian Gropper <agropper@healthurl.com>
- Date: Thu, 27 Jun 2019 11:20:12 -0400
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: "Joosten, H.J.M. (Rieks)" <rieks.joosten@tno.nl>, Luca Boldrin <luca.boldrin@infocert.it>, Stephen Curran <swcurran@cloudcompass.ca>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, sethi shivam <sethishivam27@gmail.com>
- Message-ID: <CANYRo8h8GnTrP1aixoiXxHGV2-Kg=dBmAPqho6uarHHN+wzp3Q@mail.gmail.com>
In terms of protocol, not data models, what are the endpoints used in the holder-verifier interaction in order to receive the challenge and transmit the VP? Adrian On Thu, Jun 27, 2019 at 10:58 AM Dave Longley <dlongley@digitalbazaar.com> wrote: > > On 6/27/19 10:38 AM, Joosten, H.J.M. (Rieks) wrote: > > That's very nice. It shows that SAML has recognized the need for a > > capability that allows the verifier to test whether or not the subject > > of a claim (note that there is no such thing as THE subject of a VC, > > since a VC can be about multiple/different subjects) and the entity (in > > the role of holder) that presents it to the verifier, are one and the > > same. AFAIK this capability is not supported by the VC standards. Should > it? > > It is supported through the use of a VerifiablePresentation (VP). > > For example, when presenting a VC, the VC is included in the VP and then > the presenter attaches an authentication proof to the VP that includes a > signature over its contents and a challenge string from the verifier. > This proof can be used to non-repudiatively demonstrate control over a > subject identifier referenced in the VC that is bound to the key used to > produce the signature. This binding can be done, for example, via > assertions in a DID Document associated with the subject identifier. > > In short, the VC data model allows for protocols to include this feature > via VPs. > > > > > Rieks > > > > > > > > *From:*Luca Boldrin <luca.boldrin@infocert.it> > > *Sent:* woensdag 26 juni 2019 19:17 > > *To:* Stephen Curran <swcurran@cloudcompass.ca>; sethi shivam > > <sethishivam27@gmail.com> > > *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org>; Luca > > Boldrin <luca.boldrin@infocert.it> > > *Subject:* 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 > > <mailto:swcurran@cloudcompass.ca>> > > *Inviato:* mercoledì 26 giugno 2019 17:17 > > *A:* sethi shivam <sethishivam27@gmail.com <mailto: > sethishivam27@gmail.com>> > > *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org > > <mailto: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 19^th > > <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/ > > > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/
Received on Thursday, 27 June 2019 15:20:49 UTC