<manu> scribe: Manu_Sporny

<manu> scribe: manu

<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2017Dec/0002.html

Agenda Review, Introductions

stonematt: anyone new?

No one new...

Potential Spring Face-to-Face

<stonematt> https://docs.google.com/spreadsheets/d/19Ndqc5pLsTu2ZmP4Wy7OlMOmskQFHPh28sMjW3ugsww/edit#gid=0

stonematt: When should we meet? What events are coming up that we can piggy-back on?

<ChristopherA> Next #RebootingWebOfTrust probably March 6th in Santa Barbara

<ChristopherA> Many identity events in spring

Varn: I can host this at ETS - Princeton, NJ
... I'm happy to do that - hotel/travel is the only cost... ETS would pick up the rest.

<gkellogg> Next IIW is 4/3-5

Group filling in potential meeting locations.

<tzviya> may 13 - 15 AC meeting berlin

stonematt: Ok, we have suggestions - any objections to moving on?

W3C TPAC 2017 Action Item Status Check

<stonematt> https://www.w3.org/2017/11/28-vcwg-minutes.html

https://www.w3.org/2017/11/28-vcwg-minutes.html#ActionSummary

stonematt: There are a couple of items for Chairs and Editors here... so, couple of items that we were trying to get closure on.

<cwebber2> manu: initial revocation text... there is a PR related to this

manu: Regarding - chairs to find volunteer to draft initial revocation text -- https://github.com/w3c/vc-data-model/pull/99
... Web-based status checking method is here -- https://w3c-ccg.github.io/vc-status-registry/
... Status checking registry is here -- https://w3c-ccg.github.io/vc-status-registry/
... Web-based status checking method is here -- https://w3c-ccg.github.io/vc-csl2017/

<cwebber2> manu: there's a PR to reword revocation as status checking, that text now exists in the spec. There's also a status registry, so a status checking algorithms... the status checking method is here... the status checking registry is here... the web based method was published here.... there's a PR ready to go that does ??? ... there's only code samples not spec text there, whatever you and ChristopherA decide to do should take that into

<cwebber2> consideration

manu: Please take that into consideration when drafting new text
... re: Editors to change "Verifiable Claim" to just "Verifiable Credential" -- these changes went in last week.

<cwebber2> manu: spec updated to refer to verifiable claims entirely to verifiable credentials, we just talk about claims. there will be some updates to the privacy section

manu: re: create PR to correct the use of "credential" v "verifiable credential" to be rigorous -- I made those changes

<cwebber2> manu: next action item is create PR to be credentials vs verifiable credentials to be more rigorous

manu: re: Nathan to contact Manu and DaveL about how to do content addressed JSON-LD contexts -- we discussed lightly over email

<cwebber2> manu: this is a more general json-ld discussion, there are multiple proposals

<cwebber2> manu: the discussion is ongoing, I don't think there's any finality to the discussion, but I think nothing is blocked by that. I think effectively those are done modulo some tweaks here and there... they're minor changes at this point

<cwebber2> manu: that's I think where we are on status

<cwebber2> stonematt: are these PRs ready to be ready to be pulled in?

<cwebber2> manu: verifiable claims to credentials is ready, revocation with status checking pushing to merge in today, executing something at TPAC

<cwebber2> manu: and vocabulary files

Review of Pull Requests

<cwebber2> stonematt: if we finished action items, that's the next item on the agenda, a review of PRs

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

<cwebber2> stonematt: let's close on action items unless there's more questions on Manu's update

<cwebber2> stonematt: if not, let's talk about pull requests pending

manu: Initial commit of vocabulary files -- https://github.com/w3c/vc-data-model/pull/96

<cwebber2> manu: so both of these PRs have to do with I believe consensus of the group at TPAC, first one is initial commit of vocab files

<cwebber2> manu: and that's dave longley myself and greg have reviewed it, some minor nits here and there, but I think greg has mostly already dealt with them... this gives us a json-ld context to deal with along with human readable files... this is great, thank you gkellogg

<cwebber2> manu: I think we should pull it in as soon as possible... unless objections, we'll pull it in after the call

<cwebber2> gkellogg: should we do a proposal?

PROPOSAL: Pull in PR 96 -- Initial commit of vocabulary files

<cwebber2> +1

<gkellogg> +1

+1

<stonematt> +1

<tzviya> +1

<dlongley> +1

<bigbluehat> +1

RESOLUTION: Pull in PR 96 -- Initial commit of vocabulary files

<cwebber2> stonematt: seeing no objections, resolved that

<ChristopherA> +1

<cwebber2> stonematt: just going to confirm Manu, you'll likely push the button and make that happen?

<cwebber2> manu: yes, why not do it right now

<cwebber2> manu: *clicks magic button*

<cwebber2> manu: done, next one is replacing revocation with status checking

manu: Next PR Replac revocation with status checking -- https://github.com/w3c/vc-data-model/pull/99

<cwebber2> manu: this one basically... at w3c TPAC there was a concern that revocation does not cover all use cases, for example credentials can be suspended/revoked... I think that's the spec text that stonematt and ChristopherA are working on... this PR says "here's the placeholder for status holder and credential... but mechanisms we're using will be incubated outside"

<cwebber2> manu: to be specific about proposal, there's normative text in the verifiable credentials check saying "here's how you do status checking", but mechanisms are external

<cwebber2> manu: this enables CCG to manage the registry, and allows us to incubate the status checking methods in the CCG until they hit a point of maturity where we could potentially pull it back int he working group

<cwebber2> manu: the reason we're doing it that way is to avoid creating any blockers for the status checking stuff

<cwebber2> manu: that way we can go forward with a non-normative reference without slowing things down. we expect 2 methods, one is putting a list on a site for some pseudononymnity, and one of them is a blockchain one that Someone (TM) will propose in the future

<cwebber2> manu: spec text is minimal, the other text is whether the CCG will adopt the registry as a work item, and that's up in the air until the CCG meeting in the next 30 mins or so

<dlongley> revocation (crypto) vs repudiation (claim)

<cwebber2> stonematt: clarification to make sure I'm understanding: last week when we were talking about revocation we were talkinga bout two concerns: 1) at the cryptography layer (keys check out, sigs good, etc) and 2) was business interest of status discussion we just had, and ChristopherA sort of described it as revocation vs repudiation... does that align with the way you're thinking here?

<cwebber2> manu: yes it has more to do with repudiation than revocation

<cwebber2> manu: hard to say definitively, because it's kind of amorphous currently, but much more to do with repudiation than cryptographic revocation

<cwebber2> stonematt: ok that's kind of the setup so we can reference an external system so we can manage the business tier... seems like the revocation is more of a first class citizen for us

<cwebber2> manu: wouldn't go that far

<cwebber2> manu: revocation has to do with the Cryptographic Stuff, and that does have to do with our spec, but we do have status checking stuff in the spec

<cwebber2> manu: I'd say status checking is lower level than repudiation

<cwebber2> manu: we talk about both in normative language in the spec

<dlongley> revocation (reject truth of the crypto) vs. repudiation (reject truth of the claim)

<cwebber2> stonematt: that seems right, I'm trying to handle distinction because revocation level is probably more or less universal for this broad universe of this ecosystem whereas the status management / checking and quality/value of a status/credential will be very much more oriented to a particular market segment, may be many different ways to do that depending on who's doing it

<cwebber2> stonematt: I figure there will probably be multiple ways to do things, but the cryptography side won't be

DavidC: The actual content of the claim is outside the group - therefore, whether the claim is still valid or not is out of scope... the credential is OK or not ok...
... The underlying claim is as much out of scope as negative claim, positive claims, etc.

<cwebber2> DavidC: point I wanted to make is we already had a discussion... scope of claim was outside of the group.. we agreed negative claims were positive claims to some others, we weren't going to discuss that, but we would talk about is whether a claim is valid or not... we should be talking about whether credential is valid or not... negative claim whether valid or not is out of scope

ChristopherA: To a certain extent, you could argue that every signature system (although it's a bit higher than signature system) ... could have a different revocation mechanism. In the same way that we have separate documents for signature systems, it may be that we need to think about it at that perspective for the revocation side of this problem. Even with revocation, that there could be a variety of them depending on the systems behind them.

<cwebber2> ChristopherA: to a certain extent you can argue that every signature system (although a bit higher than signature systems) has a different revocation. in the same way that separate documents for signature systems it may be that we need to be thinking about it at that perspective for the revocation side of this problem. Maybe Manu can respond a bit to this, but even with just revocation on the purely crypto side of things there could

<cwebber2> be quite a variety of them, depending on systems behind them

<cwebber2> ChristopherA: that's it

stonematt: Everyone seems to come at "revocation" in a different way - if we can refine to data model, push the rest off to community - the more successful we'll be.

<cwebber2> stonematt: the reason why we're here is I think we should move as much to the CCG as we can because this is somewhat a laden term, so where we can refine it to a simple core, wherever we can push it off the rest to the community, I think the more successful we can be

<cwebber2> manu: I agree with that... I'm mapping what everyone is saying back to the PR. I think the PR is aligned with what people are saying. We don't in the spec currently make a clean line between revocation and repudiation, but we kind of... we probably should. It's probably a separate PR

<cwebber2> manu: this PR was about revocation specifically in the spec but what we were really talking about is repudiation... but we may want to highlight what ChristopherA just said... when we're talking about cryptographic revocation it's dependent on the signature system because CL sigs do it in different ways than RSA sigs, which can themselves even do multiple methods. So we probably need a section for cryptographic revocation, and we

<cwebber2> probably need a section about repudiation which is kind of a status checking thing

<cwebber2> manu: I'm trying to figure out if we should rework the PR there right now or do another thing as a new PR?

<cwebber2> manu: I think I'd rather do what we're discussing today as a new PR, because it requires broader changes to teh specification

<cwebber2> manu: can we pull the status checking thing in right now knowing we need another PR, given we need ??? repudiation, can go into those details

<cwebber2> manu: so the ask to the group is can we pull the PR in today even though imperfect, and I can make another PR next week with a distinction between cryptographic revocation vs repudiation

PROPOSAL: Pull in PR 99 and follow it up with another PR detailing the difference between cryptographic revocation and repudiation in the spec.

<ChristopherA> +1 PR 99, +1 New PR cryptographic revocation

+1

<gkellogg> +1

<stonematt> +1

<cwebber2> +1

<TallTed> +1

<dlongley> +1 but we should address DavidC's concern that repudiation is out of scope

<bigbluehat> +1

<tzviya> +1

<dlongley> (at some point)

<cwebber2> manu: and yes we'll try to put comment that mechanisms for repudiation are out of scope

<DavidC> +1

<cwebber2> manu: I suspect we'll have two concepts, and repudiation section will say hey there are a bunch of business processes and they're out of scope, and point at status checking

RESOLUTION: Pull in PR 99 and follow it up with another PR detailing the difference between cryptographic revocation and repudiation in the spec.

<cwebber2> stonematt: don't see any detractors so I think this is resolved

<cwebber2> manu: I'm merging that in now

<cwebber2> manu: done! we're up to dat

<cwebber2> e

<cwebber2> stonematt: alright, going to next item on our agenda then, there are sort of 3 standing agenda items for each week, the review of privacy issues, an update on current milestones, and test suite progress

Reviews, Milestones, Test Suite

<stonematt> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Aprivacy

<cwebber2> stonematt: to quickly touch on privacy issues review

<cwebber2> stonematt: link to privacy issues here

stonematt: This looks like where we focus on next - review use cases - members should review these open issues.
... We need to decide what we're going to do w/ these items and how to address them.
... unless there are objections, we'll need to get the ball rolling on these issues again.
... We had a discussion about correlation at W3C TPAC 2017...
... What is our current thinking about DO_NOT_CORRELATE?

dlongley: Last I recall - we were thinking of folding DO NOT CORRELATE into terms of use -- that's what I have to add for right now.

<DavidC> +1

stonematt: I remember a similar discussion about that... +1 to that.

<stonematt> +1 to include anti-correlation in terms of use

ChristopherA: There are two different issues in my head about this - there is the case where cryptosystem used, you can't correlate (like CL-signatures)

<dlongley> also note, we have a need for terms of use coming from both the issuer and coming from the holder/presenter.

ChristopherA: You can't correlate w/o consent of other parties. That's a different situation from GDPR answer - throw items away after using it.
... That deems that its business centric - in credential... but cryptographic side of this - which is mathematically enforceable is clearly something we need to cover a little bit to address privacy concerns.

<dlongley> i.e. issuer: "i'm issuing you this credential and expect you to only use it in these ways" and holder: "i'm sharing this credential with you and you may only use it to authenticate me for some purpose, nothing else" (etc.)

dlongley: Regarding terms of use - there are a couple of places we want to talk about terms of use - issuer terms of use... and holder terms of use.
... For example, issuer concerns over bundling.
... holder examples - don't correlate me, don't share my info, etc.

stonematt: Those seem like they're in the business tier...

<ChristopherA> GDPR mandates some of this

dlongley: Our concern is where we put that information in the data model.

<dlongley> in the profile

<dlongley> terms of use in the credential => issuer's terms

<dlongley> terms of use in the profile => holder's terms

DavidC: That's the only thing that goes in credential - issuer puts it in credential... holder ToS goes in something else in protocol. It's not in the data model.

dlongley: Terms of Use in credential is issuer's terms...
... Terms of Use in profile are holder's terms of use...

<DavidC> +1

<stonematt> +1

dlongley: How that protocol works might be something like the Verifier proposing terms of use that the holder would agree to by placing them into profile to submit to the site, holder would digitally sign that information -- expect how my credential will be used by Verifier -- and there is a place for that in our data model.

<cwebber2> manu: this sounds like an advanced feature can be placed in the credential or in the profile, and we should specify we don't say what ToS terms are... that's for lawyers and etc. we should talk to Renato(?)'s group

<cwebber2> stonematt: ODRL? (ORDL?)

<cwebber2> manu: yep

<cwebber2> stonematt: you're going to put a PR for this?

<cwebber2> manu: yep

<cwebber2> stonematt: maybe you can recommend ODRL?

<cwebber2> manu: will put in an issue marker saying we're exploring that direction

<cwebber2> stonematt: great

<cwebber2> stonematt: 5 minute warning, CCG starts soon

stonematt: I'll skip milestone question -- anything about test suite?

<cwebber2> stonematt: skipping milestone question... anything about test suite we should hit?

<cwebber2> manu: so the milestone question is easy, we can close that out

milestone

<cwebber2> manu: test suite point is where we need implementations, as many as possible

<cwebber2> manu: at least the start of them

<stonematt> manu: thinks milestone 1 is complete

<cwebber2> manu: we have a test suite, it has tests in it... first thing we can do is make sure tests pass

Test Suite

<cwebber2> manu: we're at point where we need to call for implementations

<cwebber2> matt_larson: *ack that we're doing something*

MattLarson: Pearson - we're going to do an implementation...

<cwebber2> stonematt: chris webber is resuming python verison... would be nice if we could have two tests...

<cwebber2> manu: test already does that... question isn't who's using it in their company but who's doing a conforming library

<cwebber2> manu: you need to write that yourself to have an independent implementation

<ChristopherA> DID hackathon is 1/15

<cwebber2> manu: digital bazaar has one in javascript, you could argue spec-ops has one in python, and...

<cwebber2> stonematt: pearson has a ruby implementation

<cwebber2> manu: we should put it out more broadly, we could get it done in Go or Java to put an implementation together

<ChristopherA> (Ciao!)

<cwebber2> manu: not a heavy lift, most of the low level libraries are there

manu: We should shoot for top 10 TIOBE index languages...

<cwebber2> stonematt: I think that's an item we'll put on the agenda on the upcoming weeks... progress on implementations will be an item for us

<cwebber2> stonematt: next week we'll formally close out milestone 1 and describe the next milestone

<cwebber2> stonematt: any other business before call end?

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/on my way//
Succeeded: s/Present//
Succeeded: s/Renado/Renato/
Present: Manu_Sporny Tzviya_Siegman Dave_Longley Chris_Webber Gregg_Kellogg Ted_Thibodeau Liam_Quin Matt_stone Benjamin_Young Matt_Larson Richard_Varn Christopher Allen Christopher_Allen colleen_kennedy David_Lehn
Found Scribe: Manu_Sporny
Found Scribe: manu
Inferring ScribeNick: manu
Scribes: Manu_Sporny, manu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Dec/0002.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)