Verifiable Claims Working Group -- 01 Aug 2017

<stonematt> Scribe: dezell

Agenda review, Introductions and Reintroductions

Matt: there's a new structure in pull request #65. We need to discuss.
... also, Manu suggested "milestones for deliverables."

<manu> +1 to the Agenda.

Matt: we also need a new editor use cases.

<ChristopherA> There was also some discussion by Rieks with Manu that though difficult, had some points.

Agenda approved.

<DavidC> yes, but my pw does not work for the webex

Matt: anyone want to introduce themselves?

<DavidC> also I cannot login to the W3C pages

Adam Migus: I'm an enterprise architect, 20 years in security. Verifiable claims came to my attention at a conference where Manu presented.

scribe: I'm involved as a SpecOps standards champion.

Data Model Spec discussion

https://w3c.github.io/vc-data-model/

<dlongley> https://github.com/w3c/vc-data-model/pull/65

<stonematt> pr preview: https://htmlpreview.github.io/?https://github.com/w3c/vc-data-model/blob/msporny-verification/index.html

Manu: The PR is multi-faceted. There is clarifying restruction, came out of discussion of verification/revocation.
... This version should be easier to read. There are now sections of the document that talk about things we've been mulling over.
... we're trying to create a way to introduce new concepts in a more modular way.

<manu> Here's the latest structure of the document in an HTML preview: https://htmlpreview.github.io/?https://github.com/w3c/vc-data-model/blob/msporny-verification/index.html

Manu: look at the table of contents on the left.
... this PR version moves Verification up to the core part of the spec. The core data model section will be revamped (so ignore for now).
... but more basic concepts are now discussed in depth.
... That's followed by advanced concepts.
... Section 6 is "Verification" which outlines all the steps one might do to see if a claim is useful - syntax, information, expiration, non-revoked, etc.
... I hope this will give us concrete sections of the spec we can point to when people want to know how we address certain issues.
... we want to tie concepts to implementation.

<ChristopherA> +1

Burn: I like this in general. I think it will be easier for people. We need some deliniation between normative and non-normative. Granted this can be difficult in a model per se.

Christopher: I see some difficulty understanding between [sections] 6.3 and 6.4.
... Manu had a discussion with someone online. I liked Manu's responses, and I think they help illuminate the difference.

<Zakim> manu, you wanted to note "prefer implementers/readers", normative vs. informative sections and to respond to 6.3 and 6.4

<burn> I actually prefer to help readers rather than implementers, myself

<dlongley> cwebber2... i think that's supposed to mean "If revocation instructions are present, they MUST/SHOULD be followed during verification."

<burn> Favoring users is always better

Manu: Dan noted it might difficult for implementers to understand tradeoffs. There is some question about whether these documents are for implementers or web developers.

<dlongley> that text needs updating (but all of section 6 does, mostly placeholders now)

<cwebber2> dlongley, thanks for the clarification

Manu: W3C documents seem to favor implementers, but I'd say we prefer that the document should be easy to read for a general technical audience.
... I don't know that we'll shove everything into the core datamodel section.

<burn> Manu, this was not a major point. My major point was wrt normative/informatie.

Manu: we have some experience doing it this way with another spec (now in rec) and we'll see how it goes.
... Yes - we'll have normative and informative sections. The basic and advanced concept sections will be normative.

<ChristopherA> Not the entity profile, but how to trust the entity profile

Manu: Christopher asked about 6.3 and 6.4 - entity profiles. Our intent is to define entity profiles in this document.
... Hopefully that will become clearer. I hope the bulleted lists will in time be expanded to be more readable.

<cwebber2> s/Christopher Asked/Christopher Webber asked/

<dlongley> agree that we should focus on semantics, not trust

Christopher A: I'm making a point that there are some requirements hiding in the discussion about entities and entity profiles.

<Zakim> manu, you wanted to agree that "trust in the entity profile" is out of scope.... trust networks are out of scope.

scribe: These issues might belong in other kinds of specs - what are those?

Manu: we don't outline the trust models in detail - that's on purpose since they are out of scope.
... Our work is meant to be "trust model agnostic."

<ChristopherA> But there are some assumptions about those choices here, and I just to be explicit that those choices are made elsewhere.

<TallTed> Kim asks, in webex chat - "Which github issue is Christopher referring to?"

Manu: these concepts are continuing to be explored in the Credentials CG.

<ChristopherA> Issue was from an old version of the spec: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/issues/34#issuecomment-319298392

<trackbot> Sorry, but no Tracker is associated with this channel.

<ChristopherA> of the DID spec.

Matt: seems like there's general positive feedback. From a readability perspective, IMO it's a big improvement.

<ChristopherA> +1 to Joe's comment.

JoeAndrieu: the notion of whether the "holder" is the "subject" and how can we trust that is a key concern.

<ChristopherA> I think there are some assumptions/requirements for other documents here.

JoeAndrieu: we need better language, and I think that topic is requiring more work.

Matt: I suggest we open an issue for that terminology issue.

<Zakim> nage, you wanted to add to the "entity profile" discussion

Nathan: entity profile has a lot of things related to privacy. So there are discussions of both terminology and how an EP is used in practice.

<Zakim> manu, you wanted to ask if we want to merge the PR at this point and iterate on it after that? and to agree with JoeA, it's unresolved, and that was apparent in the DID spec

Manu: Just to underscore - I didn't mean to say EP and Privacy are out of scope. Selecting "One Trust Model" is out of scope per our charter.

<JoeAndrieu> +1 to clarification about trust model, noting that the embedded/assumed trust models need some teasing out, esp wrt entity profiles

Manu: We had a good discussion last week, and it was obvious that we are still not totally aligned on terminology.

<ChristopherA> I'm not yet hearing that even if we don't choose a trust model, there are some requirements that a trust model must specify, and that list we may want to include.

<JoeAndrieu> +1 PR65 looks like a good improvement

Manu: But I think that's a >different< discussion than PR 65.

<cwebber2> +1 to PR 65

<stonematt> +1 to merge PR65

<nage> +1 on PR65

<dlongley> +1

Manu: I need to ask if it's OK to merge PR65.

<burn> +1

<TallTed> +1

<amigus> +1

<ChristopherA> +1

Matt: hearing no objections. So we can close this topic and move to the next one. Merge is approved.

Milestones for next deliverables

<ChristopherA> I'm needing more examples, and if the spec changes, the examples are changed.

Matt: I'd like to start the discussion to get feedback on what deliverable milestones might be, with an eye to creating implementation milestones.

Christopher A: trying to use examples in the document was harder than I thought.

scribe: I'm not saying the examples should be change (they are illustrative) but we need to be sure we have covered all the subtleties.
... we need more detailed examples. And we need to track that when the spec changes the examples change.

<ChristopherA> Linked Data has subtleties

Burn: Understood desire to make examples match. Please feel free to create a PR to address any issues you see, or ask. Feel empowered.

<Zakim> manu, you wanted to mention that this is what milestone 1 should deal w/ and setup - a test suite w/ examples.

<ChristopherA> +1 on test suite

Manu: I agree with Christopher A. Minimal Viable Implementations are the way to go - a test suite with examples will help.

s/Liable/Viable/

scribe: Milestone 1 - demonstration signature issue and revocation.
... once we have that, we can grow the examples in the test suite in the direction we want.
... we should have tests and source documents, and expand dynamically when people pose questions.

<stonematt> +1 to milestone 1 be Minimum Viable Implementation that is scoped to Issue & Sign (not Expire and Revoke)

<burn> +1 to starting test suite. Will need that to finish CR eventually anyway.

scribe: Milestone 1 - a one month effort to create the above minimal viable implementation.

Matt: sounds like the minimal implementation is "issue signature", milestone 2 is "expiration revocation", and we can decide Milestone 3 later.

Manu: normally materials are kept in a project in GitHub. Create a "milestone 1" and describe it.
... if the group agrees we can move ahead.

<ChristopherA> no objections

Matt: people OK with these first two milestones?

<JoeAndrieu> +1

<dlongley> +1 to first two milestones

<colleen> +1

<cwebber2> +1

<amigus> +1

<manu> +1 to milestone 1 - check issuer/syntax/signature... milestone 2 - revocation, etc.

<ChristopherA> +1

Editor for Use Cases

<scribe> ACTION: manu to describe the first two milestones (issue/signature) and (expiration revocation) in GitHub. [recorded in http://www.w3.org/2017/08/01-vcwg-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

Joe: I can take responsibility for this role and pose changes through an issue.

<Zakim> JoeAndrieu, you wanted to discuss Editor for Use Cases

Matt: Thanks Joe.

<Zakim> manu, you wanted to wonder if we want to cut down too much on use cases?

Manu: My question - I know we have a narrow charter, so I'm wondering how we focus the use cases without losing "out of scope" use cases.

<dlongley> +1 for a non-normative "Future Considerations" section

Manu: We want a way to express our future vision.

<dlongley> other specs have that.

<TallTed> +1 retain "VC UCs out of scope for this WG" labeled as such

<manu> +1 to what JoeA just said.

JoeAndrieu: So that's one organizing (in/out of scope) principle, but I have others. I'll include it in my recommendation.

Next Week's Agenda

Matt: what should we address.

Burn: no item to propose, but once the milestones are created, people in this group must evaluate Milestone 1 >very carefully<.

<DavidC> I have an issue for next week, when I hope to be able to join via Webex

<dlongley> DavidC: go ahead and type your issue in there now

<Zakim> manu, you wanted to ask "data model discussion" on next weeks agenda.... specifically, entity profile discussion.

<DavidC> On the CC group we discussed group attributes, and having a single attribute in each claim, and claims linked via a group ID

<burn> I also said that people need to make sure their milestone 1 issues are entered into GitHub

manu: I think we should discuss entity profile and review the datamodel.

Matt: thanks for the discussion. Nice progress.

Adjourned.

<stonematt> bye all

<ChristopherA> Ciao!!

- DRAFT -

Verifiable Claims Working Group

01 Aug 2017

Attendees

Contents

Agenda review, Introductions and Reintroductions

Data Model Spec discussion

Milestones for next deliverables

Editor for Use Cases

Next Week's Agenda

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output