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

VCWG Group Discussion #1 on CR issues/PRs Minutes for 2019-04-10

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 10 Apr 2019 14:48:27 -0400
To: W3C Verifiable Credentials Working Group <public-vc-wg@w3.org>
Message-ID: <c82e0c49-52f1-404d-52b6-2c1fa35ea019@digitalbazaar.com>
Here are the minutes from today's call. The purpose was to get alignment
around how we are going to process Candidate Recommendation PRs that
needed more debate and any other issues that the group felt might need
more alignment on before a proposal.

VCWG Group Discussion #1 on CR issues/PRs Minutes for 2019-04-10

Agenda:
  1. Process Justin's concerns
  2. Process Ken's concerns
  3. Process David Chadwick's concerns
  4. General (focused) discussion until we want to wrap on PRs/issues
Topics:
  1. refreshService Feature
  2. Data Model vs. Syntax
  3. Extension mechanisms in the spec
  4. credentialSchema
  5. Change in Identifiers section
  6. Unification of ecosystem Overview and Terminology
  7. Any Concerns around how CR Process is being run
Organizer:
  Manu Sporny
Scribe:
  Dave Longley and Brent Zundel
Present:
  Dave Longley, Brent Zundel, Manu Sporny, David Chadwick, Ken
  Ebert, Nathan George, Dmitri Zagidulin, Justin Richer
Audio:
  https://w3c-ccg.github.io/meetings/2019-04-10/audio.ogg

Dave Longley is scribing.

Topic: refreshService Feature

Ken Ebert: https://github.com/w3c/vc-data-model/pull/540
Manu Sporny: https://github.com/w3c/vc-data-model/pull/501
Manu Sporny: https://github.com/w3c/vc-data-model/issues/458
Manu Sporny:  Ken why don't you kick us off? [scribe assist by
  Dave Longley]
Ken Ebert:  My main concern is that we are cutting the holder out
  of the equation if we're allowing the verifier to bypass them and
  go directly to the issuer. That removes the holder's control.
  [scribe assist by Dave Longley]
Ken Ebert:  Main concern is that we are cutting the holder out of
  the equation if we allow the verifier to bypass them to go right
  to the issuer
Ken Ebert:  That allows for issuers and verifiers to do whatever
  they want without the holder's consent. [scribe assist by Dave
  Longley]
Nathan George:  It has helped to think about having an additional
  holder here. You are using the anchoring of who the issuer is to
  talk to their identity agent or service directly just like any
  other holder to get an additional copy of the credential. The
  refresh service encourages direct communication between the
  issuer and verifier. [scribe assist by Dave Longley]
Nathan George:  The concern I have is that the refresh service
  encourages direct communication between verifiers and issuers
Brent Zundel is scribing.
  ... if issuer and verifier talk directly, that is the federated
  token model we already have.
Manu Sporny:  If we make this change, See no way it is not a
  substantive normative change.
  ... my concern is process without destroying the spec. Want a
  REC not a wreck.
Nathan George:  What are consequences of that?
Manu Sporny:  Need another broad review from everyone who already
  has (like 8 other groups)
  ... publish a new spec with all changes, release new CR, then
  get review. if we make this change, we have 3 months to finish
  the spec before charter ends
  ... if we signal another CR, this will introduce even more
  breaking changes from others.
  ... Justin has mentioned he's not totally comfortable with some
  of the JWT stuff, so there may also be changes there.
  ... going through another CR is a very big deal and would cause
  a re-review by the W3C of the charter, plus another round of
  formal objections
, Etc
Manu Sporny:  There may be some language lawyering we could
  introduce non-normatively. The current PR introduces new
  normative language. it is not a bug in the spec that is being
  fixed
Nathan George:  It is possible for a verifier to discover who the
  issuer is. we don't want the collapse of the three-way
  relationship and cut out the holder.
  ... holder gives the right to the verifier to request a new
  credential from the issuer as a new holder
Dave Longley:  I feel like we're falling back into the trap of
  trying to restrict the data model. What we should do instead is
  allow the data model in many ways, but make clear that there are
  consequences for using it certain ways, non-normatively.
  ... for example, we could use a refresh service  that uses ocap
  to permit a verifier to get updated data.
Ken Ebert: From nage: I don't see how that isn't protocol
  specific, why is that a data model concern?
  ... all of these things enable a variety of use cases, zkp uses
  are not other uses, refresh service is an extension point
  ... what is missing is non-normative text around hoe the
  refresh service may be used and the protections that may be
  desired for zkp uses.
David Chadwick:  I don't think it appropriate for verifiers to go
  to issuers, but when dlongley pointed out certain use cases where
  for the public good, there would be a need for certain limited
  use cases where the verifier can go directly to the issuer.
  ... there should be language that makes this use case clear.
Nathan George:  Not seeing how this isn't protocol specific, why
  is a refresh service needed if the verifiable data registry can
  prove freshness
Dave Longley: Yes, it's a protocol concern, but the data model
  must enable it
Dmitri Zagidulin:  In some cases, it is required for verifiers to
  contact issuers.
Dave Longley: And that's all we're trying to do
Dave Longley: The data model simply says "put refresh services
  here"
Dmitri Zagidulin:  Old school US credit cards, some people put
  "please check ID" that's an attribute of the credential where the
  verifier needs to check with the issuer.
Dave Longley: The data model can't do that! :)
Nathan George:  I'm not opposed to that because the Holder is the
  one letting the verifier check with the issuer. what I am not
  okay with is the issuer saying the verifier must check with them.
Manu Sporny:  I want to ask a high level question. We are diving
  into protocol.
  ... can we agree to try to not put us into another CR? Is there
  a way to address this non-normatively?
  ... would Sovrin give a formal objection if only non-normative
  changes are made to correct this?
  ... I want to make sure that's not what Ken is saying.
  ... Is there a way to put something non-normative in the spec
  that says "in general don't allow the verifier to contact the
  issuer out of band, but there are some cases where it may be
  appropriate"
Dave Longley:  Plus 1 to non-normative text
  ... this is a data model, all we're doing is providing an
  extension point for possible refresh services. We shouldn't talk
  about protocol at all, except non-normative guidance for
  implementors creating refresh services.
  ... requiring holder consent, for example. Like an ocap that
  may be revoked at any time.
  ... the point is we can't talk about the protocol in the spec.
  The spec only defines where the refresh service extension point
  should go.
  ... anybody using the VC data model can come up with whatever
  refresh service they want.
Ken Ebert:  I think that it might be possible to come up with
  non-normative language that pioints out the dangers.
  ... or to say that if a verifier receives a credential as a
  holder.
Manu Sporny:  We could say something even stronger than that.
  ... Something that addresses Sovrin's concern here. All we need
  to start drafting that is an agreement that we want to take the
  non-normative approach.
Ken Ebert:  There are other problems as well. the current
  language doesn't make clear where the refresh service goes and
  who has access.
  ... DavicC has clarified his understanding of it, which has
  helped me, but there is additional tightening up that is
  necessary for clarity.
Dave Longley: +1 To careful non-normative languages and
  clarifications about this feature
  ... where do refresh services go and who are they applicable
  to?
Manu Sporny: +1
Manu Sporny:  Just to be clear, we can write 20 pages of
  non-normative text. writing normative changes is where we get
  into trouble.
Dave Longley: +1 To telling users there are serious data privacy
  and control concerns with the feature
  ... I think we all agree to attempt to address this concern
  non-normatively.
Dave Longley: -1 To 20 pages :)
Ken Ebert:  I think we should try to make that work, hopefully
  not 20 pages worth.
Nathan George: I am concerned about whether non-normative text is
  sufficient to keep us out of big trouble, but think it is worth a
  try.
  ... maybe I could work with the Daves to come up with language
  that works.
Manu Sporny:  Can we close both open PRs and create a new one, or
  should we use one to build from?
Ken Ebert:  Mine should probably close.
David Chadwick:  I'm happy to close the PRs.
Manu Sporny:  Who will do the new PR?
David Chadwick:  Happy to give it a bash.
Manu Sporny:  Yes
Ken Ebert:  Yes, if I feel it hasn't worked, I'll put together an
  alternative PR.
Manu Sporny:  IO am closing those PRs now, with a note about our
  decision.
Dave Longley: I do think it's important to have more
  clarification around this feature
Ken Ebert:  Also suggest dlongley review those.
Dave Longley:  Yes, we can do that and iterate on the submitted
  PR.
Manu Sporny:  Closing DavidC and ken PRs with comments
  ... DavidC will create a new one for the group to review.
  ... thanks ken for being flexible
Manu Sporny:  Justin, how long are you here.
Justin Richer:  I am here now.

Topic: Data Model vs. Syntax

Manu Sporny: https://github.com/w3c/vc-data-model/pull/539
Manu Sporny:  I closed mine, let's talk about yours.
Justin Richer:  Is there any text in yours that should be in
  mine?
Manu Sporny:  I honestly don't care, it is all non-normative.
Justin Richer:  Nothing in yours you felt is required?
Manu Sporny:  No
Justin Richer:  PR 539. Tried to address the notion over what a
  verifiable credential is, with as light a touch as possible.
  ... in my opinion, this would be easier if normative.
  ... as far as informative changes, this is what I've got.
Manu Sporny:  I added minor editorial nits yesterday.
Justin Richer:  Avoid must, not a big deal. didn't want to weasel
  too much.
  ... wrapping things with anchor links, no problem
  ... new paragraph, no problem
  ... going thorugh manu nits
  ... another anchor link, okay
  ... that's all fine.
Going through proposed changes in PR 539
Justin Richer:  Essentially, all the syntactical representations
  of the data model should be able to move from the data model to
  the syntax deterministically and reversibly
  ... We can get along part of the way there informatively.
David Chadwick: +Q
  ... interoperability is not in the syntax, it is in the data
  model.
David Chadwick:  I love this approach and wish it had come up
  with months ago.
Justin Richer:  Unfortunately I've only been here two minths and
  it took time to get up to speed.
Dave Longley:  I like this PR. this makes explicit what was
  tribal knowledge, so thank you
Brent Zundel: +1
Manu Sporny: +1
Justin Richer:  Absolutely. I could tell this was what people
  were assuming. glad to help.
  ... also good to here that what I pulled out is actually the
  intent
S/here/hear
  ... apart from some wordsmithing, what I'm trying to say (in
  the intro to the serialization section) the verifiable credential
  and presentation are defined by the data model, everything else
  is a serialization of that.
Continues covering PR
Justin Richer:  Finally, this document makes no requirement in
  terms of conformance for any specific serialization.
  ... which is behind a lot of the grousing from microsoft.
  ... in the JWT world, they are allowed to not know what to do
  this a non-JWT credential, but not allowed to create a JWT that
  can't be transformed into this data mdoel.
Manu Sporny:  I looked back at the conformance section and this
  says that too, but not as stringly.
Justin Richer:  May be worth saying that a conforming document is
  one that fits the data model, a conforming serialization, must be
  able to be deterministically converted into and out of the data
  model.
  ... I think it makes sense to try for changes to conformance
  section that everyone agrees is non-normative.
  ... I anticipate this would be a change in normative text that
  is not a change in normative requirements.
  ... the note on the JSON section. this section is useless
  garbage.
  ... it is awful
Manu Sporny:  I can explain why some of that exists
Justin Richer:  It is inexcusable. Really what we make clear is
  that even by following these rules, they will not end up with an
  interoperable thing.
Manu Sporny:  Any objections to merging this?
Justin Richer:  One more point to make: the proof is often tied
  to the transmission format, especially when using a
  non-canonicalization based format.
  ... we need to warn people that they need to keep the string
  that came over the wire in order to continue being able to
  verify.
  ... this is calling out a requirement for implementors to be
  aware of.
Plus ones
Ken Ebert: +1
Justin Richer:  Cool. I'll clean up the PR
Manu Sporny:  Last chance to object
  ... two other things jricher brought up.
Justin Richer:  Informative references for signature methods and
  no PR or issue seen for that.

Topic: Extension mechanisms in the spec

Manu Sporny:  There are a number of assertions that the spec is
  not interoperable
  ... proof formats, status checking, anywhere there is an
  extension point.
  ... counter argument is "charter says data model interop, not
  extension point interop"
  ... want feedback on what we thought we are creating.
David Chadwick: Extension point plus type only. Not every type of
  extension
  ... are we testing what extensions do? or just that the
  extension points can exist and the extension be identified?
Brent Zundel: +1
Ken Ebert: Extension points with examples
Dave Longley:  I agree
Manu Sporny:  Justin, your thoghts?
  ... you might be muted.
  ... did he drop?
Justin is back, Manu recaps
Justin Richer:  That's fine. I think it would be better to define
  what conformance and interop means is the best way to go
Manu Sporny:  I didn't get all of that from what you said.
Justin Richer:  I was trying to solve the underlying problem of
  an ill-defined core.
  ... core part of argument needs to be that conformance to data
  model is how interop is proven.
Manu Sporny:  Looking at PRs.
  ... credentialSchema is next.
  ... DavidC this one is yours.

Topic: credentialSchema

Manu Sporny: https://github.com/w3c/vc-data-model/pull/533
Manu Sporny: https://github.com/w3c/vc-data-model/issues/474
David Chadwick:  Basically, issue tries to make clear difference
  between context and schema.
  ... context was sufficient for awhile, then shema was added
  because context is not sufficient anymore.
Manu Sporny:
  https://github.com/w3c/vc-data-model/issues/474#issuecomment-481693698
Manu Sporny:  There is a discussion here that is useful. David
  would like to say these things in a non-normative way.
David Chadwick:  Some of the answers are in the responses in the
  issue, that text needs to be in the spec.
Manu Sporny:  What I need you to do is respond to the questions.
  ... I'm willing to write the PR.
David Chadwick:  That is fine.
Manu Sporny:  Zundel wrote the first PR.
  ... I will take that text and built off of it.
Brent Zundel: +1
Manu Sporny:  When we have a PR then we will be able to discuss.

Topic: Change in Identifiers section

Manu Sporny: https://github.com/w3c/vc-data-model/pull/534
Dave Longley is scribing.
Brent Zundel:  I noticed a sentence in the identifiers section
  that seemed to me to be untestable as conformance to a data
  model.
Brent Zundel:  The PR seeks to introduce a correction of that.
Brent Zundel:  That non-normative conformance statement.
Manu Sporny:  The only issue here is that you removed the capital
  MUST and you added a MAY. And that's the thing that
  triggers/that's one signal that you're making a substantive
  normative change. I agree with you that it's untestable.
Brent Zundel:  I'm not willing to put us into another CR just for
  this change. I also don't see how we're going to test conformance
  to this, it seems like there should be a change but I don't know
  how.
Ken Ebert:  If you have the identifier, it must be expressed
  using the `id` property. I think what you're saying is referring
  back to whether or not the object has an identifier separate from
  it must be expressed using an `id` property. The separation of
  how you express it and the optionality of whether it's there or
  not and if you separate them then you can get the language to
  work.
Brent Zundel:  It's in there that the `id` is optional, then only
  thing that's in there is the MAY... there's an odd way of saying
  the same thing.
Manu Sporny:  If two people want to talk about the same thing,
  identify that same thing. That's fundamentally what we're saying
  here and that you MUST identify it that way because that's the
  only way you can tell two sets of attributes are associated with
  the same thing.
Manu Sporny:  We also say that's optional -- as long as we can
  preserve that MUST in some way, we're fine.
Manu Sporny:  Let's not get into another CR over this.
Brent Zundel:  All the MUST is saying is that you need to adhere
  to the data model. I'm willing to totally back off on this if
  that's the easiest way to do it.
Manu Sporny:  It is, but if we want changes there are some we can
  make. One of the tests can just make sure you express `id`. The
  way you fail this test is someone gives you an `id` and you
  delete it -- and that test would fail. The test makes sure you
  preserve `id`.
Brent Zundel:  As long as there is a test that can test this I
  have no problem at all.
Manu Sporny:  I think we have a test currently that does this.
Brent Zundel:  If you'd be willing to add a comment on this issue
  and that we have a test for this then I'll close it no problem.
Manu Sporny:  Ok, I'll do that.
Manu Sporny:  Ok, that's that one.
Ken Ebert:  If you just said "if present, identifiers..." that
  would cover it for me.
Manu Sporny:  Ok, can you make that comment in there? Because
  that we can argue we always meant that.
Ken Ebert:  Yes.

Topic: Unification of ecosystem Overview and Terminology

Manu Sporny: https://github.com/w3c/vc-data-model/pull/508
Brent Zundel is scribing.
Manu Sporny:  We can merge that one in now that the conflict have
  been merged.

Topic: Any Concerns around how CR Process is being run

Manu Sporny:  You'll notice, each of our WG calls is pretty
  regimented.
Fairly regimented thing. Issue, PR, no discussion, object or not,
  move on.
  ... that was a bit of an issue yesterday.
  ... Is there any other way we could run it and still make
  progress?
  ... without making people feel we are ramming the spec through.
Ken Ebert:  Taking critical issues offline is good. allows us to
  handle more things in main call.
Manu Sporny:  That is the design of how this group handles CR
David Chadwick:  Is jricher still here?
  ... I have a question for you. The proof for the JWT encoding
  removes the proof section, how do you feel about that?
Justin Richer:  The proof itself will always be in the data
  model, but it may not always be in the data object.
  ... for example, you get a JWT, you do all the transformations
  needed, get into the abstract data model.
  ... get to the proof section, that is the JWT as a whole.
  ... this doesn't map to serialization very nicely, but it
  works.
  ... with the conceptual notion of what JOSE objects are.
  ... this is very unlike the VC data model.
  ... the proofs and signatures at a similarly deep level as the
  rest of the data is not in line conceptually with JWTs.
David Chadwick:  So the proof section could say "proof type:
  external JWT"
And the proof section would have the full complete JWT
Justin Richer:  If you think of this as a serialized document, it
  feels strange and overly redundant to do that.
  ... from the developer's perspective, this is no big deal.
  parsing the object and including the original string is standard.
  ... are you saying we need to add text that makes clear how
  this works?
Manu Sporny:  It can be argued both ways. Not sure if you're
  aware of the work. we started that way, then there was a whole
  bunch of discussion that started much like the discussion just
  did.
  ... we could add informative text about this.
  ... jricher, you have said you don't like how JWTs in the spec
  now, but if there was a better way to do this that had wide
  acceptance, it may be worth it to change the whole JWT section.
  ... but uPort and others need to be on board. there needs to be
  alignment.
  ... one option, rip out whole section as its own normative
  spec.
  ... other, make changes in line. and it has to be perfect.
  ... putting that out that as things to think about.
  ... things may be triggered if we go to another CR.
Justin Richer:  What about a JWS based signature section?
Manu Sporny:  That is what RSA2018 does
Justin Richer:  No it doesn't, I'm talking about something else.
  ... RSA2018 is a detached signature that requires a portion of
  the body be formatted and serialized, then signed. you are
  signing the payload, but altering the payload with the signature
  when you're done.
  ... there is a way to use JWS without JWT.
Manu Sporny:  I see what you're saying.
Justin Richer:  Coming at this blind, that's what I would have
  suggested.
  ... moving back to question. look at section 4.7. already says
  the data model allows for an external proof.
  ... as a developer, I would already be looking at  two ways to
  store this. Normatively we're fine. could it be worded better,
  sure.
  ... it would be a good idea to have a non-normative example of
  a JWS-based proofing mechanism alongside what is now example 9 in
  4.7
  ... have two examples in there, along with all of the
  informative text around RSA2018.
  ... to show a developer reading this what an external proof
  looks like.
  ... they'll know they need two slots to hold this stuff.
Manu Sporny:  That would be non-normative, we could add that.
David Chadwick:  I would appreciate that.
Manu Sporny:  Counter argument would be we already do this in the
  JWT section.
Justin Richer:  But nothing is in the proof section that gives
  any example of what an external proof even looks like.
  ... how do we represent the proof as a part of the data model.
  ... This doesn't need to be normative
  ... example 9.1 would have a fully formed JWT next to all of
  the content. I would have to sit down to write it.
Manu Sporny:  That sounds like a great PR, if you have time.
Justin Richer:  Unfortunately I don't really, if there is any one
  else who can take it.
Manu Sporny:  Just a bunch of base64?
Justin Richer:  That would be fine.
Manu Sporny:  Example 28 is pretty much what we're talking about.
Justin Richer:  Except we don't care about the higlighted gree
  section. Take example 30, but take example 28 (the whole JWT) as
  the proof.
  ... nevermind, I want the transformed payload and the JWT that
  formed it.
  ... I want example9, then example 9 as a JWT, shown as the
  proof payload of it.
Manu Sporny:  I could have time to do that.
Justin Richer:  I probably will not, but can review
David Chadwick: This example will be very helpful thanks
Manu Sporny:  Anything else?
Justin Richer:  Should we record an issue to augment examples to
  say how signatures are calculated?
Manu Sporny:  It is done, but not in the section you're looking
  for
Justin Richer:  You also don't reference with links
Manu Sporny:  In section 4.7?
Justin Richer:  That makes the most sense.
  ... lifecycle examples are the ones I'm most concerned with.
S/links/links to RSA2018, JWS, etc
Manu Sporny:  3.4 Ans 4.7 and anywhere else a full proof is
  defined and understanding it is vital to understanding the
  section.
Justin Richer:  A note for everyone. your average developer only
  looks at the examples and tries to make that work.
  ... we need references in the section.
Manu Sporny:  Anything else?
Nope
Manu Sporny:  Thanks, I think we're aligned.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Wednesday, 10 April 2019 18:48:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 April 2019 18:48:53 UTC