@timbl wrote:

I suggest you have a link to a list of implementations or a Wiki about them on https://www.w3.org/2017/vc/WG/

Yes, this would be a good improvement to the website.

I guess to https://w3c.github.io/vc-test-suite/implementations/

Unfortunately, that document is quite old at this point and implementations have matured well beyond what was tested during the last iteration of the VCWG. I expect much of that test suite to be replaced with a more advanced test suite in the next iteration of the work (currently under charter review).

Some of us are currently refactoring the way Verifiable Credential testing is done in the W3C Credentials Community Group. Here is a list of implementers that conform to some basic level of the general structure of the new test suite:

https://github.com/w3c-ccg/vc-api-test-suite-implementations/tree/main/implementations

... however, those implementations don't include the stand-alone libraries that are used (like vc-js).

I expect that we might have to hand curate the list for now (which is not ideal), and then drive the list from the registered implementations (above) in time.

This issue is to track the addition of an implementations section to the VCWG home page.

add a sentence or two to PR w3c/vc-data-model#847. (David Chadwick) (see details)

Hello All,
First of all, apologies for putting this question in issues as I can't seem to find a page to ask the question.

My question is:
As a verifiable credential issuer is allowed to register one or more DID's in decentralized (distributed) ledger, how can a verifier be assured that the credential that it is verifying, is actually issued by a legitimate issuer?

Below is an example to clarify the question:

Let's say, a motor driving licence issuing agency (MDLA) registered themselves into a decentralized (distributed) ledger with DID value as "did:example:mdla1". They have also registered the driving licence schema along with that DID which looks like below (over simplified example):

"schema_json":{
  "id":"mdla:drivinglicence:schema:v:1.0",
  "name":"Driving Licence",
  "attrNames":["full_name", "credential_created_date", "start_date", "end_date"],
  ....
}

Now, let's say I want to tamper with the verifiable driving licence credential. And to do that, I do register myself in a decentralized (distributed) ledger with DID as "did:example:mdla2" along with the same credential schema as above (only changed the ID to be my preferred ID). And later populate a fake verifiable driving licence using that.

Now, when I present the credential (that I have created by myself) to a person (say a police officer) to verify, how the verifier will know that the credential is issued by me (thus it is fake) and not issued by the actual authority (MDLA)?

As per my understanding so far, my DID (did:example:mdla2) will have my public key associated with it and I have digitally signed my verifiable driving licence credential using my private key, therefore the signature should be verified without any issue.

Please help me clarify this confusion or point me to some resource where I can get a better understanding.

Again, apologies for putting this question in here.
Thank you.

@timbl wrote:

I suggest you have a link to a list of implementations or a Wiki about them on https://www.w3.org/2017/vc/WG/

Yes, this would be a good improvement to the website.

I guess to https://w3c.github.io/vc-test-suite/implementations/

Unfortunately, that document is quite old at this point and implementations have matured well beyond what was tested during the last iteration of the VCWG. I expect much of that test suite to be replaced with a more advanced test suite in the next iteration of the work (currently under charter review).

Some of us are currently refactoring the way Verifiable Credential testing is done in the W3C Credentials Community Group. Here is a list of implementers that conform to some basic level of the general structure of the new test suite:

https://github.com/w3c-ccg/vc-api-test-suite-implementations/tree/main/implementations

... however, those implementations don't include the stand-alone libraries that are used (like vc-js).

I expect that we might have to hand curate the list for now (which is not ideal), and then drive the list from the registered implementations (above) in time.

This issue is to track the addition of an implementations section to the VCWG home page.

@timbl wrote:

I suggest you have a link to a list of implementations or a Wiki about them on https://www.w3.org/2017/vc/WG/

Yes, this would be a good improvement to the website.

I guess to https://w3c.github.io/vc-test-suite/implementations/

Unfortunately, that document is quite old at this point and implementations have matured well beyond what was tested during the last iteration of the VCWG. I expect much of that test suite to be replaced with a more advanced test suite in the next iteration of the work (currently under charter review).

Some of us are currently refactoring the way Verifiable Credential testing is done in the W3C Credentials Community Group. Here is a list of implementers that conform to some basic level of the general structure of the new test suite:

https://github.com/w3c-ccg/vc-api-test-suite-implementations/tree/main/implementations

... however, those implementations don't include the stand-alone libraries that are used (like vc-js).

I expect that we might have to hand curate the list for now (which is not ideal), and then drive the list from the registered implementations (above) in time.

This issue is to track the addition of an implementations section to the VCWG home page.

I'm not sure the link to WICG is right for us. do we use it? I've never heard of it.

In general, a good charter document will include:

1. A longer term vision statement that guides the project from release to release, version to version ...an arrow pointing to some point on the horizon that specifically guides the current release N, plus release N+1
2. A clear statement (a commitment to the reader of the document) of who the intended/primary readers(s) are for the document. e.g. software architects and developers
3. A set of audience-specific set of goals and objectives that the current release N sets out to address (a further commitment to the reader)

Background

Quoting from http://www.echoes.com/msf/envisioning.html ...

Vision
There are six fundamental concepts and guiding principles that underlie the MSF project vision and scoping approach

1. Peak performance begins with a commitment to vision
2. To produce great results, vision must exist and be communicated
3. A great project vision combines verbal and visual information
4. Vision is bounded by no preconceived limitations
5. The sustaining source of vision is business value
6. Vision guides shorter-range objectives (scope)

Scope
Setting the scope means that the needs of a diverse set of end users must be balanced against each other as well as other priorities set down by management. Several variables may impact the potential success of the project, including costs, resources, schedule functionality, and reliability. The key is finding the right balance between these variables

Is there any canonical or recommended way to generate a deterministic signing algorithm message from VC? For example:

1. Sort the JSON object by the keys in alphabetical order.
2. Convert the sorted JSON object to a canonical string representation.
3. Hash the canonical string representation of the JSON object using a suitable cryptographic hash function, such as SHA-256.
4. Sign the hash using the chosen signing algorithm, such as RSA or ECDSA.

The charter dropped a browser-based APIs for interacting with verifiable claims, but suggests that some future working group might take up the matter. This would be unethical because it would create privacy violations.

Example: At present, wifi captive portals commonly ask for identifying information, but providing truthful answers harms users, at minimum with SPAM emails, but potentially with identity theft, etc.

There are reasonable "pseudononymous identity on the web" schemes, but they require much more delicate approaches to personal information and more delicate applications of cryptography. Two recent examples :

• Bryan Ford's DEDIS group at EPFL has a ring signature based scheme for proof-of-person-hood parties that provide users with pseudonyms that unlinkable across domains, but unique per domain. Ring signatures provide anonymity to group members, but group members cannot be added or revoked, hence the need for periodic parties.

• CloudFlare's new approach to CAPTCHAs for Tor now exploits that CloudFlare is both the issuer and verifier, but earlier incarnations used single-use blind signatures.

We can envision other schemes that provide different properties. If you want to provide the cross origin unlinkability required by cookies, then you cannot use conventional signature schemes because the signatures themselves create a unique identifier.

On https://w3c.github.io/verifiable-credentials/ , if I click "more..." under "Meeting Minutes", the visited page doesn't have any styling.

this link doesn't work:

https://github.com/search?q=topic%3Averifiable+claims+org%3Aw3c&type=Repositories

how to we make a "topic"?

@burnburn @liamquin should we add a link to the CG in the site somewhere?