W3C home > Mailing lists > Public > public-vc-wg@w3.org > April 2019

Minutes for VCWG telecon 9 April 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 16 Apr 2019 22:41:26 +0900
Message-ID: <CAJ8iq9WD7XAd6PxezZ6Mg_54cRoKTS=XUh7GwE7n1-AwZuJuhA@mail.gmail.com>
To: public-vc-wg@w3.org
available at:
  https://www.w3.org/2019/04/09-vcwg-minutes.html

also as text below.

Thanks a lot for taking the minutes, Amy and Yancy!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                Verifiable Claims Working Group Meeting

09 Apr 2019

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0005.html

Attendees

   Present
          Manu_Sporny, Amy_Guy, Andrei_Sambra, Sercan_Kum,
          Justin_Richer, Dave_Longley, Brent_Zundel, Ken_Ebert,
          Adrian_Gropper, David_Chadwick, Oliver_Terbu,
          Matt_Stone, Allen_Brown, Benjamin_Young, Jonathan_Holt,
          Ted_Thibodeau, Yancy_Ribbens

   Regrets
          Kaz, tzviya, chaals

   Chair
          Matt_Stone

   Scribe
          rhiaro, yancy

Contents

     * [3]Topics
         1. [4]PR Review
         2. [5]Open issues
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <manu> scribenick: rhiaro

   <stonematt>
   [8]https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/00
   05.html

      [8] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0005.html

   stonematt: the CG call is generally after this WG call, but
   they cancelled this week. Many of us go to both, and since we
   have more VCWG work to do than we can do in an hour we're
   offering to extend this call another hour for anyone who can
   attend. We'll get as much processeed as possible
   ... Anything you need to do now to make your next hour
   available, do it now

PR Review

   <stonematt> [9]https://github.com/w3c/vc-data-model/pulls

      [9] https://github.com/w3c/vc-data-model/pulls

   manu: I'm going to go down the entire list of PRs starting at
   the oldest

   <manu> [10]https://github.com/w3c/vc-data-model/pull/501

     [10] https://github.com/w3c/vc-data-model/pull/501

   manu: First is 501. This had a number of questions around
   refreshService
   ... david chadwick proposed some changes, ken responded with a
   list of questions and in an attempt to not have a tremendous
   amount of back and forth in the issue I suggested a call to
   discuss this, there are some big disconnects still on this
   feature
   ... once bringing david and ken up to speed we can try to
   figure out what text will resolve ken's concerns

   ken: I submitted last night a new PR to address this issue,
   that's number 458
   ... I think it's a serious issue, the deeper I understand
   refreshService the more critical I think it is we address it. I
   thinkt he way it was written undermines the holder's ability to
   control their data and their interactions, so I put together a
   pr that addresses that

   dlongley: I think as written we would object to ken's pr
   ... so we're going to have to take a closer look at that
   ... is it 540?

   ken: yes

   <stonematt> [11]https://github.com/w3c/vc-data-model/pull/540

     [11] https://github.com/w3c/vc-data-model/pull/540

   dlongley: the changes that are put into here might make it so
   the refreshService is only usable under certain conditions that
   would only apply to certian use cases rather than others. We're
   trying to make sure you could use a refresh service to cover
   all the possible use cases. We will have use cases where there
   are issuers that want to allow verifiers to pull information
   after holders haves hare those credetianls. HOlders should be
   aware those vcs

   work that way but that wouldn't prohibit the vcs form working

   scribe: [scribe got lost]

   ken: that is the exact use case that I think undermines the
   ability for the holder to control their data
   ... if it stays in that way, Sovrin will withdraw support. I
   cannot convince my boss to vote for it

   dlongley: sovrin doesnt' have to support a very specific
   refresh service that allows it to happen
   ... this allows to calll a space where refresh services can
   reside, where you put that information. Sovrin is under no
   burden to support a refresh sservice that covers use cases they
   don't want to cover. All they have to do is support the space,
   so other people can create refreshservices that function the
   way they need

   DavidC: either we're going to discuss it now or we're not..
   manu's original proposal was we discuss it offline which we
   haven't yet. But if we are going to discuss it now I want to
   raise a point

   <Zakim> manu, you wanted to prevent discussion and move on.

   stonematt: I think we should table it and discuss it later or
   in another call so we can continue to process

   <ken> +1

   <dlongley> +1 to no discussion today

   manu: If it gets into discussion we need to stop it, we have a
   lot to get to, 21 issues, if it's not a resolution we move on
   ... Those two PRs are stuck until this gets discussed. ken,
   david, we will have to find another time to have that
   discussion asap

   <SercanK> +1 interested

   <ken> agreed

   manu: that's a big change we're talking about

   <DavidC> +1

   manu: Next PR is 508

   <manu> [12]https://github.com/w3c/vc-data-model/pull/508

     [12] https://github.com/w3c/vc-data-model/pull/508

   manu: brent I just need you to resolve the conflicts
   ... never mind I can do that
   ... That's good to go

   <stonematt> [13]https://github.com/w3c/vc-data-model/pull/514

     [13] https://github.com/w3c/vc-data-model/pull/514

   brent: resolved them yesterday

   manu: 508 is ready to go in
   ... 514, there are a number of updates that grant did to the
   spec

   <oliver> I would like to be part of the discussion if you have
   a dedicated call

   manu: *reads all the editorial pr numbers*
   ... grant did a broad search and replace and changed every
   instance of credential to verifiable credential. They are two
   different concepts. A credential doesn't have any kind of proof
   mechanism associated with it, a VC does. The changes wipe out
   that distinction
   ... There are 63 places where that change was made that needs
   to be reverted. I have marked all of them, grant says he's
   gonna process them. All of those editorial changes to the spec
   are stuck until that happens
   ... Next is pr 531

   <manu> [14]https://github.com/w3c/vc-data-model/pull/531

     [14] https://github.com/w3c/vc-data-model/pull/531

   manu: This PR attempts to clarify that multiple proof mechanims
   are allowed, brent and chaals have approved it, I wrote it.
   We're holding on justin because you wanted to review this pr
   ... once you do a reivew and suggest concrete changes or just
   approval we can pull that pr in
   ... 531 is blocked on justin

   Justin_R: i'll take a look

   <manu> [15]https://github.com/w3c/vc-data-model/pull/532

     [15] https://github.com/w3c/vc-data-model/pull/532

   manu: next one is also justin, 532. Jonnycrunch, Justin and I
   had a discussion last week where justin noted issues and
   concerns with the syntaxes section
   ... we're a little too loose with the language around how
   certain serialisations should or must happen in the spec. I've
   added 4 paragraphs of text to syntax to try to make that
   clarification
   ... justin I need you to review it to make sure I'm addressing
   your concerns appropriaately. dlongley has already suggested
   changes which I haven' tupdated the pr yet
   ... if anybody else has concerns about the language in the
   syntaxes section please review this
   ... the second justin gets his reivews in we're going to pull
   that in unless there are objections

   Justin_R: you had asked me last week to actually address that
   text so I didn't see this change come across and we'll get to
   it but 539 was my take on this

   manu: I hadn't seen that yet

   Justin_R: it can't be merged because of the ipr bot

   manu: we'll ping kaz and the chairs on that
   ... you are a part of the group we just need someone to..

   Justin_R: I'm working on fixing that right now, but if we're
   going to talk about the text in 532 we should talk about the
   text in 539

   manu: we sholud take this offline and put aside time this week
   to do that

   <manu> [16]https://github.com/w3c/vc-data-model/pull/533

     [16] https://github.com/w3c/vc-data-model/pull/533

   manu: Next is 533
   ... an update that brent made to address issue 474
   ... I think it was approved, DavidC is pushing back on it and
   dlongley has responded. We're gonna have to let this one ride
   ... please try and resolve stuff in the issue
   ... DavidC I think this is blocked on you until you say whether
   you agree with the text

   <manu> [17]https://github.com/w3c/vc-data-model/pull/534

     [17] https://github.com/w3c/vc-data-model/pull/534

   manu: 534 is next
   ... this is by brent. DavidC did brent's changes address your
   concerns?

   <manu>
   [18]https://github.com/w3c/vc-data-model/pull/534#discussion_r2
   73367840

     [18] https://github.com/w3c/vc-data-model/pull/534#discussion_r273367840

   DavidC: on the context one?
   ... I haven't seen a response to.. oh I see okay

   manu: changing a MUST to a MAY, brent is asserting it's a
   mistake the group made, I don't think it was
   ... if it was not a mistake it's a normative change
   ... as a heads up to anyone else doing PRs any time you touch a
   SHOULD or a MUST or a RECOMMENDS it's a normative change and
   you need to get the entire group to agree we didn't actually
   mean the MUST
   ... David, brent, myself, dlongley, anyone else you need to get
   together to decide the exact spec text. If there's a way to
   make this change and make it non-normative that would be best.
   if it's normative change we'll have to go through another CR,
   which we're trying to avoid
   ... Need to take this offline

   <brent> +1

   <manu> [19]https://github.com/w3c/vc-data-model/pull/535

     [19] https://github.com/w3c/vc-data-model/pull/535

   manu: Next is 535
   ... brent has written this to address 483 about context and 491
   ... brent what's the status here? I can merge

   brent: I updated it according to your comments
   ... yesterday. But other than you nobody has reviewed it

   DavidC: when you say doesn't require the value to be
   processed.. what does that mean?
   ... Does that mean even read and understood? or does it mean
   referenced and fetched and everything

   manu: it does not mean dereferencend and fetched. It means the
   array is in the order you expect - this is for json processors
   processing @context - you don't need to dereference you don't
   need to do json-ld processing
   ... but you need to do a byte to bye tstring compare to make
   sure the items in the array are in the same order you expect

   DavidC: it says there is no requirement that the value is
   processed

   manu: it says specificially to be processed using JSON-LD
   ... brent has updated the text

   DavidC: right okay

   manu: david and anyone else who wants to do a review please do.
   Right now it has an appropriate number of reviews to pull it in
   (at least 2)
   ... 535 is ready, please reivew if you have something to say

   <manu> [20]https://github.com/w3c/vc-data-model/pull/538

     [20] https://github.com/w3c/vc-data-model/pull/538

   manu: Next 538
   ... brent, update on this one?

   brent: this is in response ot issue 488 which is just attempts
   at adding non-normative clarifying text to the presentation
   section
   ... I've added a couple of paragraphs worth of text
   ... or reordered things
   ... I don't think I"ve changed the meaning of anything, just
   tried to explain more

   ken: does have new normative language in it

   brent: where?

   ken: line 1621 has a must, line 1690 has a may

   manu: it existed in the old language
   ... 1644 and 1643 on the other side

   ken: I just wanted to call it out to make sure

   brent: that's a paragraph I moved so all the normative
   statements are in the same place

   manu: this just needs reviews

   <manu> [21]https://github.com/w3c/vc-data-model/pull/539

     [21] https://github.com/w3c/vc-data-model/pull/539

   manu: The last pr that's pending is justin, 539
   ... we need to review, we'll do that

   <manu> [22]https://github.com/w3c/vc-data-model/pull/540

     [22] https://github.com/w3c/vc-data-model/pull/540

   manu: 540 is one that ken just put in
   ... that we also need to review
   ... DavidC is disagreeing with the proposed update. We will
   continue going through that PR in the thread
   ... Any comments/concerns about the way we're processing these
   or next steps?
   ... Next step is let's try to get a big call with all of us
   there and try to address the PRs that we feel are easiest first
   and then more difficult second
   ... if certain people that need to be there who are contesting
   the PR or pushing the PR aren't there we are just going to have
   to have a separate call. Let's try and put this earlier in the
   week, possibly wed/thu/fri of this week
   ... and push forward resolutions for those

Open issues

   manu: Justin, you were on that call and yo ucould let us know
   whether or not jonnycrunch would disagree with this PR.. I
   think he would agree with it

   Justin_R: I'm not going to pretend to speak for him and I
   believe you should not either

   manu: we can't resolve any of the issues jonnycrunch had a
   concern with if he's not here. We'll have to make sure he's on
   the call when we address stuff
   ... It's really only the @context issue, and that's a
   foundation issue for some of the other sub-issues

   <manu> [23]https://github.com/w3c/vc-data-model/issues/491

     [23] https://github.com/w3c/vc-data-model/issues/491

   manu: First is 491
   ... raised by tony nadalin, says no need to process the context
   unless dealing with jsonld and processing should be made
   optional. The assertion is that it was always optional for non
   jsonld processors modululo that one thing where you have to
   make sure the order is appropriate. The suggestion is to add
   non normative text making that more clear. brent already has a
   PR in for that. Part of that's there. THere's another set of
   text we shoul add in

   5.3.1 outlininig you shouldn't have to do full blown
   compaction/expansion kind of stuff to be compatible

   scribe: the suggestion is to add non-normative text to the spec
   that clarifies this

   Justin_R: I think the core of this is one that you and I have
   spoken about in the past manu and that's this notion of what
   looks like 'jsonld processing' to a non-jsonld nerd is
   completely different soeone who isn't speaking jsonld

   <Zakim> Justin_R, you wanted to comment on "JSON LD Processing"

   Justin_R: you have someone doing normal json web api stuff and
   it has this context thing I need to look at and if I go digging
   in that and it has this schema document.. it's going to feel
   like I'm doing jsonld processing. Even if I"m not actually
   doing that, it feels like a requirement beyond what is
   intended. I believe the new text that says do a string
   comparison, end of day, is a good move. But we need to not
   stand on this bridge of "it's not really

   jsonld processing" unless we want to be very explicit about the
   phrase jsonld processing which isnot intutitive for people who
   are not in the jsonld space full time

   manu: +1

   DavidC: I think it's more than this becuase you have to look at
   the aliasing as well, the type is a URL but in our examples
   it's not a URL
   ... the only way you know that our examples are URLs then you
   have to do some @context processing
   ... the jsonld processor would say these types are not URLs

   dlongley: I'm not sure I follow what david is saying. If your
   app is written to understand specific contexts without having
   to do any processing on those, only understands json, and you
   write it against the rules in some spec somewhere that lists
   the meaning of that context, you sholuld be just fine. Some
   people decide to hardcode terms and keys to certain values in
   their applications. All we're doing is calling out where the
   semantic mappings and

   defintions can be found in a context file if you want to go
   into the json ld space and dereference those

   scribe: but people can write applications with hardcoded values
   without doing that

   DavidC: when they come to extend they're going to say it's a
   special type of VC..w hat are they goign to put in there? a URL
   or a string? it's going to cause ag reat deal of
   misunderstanding
   ... We either say you have to understand the aliasing mechanism
   or you don't use it

   <dlongley> this is becoming a discussion... need to take
   offline

   <Zakim> manu, you wanted to stop discussion.

   DavidC: but to leave it in this grey world where you may or may
   not use aliases or may hard code them or not, I feel it's
   storing up problems for the future when we get people using
   this down the line who are not familiar with all this
   discussion

   manu: we need to move on from discussion, we can't put forward
   a proposal for this
   ... David, what it sounds like is a bunch of normative changes?
   if you're not doing that we can add non-normative text, I've
   got a proposal to explain that stuff. I believe you're
   technically incorrect, but we need to probably have that
   discussion because again as Justin said I don't think that you
   understand at depth how jsonldp rocessors work
   ... one thing is we can have an offline discussion where we
   talk about it more in depth. Or I can propose that we make non
   normative text changes

   DavidC: I am very happy with non-normaitve text changes. We are
   using JSON and it needs to be undestandable to peopl ein that
   mode

   manu: you feel it's possible to create non-normative text that
   helps with thatJ?

   DavidC: we should certinaly have a go at it

   manu: *reads a text change* .. the json-ld processing is far
   more involved than if you do json only, which is just string
   compares
   ... nothing was raised in the issue that changes the midn of
   the group
   ... no normative changes, but we do admit we need to add
   non-normative text text to underscore why not doing context
   processing at all \(ie the string compare \) creates semantic
   ambiguity

   <manu> PROPOSED: Processing @context for both JSON-based and
   JSON-LD-based processors is vital to ensure semantic
   interoperability. The VCWG has considered the points raised in
   issue #491 and has determined that no new information has been
   provided with regard to the topic of semantic interoperability.
   Additional non-normative text should be added to the
   specification to underscore why not comparing the @context
   against known values when using JSON processors leads to
   semantic ambiguity.

   manu: that's the proposal, anything folks want to add?

   stonematt: any objections to this proposal?

   RESOLUTION: Processing @context for both JSON-based and
   JSON-LD-based processors is vital to ensure semantic
   interoperability. The VCWG has considered the points raised in
   issue #491 and has determined that no new information has been
   provided with regard to the topic of semantic interoperability.
   Additional non-normative text should be added to the
   specification to underscore why not comparing the @context
   against known values when using JSON processors leads to
   semantic ambiguity.

   <manu> [24]https://github.com/w3c/vc-data-model/issues/484

     [24] https://github.com/w3c/vc-data-model/issues/484

   manu: issue 484 is next
   ... this one is related to types
   ... tony is saying we should not be forced to use jsonld in the
   type data model, it should allow for a json model such as jwts
   and cwts, there are many parsers for those..
   ... so there's a lot of back and forth in this thread between
   tony and brent and davidc
   ... a lot of explaination that goes on and then dlongley jumps
   in .. 26+ comments
   ... tony is asking for these changes to the spec. Tony is
   asking for, specifically..

   <manu>
   [25]https://github.com/w3c/vc-data-model/issues/484#issuecommen
   t-479922835

     [25] https://github.com/w3c/vc-data-model/issues/484#issuecomment-479922835

   <Zakim> Justin_R, you wanted to discuss JSON LD semantics

   manu: in that comment tony is saying no jsonld statements are
   allowed. He says I don't thik this will work without changes to
   the spec, so the spec should say no jsonld to be allowed, no
   context to be allowed, document jwts to be allowed, jws to be
   proof mechanisms, and says there will be other things that need
   to be documented to allow jwts

   Justin_R: there's a lot of comments in that thread but honestly
   most of this boils down to be what has been one of my core
   concerns bbotu this for a while in that it's pretending to not
   use the jsonld based data model and in doing so peole coming
   with their own data model that is similar to that are offput by
   these half specified requirements to say oh well you need to
   use this date field... I already have an expirationDate field
   why would I use

   yours? At the end of the day the reuqests for requirement
   changes are smoke and mirrors. But the cause of these is valud
   and needs to be addressed. In that, as I've been saying for a
   bit, the spec needs to be more clear and up front about what
   the data structure actually is and how things are epxressed in
   such a way that they are translatable to and from that

   scribe: manu your pr and my pr have sought to address that
   although having read yours in the background, in very different
   ways
   ... I do think this is a fundamental issue of understanding
   what the spec is about but if people are reading the spec and
   saying it looks like I sholud be able to just use my data model
   here why are you telling me I can't, that's on us to be more
   clear about what the requirements really are
   ... My suggestion is to as I've said to you on side
   conversations is to stop pretending that it's more universal
   than it is
   ... this is a jsonld based data structure which you can process
   without using all the aliasing and dereferecing and all the
   other stuff, but the core data structure is based on jsonld
   schemas and constructs and we have to say that. Then you can
   answer this issue with no i'ts this but if you can translate
   from your carrier format for processing and out of it into your
   carrier format then that's fine. My pr seeks to do that

   <dlongley> +1 to Justin Richer's PR

   <dlongley> +1 to say Justin Richer's PR addresses this issue

   manu: you believe the group is working on this, we've got prs
   in. Can we address this issue by saying we're adding
   non-normative text to the spec to address this concern? once
   the nonnormative text is in the spec we should close this issue

   Justin_R: once the text is incorporated the issue should be
   closed, but it's not being closed in thew ay requested by the
   opener
   ... We need to be clear about what the spec wants

   manu: if anyone thinks that we should remove json ld and
   @context from the spec entirely please speak up
   ... we're attempting to clarify that jsonld is not mandated
   ... the issue is specifically about type, here's a proposal

   <Justin_R> who's speaking?

   <Justin_R> thanks

   TallTed: microfocus on let's change this sentance within a
   giant sphere that is itself problematic does not help us even
   though we close issues that look like they're small

   <Justin_R> +1 to TallTed's point

   TallTed: everything I heard in this conversation is based on
   jsonld structure. Requires this construct and that construct,
   all of this is jsonld. If jsonld is mandatory then this is
   based on jsonld, it is a derivative becuase it reuqires this
   other thing
   ... there is definitely an issue there, coming at least form
   this person talking about jwts and jws and other things. I have
   a concern as well that it means there's no possibility for
   future evolution among other things
   ... and that would kill the spec which is problematic, but
   maybe that's the case
   ... there's a choice between let's ram this thing through, and
   recognising that forcing a decision is problematic

   <Zakim> Justin_R, you wanted to comment on what jsonld is
   required :for:

   Justin_R: I agree this is a broader discussion. I want to
   reinforce my point that the key is being clear on what jsonld
   is for in the spec
   ... when people say you need to understand jsonld to do this
   bit and then people push back that you don't need it for
   everything all the time, then you're talking at cross purposes
   ... if the spec can be clear about what it uses the technology
   for, and how much you're required to understand (and the type
   system is one of those) then it would be in much better shape
   than to pretend those requirements of understanding ar enot
   there

   manu: we need *concrete* spec text
   ... the conversation has been very nebulous. We get it, boil it
   down to concrete spec text

   TallTed: that is not a functional response

   manu: what would make you happy?

   TallTed: I do not have an answer. Demanding concrete spec text,
   the only answer I can say to that is strip out everything that
   mentions jsonld if it is not actually mandatory. But it is
   mandatory and cannot be stripped out so that won't get any
   consideration from anybody
   ... this is one of those spaces where inertia is really
   problematic
   ... there is text here that is in a concrete form. It has
   problems. The solutions ot to those problems are not clear.
   Because the solutions are not clear, concrete suggestions are
   not possible

   <DavidC> We need to agree on the concepts and the understanding
   of them before we can produce concrete text

   TallTed: We're in a stupid system hat mandates everything be
   done in a prespecified time frame, and some things just aren't
   doable that way

   <Justin_R> +1

   <manu> [26]https://github.com/w3c/vc-data-model/issues/485

     [26] https://github.com/w3c/vc-data-model/issues/485

   manu: Next up is issue 485

   <manu> PROPOSED: The specification is not clear with respect to
   the range of possible values for the issuer property and should
   add a few non-normative examples of different values that can
   be associated with the issuer property such as identifiers
   associated with JWKs and DIDs as well as embedded values. Issue
   #485 should be closed after the PR has been merged.

   manu: about allowing the issuer to be a jwk. There has been
   some discussion in that issue, a pr has been created and
   reviewed by multiple parties indicating how a jwk can be
   included. We have made modifications to the spec that
   demonstrates how a jwk can be used

   <Justin_R> @bigbluehat can you provide a link to information
   about that forum?

   manu: We have not doen the embedded value thing yet

   <manu> PROPOSED: The specification is not clear with respect to
   the range of possible values for the issuer property and should
   add a few non-normative examples of different values that can
   be associated with the issuer property such as identifiers
   associated with JWKs and DIDs. Issue #485 should be closed
   after the PR has been merged.

   manu: there seems to be push back that he wasn't expecting that
   to be ther eso we could strike that

   stonematt: are we comfortable we won't get a new issue next
   week about embedded values?

   manu: I would expect there wouldn't be folloup, the commenter
   has said they don't expect it to be used in that way

   <manu> PROPOSED: The specification is not clear with respect to
   the range of possible values for the issuer property and should
   add a few non-normative examples of different values that can
   be associated with the issuer property such as identifiers
   associated with JWKs and DIDs. Issue #485 should be closed as
   the PR has already been reviewed and merged.

   stonematt: any objections?

   oliver: no objections. I think there might be an easier way to
   model it, to use jwk for a specific issuer. There's nothing
   that prevents someone to use the native jwt claim an dheader
   names to do that
   ... I have some issues understanding th eproposal but no
   objections so it's fine

   <Justin_R> @bigbluehat thanks, it's not letting me log in
   though. I'll have to dig up details later

   manu: technically tha'ts correct, it's just that the commenter
   said they'd like to see that specific field support jwk
   ... it does, it's a URL, it can poitn to a jwk

   oliver: all right

   RESOLUTION: The specification is not clear with respect to the
   range of possible values for the issuer property and should add
   a few non-normative examples of different values that can be
   associated with the issuer property such as identifiers
   associated with JWKs and DIDs. Issue #485 should be closed as
   the PR has already been reviewed and merged.

   stonematt: not hearing any objections, proposal is resolved

   manu: next is 486...
   ... *reads issue*

   <stonematt> [27]https://github.com/w3c/vc-data-model/issues/486

     [27] https://github.com/w3c/vc-data-model/issues/486

   manu: brent has responded, oliver has responded, I have
   responded and so has davidc
   ... both david and brent have put in PRs to address each one of
   these items
   ... the proposal is that jwts are an external enveloping
   digital sig format and cannot be embedded in data. Specifically
   asking for jwts to be embeddable both at the top level and as
   an embedded data format. You end up duplicating the
   information. LDS uses JWS today as an embedded proof format.
   That's not an official rec yet

   encryptying digitally signs expressions is also supported by
   the data model today

   scribe: we can say that we've got prs in already
   ... issue 486 shoudl be closed after non normative changes
   ... we responded to every issue that he rasied by explaining
   how the spec already supports it, or we made the one
   nonnormative change we could
   ... brent you believe that?
   ... and considereda ll the things that were raised?

   brent: i believe so. I don't know that it would make sense to
   add more nonnoramtive text to the spec that addresses it
   further. i don't feel tha tanything needs to happen. If someone
   else feels strongly that does need to happen they should speak
   up

   <manu> PROPOSED: JWTs are an external/enveloping digital
   signature format and cannot efficiently be embedded in data.
   Encrypting digitally signed (and proofed) expressions of the
   Verifiable Credentials Data Model are expected via the use of
   JWEs, COSE, TLS, and other encryption mechanisms and a fully
   supported by the Verifiable Credentials Data Model. Issue #486
   should be closed after non-normative changes to the
   specification are made #536.

   DavidC: I was just playing devil's advocate and trying to look
   at it from tony's perspective. It does seem odd the way we have
   it. The proposal I made reverts to an earlier viersion of the
   spec which would be a normative change. If we're not going to
   havea new cr I can withdraw my proposal. But if we are having a
   new CR I would like to re-look at my solution because I think
   it would appease tony better

   manu: given we don't have another CR yet would you be willing
   to hold off on that PR until the point we hit another CR?

   DavidC: Absolutely. I don't want this to be cause of another CR
   ... but if there is another CR because of something else I'd
   like to look at this as well

   manu: so, not an objection

   stonematt: we have a proposal on the table, any objections?

   RESOLUTION: JWTs are an external/enveloping digital signature
   format and cannot efficiently be embedded in data. Encrypting
   digitally signed (and proofed) expressions of the Verifiable
   Credentials Data Model are expected via the use of JWEs, COSE,
   TLS, and other encryption mechanisms and a fully supported by
   the Verifiable Credentials Data Model. Issue #486 should be
   closed after non-normative changes to the specification are
   made #536.

   <manu> [28]https://github.com/w3c/vc-data-model/issues/487

     [28] https://github.com/w3c/vc-data-model/issues/487

   manu: next up is 487
   ... the commenter has a general theme on many of the issues
   that have been raised.. they're saying how can there be interop
   if there is no standardised proof mechanism
   ... then suggesting that jws becomes that standardised proofing
   mechanism
   ... fundamentally the disagreement is it looks like you're
   creating a spec that needs a digital signature format, because
   you have provided some digital signature formats in here that
   don't have recommendations, I'm suggesting you rip those out,
   or they're all non-onrmative - and to be clear, they're all
   non-normative today, so we're doing what he is suggesting
   ... what we do allow for is a place where you can put embedded
   digital sig formats like LDproofs LDS, all using that
   mechanism, but we don't specify the details. All we specifify
   are the extension points
   ... The assertion potentially based on the way the group is
   operating is that we are definitng a set of extension points in
   the spec, not the extensions themselves. that's out of scope of
   the charter
   ... the commenter is saying why don't you make jwts the default
   and that's it?
   ... currently there is normative language in the spec that
   tells you exactly how to use a jwt and the data model together
   ... even for the nonnormative bits we use jws
   ... for the rsasignatures that we do in the LDproofs and LDS
   implementations that exist today we are using jws
   ... all of this is to say the group needs to make a decision on
   what the spec is
   ... and what it is intended to do
   ... are we doing data model with extension points? or are we
   doing data model where every single extension point has to
   demonstrate interop specifically around digital signature
   formats?
   ... or are we saying (which is what I'm saying the group has
   traditionally said) we are not picking a winner when it comes
   to digital signature formats, we're mkaing sure all of them
   could work even the ones that are nonnoramtive today because we
   have a variety of companies doing a variety of proofs in
   different ways
   ... that's the background
   ... the question in this issue is how can there be interop when
   there's no standardised proof mechanism?
   ... one way we can respond is that we acknowledge that there
   are as et of specs that are currently non normative and that
   further standards work needs to be done on them
   ... eg. LDproofs LDS
   ... and that this work would benefit from that work contunining
   in parallel outside of this group
   ... the other assertion we can make is that the spec is already
   clear about how you can utilise jwwts and jws in the current
   spec
   ... we can recommend that the spec is clear about how you use
   jwts and jws. And we ack that there are non-norm signature
   mechanisms and we recommend the reation of groups to work on
   those
   ... any objection to a proposal along those lines?

   <Justin_R> +1

   DavidC: it's good we have these extension points. We can test
   the type in the data model but we can't test the extensions.
   What I don't like about the jwts is it doesn't use the
   extension point, it doesn't say th eproof is type jwt. We've
   made a special case for jwt. What happens if you want a mime
   typ eor an x509 signature or something? how is that going to be
   put in externally? I'd prefer we put in the way of doing jwt
   using the extension points.

   It's how we used to have it. And thenw e're consistent and
   every proof is defined via the extension point

   scribe: but now we've pulled jwt out as a speical loner

   manu: we have discussed that before

   jonathan_holt: we're getting into a lot of details about
   validating signatures.. we can kick the can down the road

   manu: I didn't hear any objections, I see a +1 from Justin
   about what DavidC was saying. That's where we started. There's
   an enormous amount of duplication when we take a JWT and put it
   in the proof. We did have a discussion with mike jones and
   other folks about how to embed the proof. THat's exactly how
   the ?? works. The nonnormative thing already does what you're
   saying we should do
   ... but that was not acceptable to some of the folks that were
   suggesting jwts
   ... what we have in the spec is a result of those types of
   discussions
   ... w e're doing what you want david, but that is not
   acceptable to the folks pushing the jwts stuff

   Justin_R: if we're not here to discuss things then I guess it's
   done..

   manu: is ther esomething we could push to another call?

   Justin_R: nothing I could bring up now would be to fruitful
   conversation and resolution

   manu: would you like to change the context of the discussion?

   Justin_R: we can move on

   oliver: the reason we chose this approach was to make use of
   existing jwts out there and try to be compliant with the jwt
   spec, that's why we ended up having the jwt data model the way
   it is now
   ... otherwise we woul dhave to have all information duplicated
   which was not very efficient

   manu: yep
   ... the spec is clear about jwts and the data model,t here are
   normative statements around that. We're acknowledging that we
   can't make normative statemetns but that the work could be
   continues, and it would help a bunch of other specs too
   ... that closes the issue
   ... any objections to that sort of proposal?

   <manu> PROPOSED: The specification is clear wrt. using JWT and
   JWS with the VC Data Model. The VCWG acknowledges that a W3C
   Recommendation for RDF Dataset Canonicalization, Linked Data
   Proofs, and Linked Data Signatures does not exist, and that the
   Verifiable Credentials Data Model specification, as well as a
   number of Linked Data Working Groups at W3C, would benefit from
   such a set of standards. The VCWG strongly recommends the
   creation of a W3C Working Group to create such a set of W3C
   Recommendations. This closes issue #487.

   Justin_R: this ultimately boils down to what is the scope of
   the document?
   ... given how much each of these issues have been coming up,
   regardless of what happened to get to this point, more people
   ar elooking at it, we need to consider these points. It is
   unclear what the scope of the document truly is. If the
   resolution is puttin gin more nonnormative text that says how
   you do this is something else and not our problem then we need
   to do that
   ... pretending there are extension points when there is
   handwaving is not helpful to interop or the viability of the
   spec

   <TallTed> +1

   <dlongley> +1 to clarifications to reach the intent

   <scribe> scribenick: yancy

   <oliver> could you share the PR again?

   manu: agreed

   <Justin_R> [29]https://github.com/w3c/vc-data-model/pull/539

     [29] https://github.com/w3c/vc-data-model/pull/539

   stone: which PR
   ... 539

   <Justin_R> That's the bit about data primacy, it doesn't
   address things at the root level of the spec about scope

   <manu> PROPOSED: The specification is clear wrt. using JWT and
   JWS with the VC Data Model. The VCWG acknowledges that a W3C
   Recommendation for RDF Dataset Canonicalization, Linked Data
   Proofs, and Linked Data Signatures does not exist, and that the
   Verifiable Credentials Data Model specification, as well as a
   number of Linked Data Working Groups at W3C, would benefit from
   such a set of standards. The VCWG strongly recommends the
   creation of a W3C Working Group to create

   <manu> such a set of W3C Recommendations. Additionally,
   non-normative text should be added to the specification that
   suggests that data needs to be translated to/from the data
   model, once this PR is in, issue #487 should be closed.

   manu: any objections?

   davidc: the proof should be there for jwt

   <manu> PROPOSAL: The specification is clear wrt. using JWT and
   JWS with the VC Data Model. The VCWG acknowledges that a W3C
   Recommendation for RDF Dataset Canonicalization, Linked Data
   Proofs, and Linked Data Signatures does not exist, and that the
   Verifiable Credentials Data Model specification, as well as a
   number of Linked Data Working Groups at W3C, would benefit from
   such a set of standards. The VCWG strongly recommends the
   creation of a W3C Working Group to create such a set of W3C
   Recommendations. Additionally, non-normative text should be
   added to the specification that suggests that data needs to be
   translated to/from the data model and to pay particular
   attention to the proof extension point, once this PR is in,
   issue #487 should be closed.

   manu: posts new proposal
   ... any objections?

   RESOLUTION: The specification is clear wrt. using JWT and JWS
   with the VC Data Model. The VCWG acknowledges that a W3C
   Recommendation for RDF Dataset Canonicalization, Linked Data
   Proofs, and Linked Data Signatures does not exist, and that the
   Verifiable Credentials Data Model specification, as well as a
   number of Linked Data Working Groups at W3C, would benefit from
   such a set of standards. The VCWG strongly recommends the
   creation of a W3C Working Group to create such a set of W3C
   Recommendations. Additionally, non-normative text should be
   added to the specification that suggests that data needs to be
   translated to/from the data model and to pay particular
   attention to the proof extension point, once this PR is in,
   issue #487 should be closed.

   <manu> [30]https://github.com/w3c/vc-data-model/issues/483

     [30] https://github.com/w3c/vc-data-model/issues/483

   manu: next up is 483. same one we attempted last week.
   ... johnny crunch and manu discussed on phone
   ... no reason to make in mandatory
   ... attempting language to address that right now
   ... don't make context mandatory
   ... versus json processing of it
   ... suggestion here is no change to the spec
   ... because it's already optional
   ... we can add clarifying text to the spec
   ... which is also being added because of other PRs
   ... we are not goting to remove at context processing from the
   spec

   <manu> PROPOSED: The VCWG had considered all points raised by
   issue #483 throughout the lifetime of the WG's operation, no
   new information was provided by issue #483 to convince the WG
   to change @context being mandatory (which has broad support in
   the WG with no objections). The WG will provide non-normative
   changes to the specification to clarify when and how @context
   should be processed and that "JSON-LD processing" is optional.

   manu; there's the proposal

   stone: any objections?

   RESOLUTION: The VCWG had considered all points raised by issue
   #483 throughout the lifetime of the WG's operation, no new
   information was provided by issue #483 to convince the WG to
   change @context being mandatory (which has broad support in the
   WG with no objections). The WG will provide non-normative
   changes to the specification to clarify when and how @context
   should be processed and that "JSON-LD processing" is optional.

   stone: resolved

   <manu> [31]https://github.com/w3c/vc-data-model/issues/488

     [31] https://github.com/w3c/vc-data-model/issues/488

   manu: back to 488
   ... variation on the same argument
   ... tony is suggesting that presentation is at risk
   ... in conflict with previous arguments
   ... brent and tony have gone back and forth many times
   ... anything marked at risk are then removed
   ... this is an argument for the removal of presentation
   ... didn't mark at risk
   ... we ack that there are several different types of proofs and
   provided a mechanism to provide more than one of those
   ... right now we use language that should be modified and we
   need to clarify requirements

   <manu> PROPOSED: Implementers were polled before the
   specification entered the Candidate Recommendation phase and
   more than two implementers stated that they would implement
   this feature, thus it is not at risk. Interoperability for this
   feature is achieved if at least two independent implementations
   support the data model features in the specification, The WG
   acknowledges that there are several different types of
   zero-knowledge proof mechanisms and has provided a mechanism
   where one or more of those mechanisms can be combined with the
   data model in the specification. The group agrees that
   non-substantive changes should be made to the section to
   clarify the normative requirements more precisely and then
   issue #488 should be closed after that PR is approved and
   merged.

   RESOLUTION: Implementers were polled before the specification
   entered the Candidate Recommendation phase and more than two
   implementers stated that they would implement this feature,
   thus it is not at risk. Interoperability for this feature is
   achieved if at least two independent implementations support
   the data model features in the specification, The WG
   acknowledges that there are several different types of
   zero-knowledge proof mechanisms and has provided a mechanism
   where one or more of those mechanisms can be combined with the
   data model in the specification. The group agrees that
   non-substantive changes should be made to the section to
   clarify the normative requirements more precisely and then
   issue #488 should be closed after that PR is approved and
   merged.

   stone: proposal resolved

   <manu> [32]https://github.com/w3c/vc-data-model/issues/489

     [32] https://github.com/w3c/vc-data-model/issues/489

   <stonematt> Implementor List:
   [33]https://drive.google.com/open?id=1SzfAUA0J72-1BORHJEmY4cdZr
   Q6vmKy4oq_24r_NwB4

     [33] https://drive.google.com/open?id=1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4

   amy can you scribe again?

   <rhiaro> scribenick: rhiaro

   manu: they're suggesting the removal of jsonld entirely since
   it's not in a standards body... but it was ratified by w3c many
   years ago.. there's an active json 1.1 wg right now, the
   commenter may be unaware that it wwent to through the
   standardisation procses twice now. But they want tha tproofs
   are marked as risk because there's no interoprable
   recommendation. We realised that the extension point we are
   demonstrating is the proof extension point,

   and we can't say anything about it until those things become
   recs. But there have been multiple iplementors who say they'll
   support that part of the data model

   scribe: the test suite will have non required tests to
   demonstrate ldproof interop, but we can't make them official
   tests because they're not recommendations
   ... we could respond with the VCWG does not support the removal
   of jsonld from the spec
   ... specifically for section 4.7, interop is defined by two
   implementations implementing the normative statements in the
   section
   ... we do have normative statements in there on how you
   identify the type of proof in the extension points. The VCWG
   does not believe it's not appropriate to make this section
   non-normative. We need to make sure you can identify the type
   of proof that' sused. The suggestion is to close the issue with
   no change to the spec

   <manu> PROPOSED: The VCWG does not support the removal of
   JSON-LD from the specification. For Section 4.7: Proofs,
   interoperability is defined as at least two implementations
   implementing the normative statements in the section.
   Specifically, that the data model specifies a mechanism to
   express an embedded proof and the type of proof. The VCWG does
   not believe that it is appropriate to make this section
   non-normative. Issue #489 should be closed with no change to
   the specification.

   stonematt: any objections?
   ... hearing none

   RESOLUTION: The VCWG does not support the removal of JSON-LD
   from the specification. For Section 4.7: Proofs,
   interoperability is defined as at least two implementations
   implementing the normative statements in the section.
   Specifically, that the data model specifies a mechanism to
   express an embedded proof and the type of proof. The VCWG does
   not believe that it is appropriate to make this section
   non-normative. Issue #489 should be closed with no change to
   the specification.

   <jonathan_holt> were there any other issues that need me? I
   need to drop off

   <manu> [34]https://github.com/w3c/vc-data-model/issues/496

     [34] https://github.com/w3c/vc-data-model/issues/496

   manu: next up is expiration, 496
   ... suggestion is values like expiration date should be changed
   to match jwts
   ... *reads issue*
   ... brent's response is a VC is not a JWT. JWTs can encapsulate
   VCs, but are not in and of themselves VCs
   ... the other assersion that olive rmade is that the
   serialisation, the values associated with exp and
   expirationdate are different
   ... there's a section in the spec that tells you how to convert
   between the two
   ... tony says all existing jwt claims should be allowe dfor
   interop. There's a section in the spec that expresses how you
   express this stuff using a jwt that does not limit any jwt
   claim used today

   <Zakim> Justin_R, you wanted to discuss JWTs vs. VC

   Justin_R: I keep saying this but if we are clear about the fact
   that th eprocessing of the semantic document require that dates
   be converted to a specific structure for comparison in the case
   of expiration, for any other addition math or whatever, all of
   these data values need to live in a data model in a specific
   place and all serialisations must have fully spec'd and
   determinisitc translations into and out of that data model
   ... then the data model becomes the semantic interlingua? for
   all of the syntactic serialisations
   ... if you say the data model uses jsonld dates, that's fine
   ... the problem is that there are serialisation formats people
   want to use that have their own date formats. You want to say
   yes you can do that, and that's okay for processing hte jwt but
   not for processing the VC as a VC
   ... you need to translate into this other thing
   ... if I"m going to speak jwts it's going to need a vc.parse
   that takes a jwt in and spits out a vc object

   <dlongley> it's not a "JSON-LD" date (btw)... it's RFC3339,
   JSON-LD doesn't define "dates" ... but yes, we do say RFC3339
   for the issuanceDate property.

   <oliver> +1

   Justin_R: if that vc object where all of the holder proofing
   happens, but when I got to validate the proofing signature that
   goes back to the original jwt and it's validation fields. These
   are not incompatible with each other, but it's a matter of
   saying what the document is specifying which is a semantic data
   structure and not a specific syntax
   ... and that the syntaxes are translations of that

   <DavidC> +1

   manu: how do we turn that into something concrete? doe syour pr
   do that? or we need a new pr

   Justin_R: your pr does not do that, my pr is my best attempt at
   that
   ... I'm open to comments to make my pr better

   manu: if we said we're going to address this issue by
   effectively pulling in your pr, my pr or some combination
   thereof, you'd feel this issue was addressed?

   Justin_R: yes, addressed in a way that we are saying no we're
   not just going to use the exp field and posix dates which is
   what you've said in the comment thread on that issue
   ... but we are saying if you have date fields and you translate
   them into posix dates, as long as you can do that without data
   loss (deterministic and bidirectional) and then on the other
   end you can translate it back into an actual data object that
   someone can do comparisons on, then we're fine

   <manu> PROPOSED: Re-using the JWT "exp" claim in a Verifiable
   Credential is not appropriate because the datatype associated
   with JWT "exp" is a POSIX time value and the datatype
   associated with the expirationDate is a RFC3339 combined date
   and time string. The VCWG prefers the more verbose datatype.
   Non-normative text should be added to the specification on how
   deterministic and bi-directional translation should be done and
   issue #496 should be closed after that PR is merged into the
   specification.

   stonematt: any objections?
   ... hearing none

   RESOLUTION: Re-using the JWT "exp" claim in a Verifiable
   Credential is not appropriate because the datatype associated
   with JWT "exp" is a POSIX time value and the datatype
   associated with the expirationDate is a RFC3339 combined date
   and time string. The VCWG prefers the more verbose datatype.
   Non-normative text should be added to the specification on how
   deterministic and bi-directional translation should be done and
   issue #496 should be closed after that PR is merged into the
   specification.

   <manu> [35]https://github.com/w3c/vc-data-model/issues/500

     [35] https://github.com/w3c/vc-data-model/issues/500

   manu: next up is status.. 500
   ... the mention of the status registry, who runs it, why isn't
   it iana? is the question
   ... those questions were answered, there's another issue that
   says we should have an extension point registry. The group
   seems to be pushing that over to the CCG to manage that
   ... that's where the current proposal is, the ccg will maintain
   it
   ... Why not iana? At this point the group doesn't feel like we
   need to go to those lengths but we may change our mind later on
   or others may move it to iana in the future, currently we want
   it to be very lightweight
   ... w3c is already working on a registry mechanism through th
   eAC and we're supposed to talk with chaals about that
   ... that kind of addresses the why/who is running it question
   ... The other question is how will interop be achieved if these
   are not standardised in a registry accessible to all
   implementations
   ... it is accessible, it's an html link that anyone can follow
   ... then he says the data model doesn't need to exist. Don't
   understand the logic there. But he's saying 4.9 status sholud
   be marked at risk because there's no nonnormative solutions for
   it and interop cannot be shown on the mechanism
   ... THe response we can have is that we have defined an
   extension point and your requirement, the normative statement
   is that you're required to express the type information that's
   associated with the status mechanism
   ... So effectively no change to the spec
   ... Given the other suggestiosn in the other prs that are we're
   going to make it very clear that we're trying to specify the
   extension points, not every single extension that could be used

   <manu> PROPOSED: The VCWG has delegated the management of all
   extension registries associated with the Verifiable Credentials
   Data Model to the W3C Credentials Community Group in order to
   support continuity in the extension work as well as a ensuring
   a light-weight process for managing the registry. The W3C is
   incubating a registry process as well, and we are in
   discussions with the Advisory Board on that. The VCWG believes
   that this approach strikes the right balance of formalism and
   flexibility at this stage of the specifications deployment into
   the market. With respect to the 'status' field, the group has
   defined an extension point and a mechanism to identify specific
   extensions, which are the normative statements in that section.
   Issue #500 should be closed with no changes to the
   specification.

   stonematt: any objections?

   RESOLUTION: The VCWG has delegated the management of all
   extension registries associated with the Verifiable Credentials
   Data Model to the W3C Credentials Community Group in order to
   support continuity in the extension work as well as a ensuring
   a light-weight process for managing the registry. The W3C is
   incubating a registry process as well, and we are in
   discussions with the Advisory Board on that. The VCWG believes
   that this approach strikes the right balance of formalism and
   flexibility at this stage of the specifications deployment into
   the market. With respect to the 'status' field, the group has
   defined an extension point and a mechanism to identify specific
   extensions, which are the normative statements in that section.
   Issue #500 should be closed with no changes to the
   specification.

   stonematt: how do we want to follow up on the discussions that
   were postponed to be continued offline?

   <DavidC> Can we fix up a date and time now

   manu: let's see if people are available tomorrow. Justin,
   David, brent, do you have availability tomorrow?
   ... after 12pm ET?

   <DavidC> Yes I am free all day tomorrow

   brent: i have extremely limited availability through to the end
   of this week

   manu: what is your availability?

   brent: i'd have to get backt o you

   manu: any days we should avoid for all of you?

   <DavidC> Friday is no good for me

   Justin_R: My schedule is not clear

   ken: I can accommodate

   manu: looks like it'll be wednesday/thursday

   <DavidC> Thursday early for you is good for me

   manu: we'll send out an email, everyone can attend

   stonematt: would you list the prs we might discuss? refresh
   service wa sa huge topic
   ... Thanks everyone
   ... bye

Summary of Action Items

Summary of Resolutions

    1. [36]Processing @context for both JSON-based and
       JSON-LD-based processors is vital to ensure semantic
       interoperability. The VCWG has considered the points raised
       in issue #491 and has determined that no new information
       has been provided with regard to the topic of semantic
       interoperability. Additional non-normative text should be
       added to the specification to underscore why not comparing
       the @context against known values when using JSON
       processors leads to semantic ambiguity.
    2. [37]The specification is not clear with respect to the
       range of possible values for the issuer property and should
       add a few non-normative examples of different values that
       can be associated with the issuer property such as
       identifiers associated with JWKs and DIDs. Issue #485
       should be closed as the PR has already been reviewed and
       merged.
    3. [38]JWTs are an external/enveloping digital signature
       format and cannot efficiently be embedded in data.
       Encrypting digitally signed (and proofed) expressions of
       the Verifiable Credentials Data Model are expected via the
       use of JWEs, COSE, TLS, and other encryption mechanisms and
       a fully supported by the Verifiable Credentials Data Model.
       Issue #486 should be closed after non-normative changes to
       the specification are made #536.
    4. [39]The specification is clear wrt. using JWT and JWS with
       the VC Data Model. The VCWG acknowledges that a W3C
       Recommendation for RDF Dataset Canonicalizatioe, Linked
       Data Proofs, and Linked Data Signatures does not exist, and
       that the Verifiable Credentials Data Model specification,
       as well as a number of Linked Data Working Groups at W3C,
       would benefit from such a set of standards. The VCWG
       strongly recommends the creation of a W3C Working Group to
       create such a set of W3C Recommendations. Additionally,
       non-normative text should be added to the specification
       that suggests that data needs to be translated to/from the
       data model and to pay particular attention to the proof
       extension point, once this PR is in, issue #487 should be
       closed.
    5. [40]The VCWG had considered all points raised by issue #483
       throughout the lifetime of the WG's operation, no new
       information was provided by issue #483 to convince the WG
       to change @context being mandatory (which has broad support
       in the WG with no objections). The WG will provide
       non-normative changes to the specification to clarify when
       and how @context should be processed and that "JSON-LD
       processing" is optional.
    6. [41]Implementers were polled before the specification
       entered the Candidate Recommendation phase and more than
       two implementers stated that they would implement this
       feature, thus it is not at risk. Interoperability for this
       feature is achieved if at least two independent
       implementations support the data model features in the
       specification, The WG acknowledges that there are several
       different types of zero-knowledge proof mechanisms and has
       provided a mechanism where one or more of those mechanisms
       can be combined with the data model in the specification.
       The group agrees that non-substantive changes should be
       made to the section to clarify the normative requirements
       more precisely and then issue #488 should be closed after
       that PR is approved and merged.
    7. [42]The VCWG does not support the removal of JSON-LD from
       the specification. For Section 4.7: Proofs,
       interoperability is defined as at least two implementations
       implementing the normative statements in the section.
       Specifically, that the data model specifies a mechanism to
       express an embedded proof and the type of proof. The VCWG
       does not believe that it is appropriate to make this
       section non-normative. Issue #489 should be closed with no
       change to the specification.
    8. [43]Re-using the JWT "exp" claim in a Verifiable Credential
       is not appropriate because the datatype associated with JWT
       "exp" is a POSIX time value and the datatype associated
       with the expirationDate is a RFC3339 combined date and time
       string. The VCWG prefers the more verbose datatype.
       Non-normative text should be added to the specification on
       how deterministic and bi-directional translation should be
       done and issue #496 should be closed after that PR is
       merged into the specification.
    9. [44]The VCWG has delegated the management of all extension
       registries associated with the Verifiable Credentials Data
       Model to the W3C Credentials Community Group in order to
       support continuity in the extension work as well as a
       ensuring a light-weight process for managing the registry.
       The W3C is incubating a registry process as well, and we
       are in discussions with the Advisory Board on that. The
       VCWG believes that this approach strikes the right balance
       of formalism and flexibility at this stage of the
       specifications deployment into the market. With respect to
       the 'status' field, the group has defined an extension
       point and a mechanism to identify specific extensions,
       which are the normative statements in that section. Issue
       #500 should be closed with no changes to the specification.

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [45]scribe.perl version 1.154 ([46]CVS log)
    $Date: 2019/04/16 13:39:48 $

     [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [46] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 April 2019 13:42:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 April 2019 13:42:35 UTC