Re: Identifiers in Verifiable Credentials

@Steve: IMO, using "ZKPs with linked secrets" or not is a matter of market
competition. If your use case does not need or does not benefit from using
it, then you don't have to use it. The VC data model is very flexible. Your
observation is correct, within the SSI community different approaches are
implemented.

Although I would argue that for selective disclosure, it makes sense to use
BBS+ signatures since it is already defined in the W3C LD-Proof Registry (
https://w3c-ccg.github.io/ld-cryptosuite-registry/#bbs-signature-2020). You
don't need linked secrets for this.

On Mon, Jun 7, 2021 at 12:49 PM Steve Capell <steve.capell@gmail.com> wrote:

> I have a lot more studying to do before I can really make informed comment
> on this
>
> But when I read that evernym blog about bbs+ I begin to think that there
> are two different mindsets in this VC world
> - those that assume VCs are about people abd that privacy and things like
> non-correlating signatures are find and tally important.  I understand this
> viewpoint when thinking about VCs for things like health claims
> - those (like me) that are trying to use VCs about things and businesses
> to add integrity to supply chains.  In this case there is sometimes some
> commercial sensitivity but there’s really no private data and the
> stakeholders actually WANT correlatable claims - eg that the trusted trader
> ID in one VC really is the same party as the consignor in another
>
> So I really don’t see the value of the bbs+ ZKP stuff in the blog - at
> least for my use case.  I’m more than happy with the simple Merkel hash
> tree method fir selective redaction used by the Singapore open attestation
> protocol.
>
> Am I missing something ?
>
> Steven Capell
> Mob: 0410 437854
>
> On 7 Jun 2021, at 8:14 pm, Oliver Terbu <oliver.terbu@mesh.xyz> wrote:
>
> 
> @Steve: The VC data model has one section here
> https://www.w3.org/TR/vc-data-model/#zero-knowledge-proofs. The example
> shows `CLSignature2019` which is not a registered LD-Proof Suite. AFAIK, it
> uses the `anoncreds` VC protocol defined in HL Indy. However, people are
> working (and moving) on linked secrets using BBS+ which should be fully
> compliant with the W3C VC data model and LD-Proof spec but I have not seen
> a final spec or implementation yet. Note, BBS+ is already used by a lot of
> people but the linked secret piece is something that will be added atop.
> Brent Zundel wrote a very good article  recently:
> https://www.evernym.com/blog/bbs-verifiable-credentials/ .
>
> On Mon, Jun 7, 2021 at 12:02 PM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Steve
>> On 07/06/2021 10:24, Steve Capell wrote:
>>
>> Sorry - in the middle case I meant to say the “subject is not the
>> presenter” not “the holder is not the presenter “
>>
>> I think the general state will be that there is a linked data graph of
>> verifiable claims.  The verifier follows the thread like pulling on the end
>> of a piece of string and finding forks and joins and little gems as they
>> pull.
>>
>> Maybe there’s even a VC about a whole graph so that verifiers don’t need
>> to pull the string..
>>
>> Steven Capell
>> Mob: 0410 437854
>>
>> On 7 Jun 2021, at 7:15 pm, Steve Capell <steve.capell@gmail.com>
>> <steve.capell@gmail.com> wrote:
>>
>>  What about the case where there is a subject but the VC is also
>> presented by a bearer
>>
>> The bearer is the holder. Always.
>>
>>
>>
>> For example
>>
>> Issuer (border agency) issues a VC about a subject (ACME) that asserts
>> that ACME is an Australian Trusted Trader.
>>
>> I have a similar use case to this.
>>
>>
>>
>> ACME provides that VC
>>
>> It is not ACME that provides it, but an authorised official of ACME that
>> provides it. This official will have his/her own key pair (Unless ACME has
>> its own key pair and the private key is given to authorised officials by
>> some internal company procedure). Which model are you suggesting?
>>
>>
>> (together with several others like an IP rights ownership VC (about a
>> product ) and a certificate of origin VC (about a consignment) with their
>> export document bundle to their customer (importer) who gives some of them
>> to a customs broker who passes them to the importing border authority
>> (customs) who is the verifier of the trusted trader VC and the origin VC
>> (but doesn’t care about the IP rights vc). The IP rights VC is a direct
>> exporter (ACME) holder to verifier (importer) VC.
>>
>> This is pretty much business as usual in international trade - which
>> comprises maybe 10 billion consignments (and hence VC bundles) per year
>>
>> We have a combination of
>> - pure bearer VCs (eg the origin certificate where the subject is a
>> consignment of goods)
>>
>> A bearer VC has no subject ID. So if the subject is the goods then it is
>> not a bearer VC. The VC will be held by someone other than the subject
>> (unless the goods has its own digital twin which can be the holder and the
>> subject).
>>
>>
>> - traditional holder VCs (eg the trusted trader status) - except that the
>> holder is not the presenter so it’s kind of a holder VC used like a bearer
>> VC
>>
>> This is the case where the subject NE holder. In this situation the
>> holder has to prove to the verifier that it is entitled to present the VC
>> on behalf of the subject. There are a multitude of ways of doing this.
>>
>>
>> - pure holder is presenter (the scenario most often discussed in this
>> group but the least common in cross border trade)
>>
>> The holder is ALWAYS the presenter. This is the model. There are only
>> subjects and holders. No other roles
>>
>>
>>
>> Whet is the correct use of subject ID and VC assertion ID in each of
>> these cases?
>>
>> The subject ID always refers to the subject of the VC about which the
>> assertions are made. What do you mean by assertion ID? VC ID?
>>
>> Kind regards
>>
>> David
>>
>>
>>
>> Steven Capell
>> Mob: 0410 437854
>>
>> On 7 Jun 2021, at 6:52 pm, David Chadwick
>> <d.w.chadwick@verifiablecredentials.info>
>> <d.w.chadwick@verifiablecredentials.info> wrote:
>>
>> 
>>
>>
>> On 06/06/2021 22:57, Kerri Lemoie wrote:
>>
>> Hello all,
>>
>> I have a question about identifiers in verifiable credentials. The documentation states:
>>
>> "When expressing statements about a specific thing, such as a person, product, or organization, it is often useful to use some kind of identifier so that others can express statements about the same thing. This specification defines the optional id property for such identifiers. The id property is intended to unambiguously refer to an object, such as a person, product, or organization. Using the id property allows for the expression of statements about specific things in the verifiable credential."
>>
>>
>> In the credentialSubject property it seems clear that the id can represent the subject that the claim is about but I’m not clear on the uses for the optional id in the vc assertion. It would be helpful to learn about some examples or suggested uses.
>>
>> The id is optional for the case where the VC is a bearer VC e.g. a ticket
>> to an event. This means that the properties are not bound to a subject, but
>> can be presented by anyone who possesses the VC.
>>
>> Kind regards
>>
>> David
>>
>>
>> For some context: in VC-EDU, we’re discussing Open Badges as VCs. Open Badges have historically mostly been verified via issuer hosted URLs.  One of the reasons to move away from hosted URLs is to remove the dependence on the issuer for verification. However, there may continue to be use cases for when an Open Badge should still be verified through its hosted url.
>>
>>
>> Thanks,
>>
>> Kerri
>>
>>
>>
>>