Re: Regarding ownership of Verifiable claims.

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.

Received on Thursday, 27 June 2019 14:57:17 UTC