<burn> scribenick DavidC
<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2019Jan/0036.html
Justin Richer introduced himself. Has worked in IETF and in identity management
Will be joining the W3C very soon
Dan reintroduced himself. Had his own consulting business and saw VCs would give individuals much greater control over their PII. He joined ConsenSys in 2018
Been working in this space since 1999
<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee
<burn> https://github.com/w3c/vc-data-model/issues/394
#394 assigned to Amy
<burn> https://github.com/w3c/vc-data-model/blob/gh-pages/VCDMExplainer.md
manu: said that there are a few PRs to be merged
brent: said he is editor but does not have the power to merge PRs
Tzviya will merge the PRs when asked to
burn: reminded everyone that every feature needs two independent implementations
burn: otherwise it would be marked "at risk"
<burn> https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
burn: reminded everyone to add their names to implementors if they will be doing one
manu: said we have to have three independent implementations
<burn> reminder - we actually only need 2 implementations
<stonematt> manu, I thought 'revocation' is cryptographic, not status. revoking a credential status IS the refreshService if it's business layer attribute.
tzviya: Why did Manu ask for 3 implementations instead of 2?
burn: This is only for marking features at risk. We only require 2 when we are done, but would prefer 3 implementors to say they propose to implement it
<burn> DavidC: we have an impl but using our own syntax. We don't have the funding yet to make it match the standard. This is why we cannot list ourselves as implementers yet. I don't think evidence is essential. IF you trust an issuer then you trust them. You don't need them to tell you what evidence .
<JoeAndrieu> +1 for evidence not being relevant as a property. It can always be included in the claims if desired
ken: has found a way of embedding schema into proof section, so they dont use the schema section
<Zakim> manu, you wanted to note the issue w/ the thought processes.
manu: If the features are not
implemented they wont do into the spec. This is why we need 2
implementations
... the spec will be much weaker if we have to rip out a core of
the spec because no-one has implemented these features
<burn> DavidC: questions to ken. why is he doing it another way, and why isn't it documented?
DavidC: there is a difference between not implementing a feature you think is not needed, and implementing a needed feature (such as schema) in a non-standard way
ken: For ZKP VCs we have a map
function to allow attributes to be corresponded to signature values
in the proof
... we could also put the schema in the schema section as well
brent thought the schema was defined in the type section. S
<Zakim> manu, you wanted to note that we detailed an algorithm for Sovrin Credentials that could use credentialSchema in the map function... as well as in the proof.
manu: Schema does not have to come
from the type. Sovrin can use schema in the proof or in the main
content
... algorithm is simpler if you use schema instead of type
... . To summarise you can still use schema in the proof, but
better for interop to put it in the schema section. Also dont put
it in the type but in the schema section
... we should probably have another offline discussion about the
schema issue
... question to Oliver. How do you do revocation is you dont have
the status property
<oliver> q
manu: . Should we have an implementors call to discuss the non-standard way of implementing certain features
matt: . This call should be advertised on the list so that all implementors can participate
<oliver> +1
<gannan> +1
<Yancy> +1
<ken> +1
<brent> +1
<dmitriz> +1
matt: . Manu please go ahead and schedule this call next week
<burn> https://github.com/w3c/vc-data-model/pulls
<manu> https://github.com/w3c/vc-data-model/pull/384
Ganesh: Lifecycle PR is out of sync so needs more work
manu: most PRs have already been
pulled in
... . We will merge all PRs at the end of this week (with or
without comments)
<manu> https://github.com/w3c/vc-data-model/pull/399
manu: . Service endpoint breaks our normal pattern with URLs. This is because there might be a set of URLs
<manu> "id": "https://example.com/refresh-service/123"
<manu> "type": "ManualRefreshService2018"
manu: says this can be solved by using 'same as"
<manu> "alternateEndpoint": ["https://blue.com/refresh/567", "https://red.com/refresh/567"]
<manu> Here are the current CR Blockers -- https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3ACR-blocker
<TallTed> +1 to those tweaks toward the existing design pattern with indirect links to the endpoints
<manu> https://github.com/w3c/vc-data-model/issues/391
manu: Ping review is out of our
control
... all others under our control except #391
<manu> https://github.com/w3c/vc-data-model/blob/gh-pages/contexts/credentials-v1.jsonld#L4
manu: our security vocabulary is not in the suggested location
<manu> https://w3.org/2018/security#
<manu> https://w3.org/2018/credentials#
manu: We should ask the security WG if we can have a URL for our vocabulary
<burn> DavidC: I answered all the CCG review questions I could, but others still need answers.
<TallTed> belated scribe flag -- DavidC, please note that `@speaker-nick` is not interpreted as desired by the minutes tools... `speaker-nick:` is the line-start to use. kaz will have a lot of cleanup today.
<burn> ... where do you find the schema for multiple revocation services, for example?
<Zakim> manu, you wanted to note registries
manu: CCG contains a list of
registeries. We will need a registry for revocation types so that
people can find out the schemas for different revocation
mechanisms
... we need to decide how to point to CCG registeries
<oliver> q
oliver: Can we have a call next week about the test suite
<burn> https://lists.w3.org/Archives/Public/public-vc-wg/2019Jan/0012.html
manu: . Benjamin have you done a first pass yet on the tests
bigbluehat: Yes
manu: If anyone has any spare time can they please add more tests to the test suite. If just requires some java script to be written
<manu> and huge thank you to bigbluehat for writing those stubs!!!
burn: We still have a few issues to
resolve so we are not quite done yet!
... thanks to everyone and bye till next week