Re: Identifiers in Verifiable Credentials

Exactly how does that linked secret ZKP use of the ID work ?

Steven Capell
Mob: 0410 437854

> On 7 Jun 2021, at 7:30 pm, Oliver Terbu <oliver.terbu@mesh.xyz> wrote:
> 
> 
> The id is also optional for linked secret-based VCs. They can prove holder binding by proving control over the linked secret in ZKP.
> 
>> On Mon, Jun 7, 2021 at 10:49 AM David Chadwick <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
>>> 
>>> 

Received on Monday, 7 June 2021 09:40:05 UTC