- From: Adrian Gropper <agropper@healthurl.com>
- Date: Thu, 27 Jun 2019 20:17:44 -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: <CANYRo8iLZC8fLJCtyCKSnzFTb+yxsacwoa3fSoedLU85HKbTGg@mail.gmail.com>
I’m particularly interested in the protocol as it relates to DIF identity hubs. As a use-case, I’m about to get an HIV test from a national lab service to use on a dating site. I submit my sample to the lab tagged with a DID. At some later time, I want a verifiable presentation of my HIV result to be automatically available as prospects presenting their verifiable presentations swipe past my “attributes” on the dating site. In general, let’s assume that I want to use a pairwise pseudonymous DID where I might be asked for an email address as an identifier today and the service (Issuer or Verifier) is willing to let me do that. My user agent in this case could be a browser or a Holder. At some later time, another service seeks to ask for authorization for something. I then want my semi-autonomous Holder to present to that service a verifiable presentation in order to preserve the anti-correlation benefits. The DID must resolve to an endpoint that does that even though the user agent is not a browser but rather a delegated automaton of mine with the power to create verifiable presentations if it understands the request. It is this automaton that I want to understand, from a protocol perspective, in DIF and/or Intel SGX. Adrian On Thu, Jun 27, 2019 at 11:36 AM Dave Longley <dlongley@digitalbazaar.com> wrote: > On 6/27/19 11:20 AM, Adrian Gropper wrote: > > 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? > > One option is to use the Credential Handler API, which does not require > any specific endpoints, but instead allows VPs and VCs to flow between > Web sites (with user consent) via the browser as a mediator: > > https://github.com/w3c-ccg/credential-handler-api > > > > > Adrian > > > > On Thu, Jun 27, 2019 at 10:58 AM Dave Longley > > <dlongley@digitalbazaar.com <mailto: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 > > <mailto:luca.boldrin@infocert.it>> > > > *Sent:* woensdag 26 juni 2019 19:17 > > > *To:* Stephen Curran <swcurran@cloudcompass.ca > > <mailto:swcurran@cloudcompass.ca>>; sethi shivam > > > <sethishivam27@gmail.com <mailto:sethishivam27@gmail.com>> > > > *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org > > <mailto:public-credentials@w3.org>>; Luca > > > Boldrin <luca.boldrin@infocert.it <mailto: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> > > > <mailto:swcurran@cloudcompass.ca <mailto:swcurran@cloudcompass.ca > >>> > > > *Inviato:* mercoledì 26 giugno 2019 17:17 > > > *A:* sethi shivam <sethishivam27@gmail.com > > <mailto:sethishivam27@gmail.com> <mailto:sethishivam27@gmail.com > > <mailto:sethishivam27@gmail.com>>> > > > *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org > > <mailto:public-credentials@w3.org> > > > <mailto: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> > > > <mailto: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> > > <mailto: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> > > > <mailto:swcurran@cloudcompass.ca > > <mailto:swcurran@cloudcompass.ca>>> > > > *Sent:* dinsdag 25 juni 2019 17:32 > > > *To:* sethi shivam <sethishivam27@gmail.com > > <mailto:sethishivam27@gmail.com> > > > <mailto:sethishivam27@gmail.com > > <mailto:sethishivam27@gmail.com>>> > > > *Cc:* W3C Credentials CG (Public List) > > > <public-credentials@w3.org > > <mailto:public-credentials@w3.org> <mailto: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> > > <mailto:sethishivam27@gmail.com <mailto:sethishivam27@gmail.com>>> > > wrote: > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: *sethi shivam* <sethishivam27@gmail.com > > <mailto:sethishivam27@gmail.com> > > > <mailto: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> > > > <mailto: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> <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 > > <http://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/ > > > -- > 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 Friday, 28 June 2019 00:18:21 UTC