Verifiable Claims Working Group Telecon -- 30 May 2017

<ChristopherA> Good Morning!

<burn> Scribe: amigus

Agenda review and Introductions

cwebber: I am Chris Webber; I joined because of my interest in distributed identity. I'm here with spec ops

Status of publishing UC FPWD

<burn> https://w3c.github.io/vc-use-cases/

cwebber: I'm also involved in Social Web WG but that is not as part of my spec ops affiliation

<ChristopherA> We discussed last week of having 1 person each week being "re-introduced"

burn: editors have beenworking on the document but i'm not sure of that status. Manu?

manu: usecases? greg made the majority of updates

<gkellogg> https://github.com/w3c/vc-use-cases/pull/41

gkellogg: working though it on PR 41; we are going to publish as FPWD but not ready yet
... updated the patent URI. we set the publish date <missed it> we can revisit if required
... we could use the mailing list for continued discussion but there's the issue list in github

burn: anyone have any comments? if none editors and chairs will make decisions because it's all administrative

<liam> how to do a first public working draft (long URL sorry) https://services.w3.org/xslt?xmlfile=https://www.w3.org/2005/08/01-transitions2017.html&xslfile=https://www.w3.org/2005/08/transitions2017.xsl&docstatus=fpwd-wd-tr&echidna=true

gkellogg: I did update the intro to reflect that we're a WG now...

Discuss FPWD for Data Model doc

<manu> no other comments than +1 publish!

liam: chair must send a publish request and request approval for the shortname

gkellogg: yes, got it, only pointing out that it's administrative
... we'll target publishing on Tuesday but it's done when its approved and ready..

<burn> Data model: https://w3c.github.io/vc-data-model/

<ChristopherA> Are you asking for this now?

burn: this is the main topic for today; reminder: if you see a major gap like a section, then now is the time to mention that even if the content will be TBD lets just get the section added

<Zakim> manu, you wanted to mention a few things.

manu: a couple of items in the spec:

<manu> First item - remove WebIDL from spec - https://github.com/w3c/vc-data-model/pull/45

manu: first item: there's a PR for it (above)

<burn> ACTION: chairs to send transition request for FPWD for UC doc when gkellog says doc is ready [recorded in http://www.w3.org/2017/05/30-vcwg-minutes.html#action01]

manu: a little contraversial but want to comment out the WebIDL from the spec because it makes browser integeration murkey.
... <need clarification>

<dlongley> browser tools are designed to work that way -- you need the Web IDL to convert data to/from JS and C++ ... it's not clear that we need or want that kind of rigidity here as its potentially harmful to extensibility

manu: second issue: terminology: we need to clean up, I
... will suggest changes like in a PR
... will try to use the word 'entity' mostly
... we don't talk about the ecosystem; that was on purpose to avoid scope excess but now that things are better defined we might want to add something back.
... reasoning is to make sure others understand what we're trying to accomplish and that web developers understand what we're doing and the context around it. That includes terminology hence the previous
... those are the changes before FPWD; I'll do a PR to get it started.

ChristopherA: I have other items so i'll wait

burn: quesiton for manu: do you want to make some decision today or is this just discussion at this point?

manu: discussion and thoughts from the group is what we want today

<JoeAndrieu> +1 remove web_idl

manu: first remove webidl, second remove the contentious word 'identity' and use 'entity' instead; third is (see above)

joeAndrieu: how do we replace identity with entity? seems like different things...

<Zakim> manu, you wanted to respond to joe and the avoiding bikeshedding comment.

manu: the terminology discussion probably is best done offline so that we don't eat all the time in the meeting. we'll set something up
... really just want a feel what the group things WRT direction
... to address the bikeshedding potential: chairs please call us on bikeshedding when you see it

gkellogg: there are other specs that use WebIDL without the assumption that it integrates with browsers in a particular way so I don't know if I agree with removing it on that basis because this isn't the only spec that does it (without making the assumption)

dlongley: we can obviously use WebIDL but we don't really *need* to use it so its easy to stay away from

<gkellogg> +1 to what dlongley said.

dlongley: we're not defining an interface that one should use a WebIDL for, so we don't need it -- we're jumping the gun including it

<Zakim> manu, you wanted to respond to burn - yes, we want to do that, WebIDL is a very verbose way of doing that.

burn: manu question: I don't mind us removing any particular syntax or defn language but my concern is that we are still able to be clear about defining the data model and ways that it can be used. people assume we're using JSON-LD only and we want to make it clear that it's not just that...

<dlongley> +1 that we want to have multiple syntaxes as examples, -1 to Web IDL as one of those unless really necessary

manu: you're right; people think it's JSON-LD only. Maybe we should remove JSON-LD to and just go with JSON
... we've opened ourselve up to misinterpretation as a semantic web thing.
... we could do it will basic examples; it's a lot less verbose than WebIDL

<burn> agree that WebIDL definitions are crazy verbose

manu: this might make it look simpler
... we could externalize the WebIDL defn

<dlongley> also -- if you can express something as JSON, you can define Web IDL for it

<burn> dlongley, I know that and you know that, but that wasn't the concern I raised

manu: education like JSON but ecomm/retail and finance use XML..

<cwebber2> what about presenting as "just json" but saying in some note that this can be read as json-ld with an implied context?

manu: so we could show JSON, JSON-LD and XML too so that everyone sees it in their preferred format

gkellogg: we are supposed to create a vocabulary so that we aren't building things that aren't local; JSON-LD gives us a solution for that and JSON doesn't.
... I don't want to lose the ability to do localization right in the name of simplicity
... XML does allow us to tie terms back to vocab by using namespaces but it does support it.

<Zakim> ChristopherA, you wanted to comment on this topic, re: kinds of examples

burn: admin interupt: there are no issues to discuss in the next item so it was just discussion and we're basically having that discussion now.

ChristopherA: I agree with gkellogg. I want to point out to the community that, using schemas, we can have a vocabulary that results in everything being canonical regardless of format. There are other things (OWL?) that supports schema. We could point out that we don't have schema when we use JSON.

<dlongley> +1 to telling that story

ChristopherA: when we define things that are outside of the schema then it doesn't matter what your encapsulation is

ChrisWebber: we dealt with this previously and came up with a solution which is to use profiles
... people who are averse to JSON-LD we could use an 'implied context' by using a profile type contstruct..

<Zakim> manu, you wanted to point out the JSONFeed discussion and how it relates to uptake.

manu: +1 to that

<manu> https://github.com/brentsimmons/JSONFeed/issues/49#issuecomment-303499812

manu: it worked in the social web group so we should explore that

<ChristopherA> (I'd like to be in queue when new topics are started)

<ChristopherA> We may be even able to get IPLD be the same canonically, which is a format that may have a lot of legs.

manu: i want to highlight a new data format called ???; JSON-LD has gotten pushback from the larger community. I'm pointing that out because it will repeat and we have to be careful about how we respond. we can't say 'don't use JSON-LD' but i don't have a crisp answer for how we should respond
... so we just need to be careful (in the spec) about how we approach it and cwebber's suggestion seems right

<ChristopherA> I'd prefer to see 3 examples with each, with XML, JSON-LD, and JSON.

burn: any other questions before we go back to the broader 'gap' question

ChristopherA: there was a work item that came up in the CG.

<ChristopherA> https://docs.google.com/document/d/1W0r6TOaJXGcDP4qOzOIEfSymub4nRSLrBmtBqyDf06I/edit?usp=sharing

<ChristopherA> https://bitsonblocks.net/2017/05/17/a-gentle-introduction-to-self-sovereign-identity/

ChristopherA: it was an issue WRT other parties that are thinking about claims outside of this group; they seem to have 3 categories when they talk of it:
... R3 is a consortium that's doing something with claims and proofs which are attestations of the claims but they have attestations separate from that.
... seems like they want 1) claim, 2) proof (by others) of claim and 3) ability to refute a claim
... some say that the way we're doing it does already support this but it's not clear to me that it's the case

<dlongley> +1 it would be a good idea to say how each of those concepts map to verifiable claims

<dlongley> in the spec

ChristopherA: especially when discussing reputation based systems

<Zakim> JoeAndrieu, you wanted to talk about missing sections (not serialization) and to

JoeAndrieu: regarding elements and context: we don't have something for presentation of claims i.e. it's issued then presented to an inspector. we don't have something that shows the relationship especially when dealing with multiple claims and disclosure
... we also need a notion of scope-of-use
... i think both are key to addressing privacy

<JoeAndrieu> will do Manu

<Zakim> manu, you wanted to ask Joe to raise an issue on the spec for that. and to ask ChristopherA to raise an issue.

burn: FYI we need to have even empty sections so people can see what's coming...

manu: just want to make sure that ChristopherA and JoeAndrieu's comments are added to the Github issue tracker; can you guys add them?

Review of issues for Datamodel Document

<burn> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

<ChristopherA> (another example of the 3 in addition to R3s: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/final-documents/reputation-toolkit.pdf Assertion Evidence Evaluation)

burn: any comments from anyone?
... anything else from you manu?

manu: not yet, just the 3 items discussed earlier however, both ChristopherA's and JoeAndrieu's comments aren't addressed and should be
... actually one other item: we're doing a talk to the US Federal Reserve Secure Payments Task Force next week I'd like to give folks a heads up that we're doing that

pull request 38

<burn> https://github.com/w3c/vc-data-model/pull/38

burn: JoeAndrieu and amigus submitted comments, we're working through them. Ask that others review and comment.

manu: i've been asked to come talk to the US Federal Reserve Secure Payments Task Force to talk about our work in Charlotte, NC. they launched a task force to make faster payments happen and keeps pace with the rest of the world also better identification for fraud reduction. they're interested in VC, WP and related
... please take a look at what I've done and contact me (don't leave comments in the doc)
... it's a BD, is a 75 minute, keynote with over 100 folks in banking/finance

suggestions for next week

<manu> Suggestion: Cover PRs that I will hopefully get to today/tomorrow.

burn: ChristopherA brought up introductions and re-introductions which we'll start on next week
... manu: getting the docs published is top priority; we had a poll in the CG before the WG started so we already have a list of priorities for discussion to start from

<ChristopherA> I have posted issue: https://github.com/w3c/vc-data-model/issues/47

- DRAFT -

Verifiable Claims Working Group Telecon

30 May 2017

Attendees

Contents

Agenda review and Introductions

Status of publishing UC FPWD

Discuss FPWD for Data Model doc

Review of issues for Datamodel Document

pull request 38

suggestions for next week

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output