Agenda review, Introductions, Re-introductions

<inserted> scribenick: allen_

Burn: take a look at unassigned issues
... assign them
... look at blockers
... terms of use
... questions about agenda

Unassigned Issues

Burn: links correct

<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee

Burn: unassigned issuess
... looks funny being the same
... number 275
... just ame in
... takes answer more than discussion

Dave: will take

<cwebber2> I think that last one is a ld-sigs/proofs thing rather than a vc thing

<cwebber2> unless I'm misreading

Burn: number 269 may not need someone to take will assign matt who will not object

<Zakim> manu, you wanted to close - it's a graph.

Burn: number 260 is a vc tree or a graph need some one to take David or Dave

Manu: it's a graph that's the data model
... will not come to any thing other than it's a graph

Burn: okay then will assign manu to close with graph answer notwithstanding discussion

<DavidC> I am saying nothing!

Burn: number 253 this is not a blocker

<DavidC> Although the graph part of subject/claim has already been removed

Burn: not anything at all will let go for now down at the end of our discussions moving on
... number 252 there3's a lot of conversation happening with some agreement
... who will take it

DavidC: what to do

Burn: like any issue help it to conclude and supply status

DavidC: will take

Burn: saw that it may be done

DavidC: says there's some disagreement

Burn: assign DavidC
... number 247 mandatory or optional -- have some to dos
... some work needed
... just looking at TPAC outpu

Joe: use case team looking at requirements in data model looking at input from test suite

Burn: that's good will not drop check boxes at end
... assigned to Joe

GitHub Project Review blockers

<burn> https://github.com/w3c/vc-data-model/projects/1

Burn: sos only defers non spec important let's move on to get hub project review blockers links for this and the next are the sme
... if you look at this projectbunc of columns will talk about it later will talk from memory

<TallTed> https://github.com/w3c/vc-data-model/projects/1?card_filter_query=label%3Areview-blocker

Burn: the review blocker want to talk about is
... aske fro feed back and got it from PNG
... must have formal reviews done before requesting CR
... must do if we made the request expect no reprises from formal reviews must address informal comments
... must consider the document complete all inputs accounted for may still be changes but not substantitive
... can't ask for formal review without all pieces in place
... have review blocker items higher priority than CR blockers
... can request pre CR review while working on CR blblockers
... first is number 234 because it's an external comment must address it
... asks that people look that issues in PRS
... if there are issues mark them Manu in particular
... still not loading on screen

Tzviya: which reviews has done reviews

Burn: not done formally continues to expect

Tzviya: need Internationalization, PING

Burn: need ODRL does not believe TAG review done
... if anyone is aware of others still take a look
... switch to looking at issues and PRS then move to CR blockers and PR issues
... if not announced presence, please do so
... have not rescanned
... lets look at number 234
... interesting because issue we have refers to ODRL repo issue
... that's where comment lives skipping 1st part which is our request, perhaps things we can do and updates
... commenter added to our repo and closed

Manu: mostly editorial, should be no issue in closing

burn done, looks editorial but needs to be done

Manu: need pr

Burn: correct moving fro triage to needs pr
... volunteer? David c has comment

<manu> I'll volunteer if I get to it first, others are welcome to give it a shot.

DavidC: terms of use can move from vc out to context, if so proposed edit will take over. have discussion about terms use before edit

Burn: understand suggest but woes like to get review comments done
... if could get done would be great even though irrelevant later doesn't want terms of use discussion to be blocking

DavidC: just editorial bigger issue is how to handle at all

Burn: assign self to creating pr
... chasing the assignee to me {burn}
... now look at amp and jet functionality not described in do getting them in in some form is valuable because can review let's see what status is for 237 and 244

Brent: can speak to 237 265 was naive attempt trying to figure out how to do more appropriately
... if cant'd do will conclude that ZKPs cannot be supported in JSON-LD in this spec

<Zakim> manu, you wanted to note "JSON-LD doesn't work for ZKPs" -- let us know if we can help.

Ken: heart surgery not brain surgery to wedge in top priority is to fit it in not JSON LD experts so struggling

<brentz> +1 to getting help from Manu et al.

Manu: happy to help but need to understand problem seemed addressable but don't have details have another call to resolve

Ken: a couple of days from resolution will need help then to guide to better landing

Benjamin: happy to help as chair of JSON-LD working group

<Zakim> burn, you wanted to mention scheduling other calls

Burn: hope doesn't require new JSON-LD
... possible to schedule additional calls team contact can do chairs supportive if helps lets do it let's schedule as needed
... if can get topics in in will not request cr status ask on this call or email matt
... brent and ken sounds like there are offers what would be helpful

Brent: feu more days will help to formuquestions

Burn: wil you have next week

Brent: hopeful before thanksgiving

Ken: agrees

Burn: the other

Oliver: can address

<burn> This is Issue 266

Burn: do so

Oliver: comments by manu and dave solvable and addressable will answer before committing pr still struggling with zk support leavout jus and jet set up call on support zip and jwt
... ok thing call might be helpful comments?
... no other comments sounds like way to go asks oliver to send email to burn and matt to schedule call will send out request to list

Oliver: thanks

Burn: ok asks if 224 was including in ken or brent discussion or just be cause of terms of use

Brent: latter but other things to do first
... concered bout terms of use but does not know how to resolve

Burn: thanks

Ken: must solve 237 else 244 is irrelevant

Burn: any other review blockers

DavidC: terms of use independent of zip is easier to resolve (ZKP)

GitHub Project CR blockers

Burn: nothing to add was useful info one on to other cr blockers objections"

<TallTed> https://github.com/w3c/vc-data-model/projects/1?card_filter_query=label%3Acr-blocker

Burn: will look at cards on the left skip terms of use for now because it's a large topic look at smaller things first 241
... any comments?
... assign to manu update?

Manu: things to do doesn't need triage already done just action actions

Burn: doesn't like needs triage
... beginning s of implementation items terms leading to zip net yet present on hod for now didn't want to make suggestions before zip worked through
... moving to needs pr agrees that depends on other pieces
... 252 does not like "project thing" two step process david agreed to take 252 agrees with dlonlgey disagrees with joe what;'s needed

DavidC: can he an joe reach agreement used said verifier needs to know what it can accept verifier can't know this from credential only know way of knowing who presenter is need second vc in presentation if not there illegitimate

Burn: let joe respond then get to manu

Joe: another issue want to address thought there was consensus david identified differences does not think verifier needs to know

<cwebber2> I thought we came to consensus about this at TPAC

<manu> VCs are not about authorization

<cwebber2> like

<cwebber2> I thought there was a resolution

Joe: are vis about authorization if so how not intended for authorization davids disagrees other feedback would be helpful

Burn: do quick check now discussion here christopher?

<TallTed> straw poll! (this also spins again into model vs protocol.)

ChrisW: with joe and manu authorization out of scope auth protocols will use vis but separate process add to what issue?

Burn: on 252 put comments there

<JoeAndrieu> https://github.com/w3c/vc-data-model/commit/b4be87948040c784a678cd16c4835e14dd9259be#commitcomment-31277508

<Zakim> manu, you wanted to ask if we can prioritize two CR-blockers that we might be able to close.

Burn: will let manu go next

<cwebber2> we did discuss this at TPAC, yeah

<JoeAndrieu> I'm not sure if that's a PR or what... but that's where David & I have had a bunch of discussion

<cwebber2> <cwebber2> Say VC core spec is not an authorization framework on its own? https://www.w3.org/2018/10/25-26-vcwg-minutes.html

<cwebber2> and yes

Manu: wants to talk about 2 other cr blockers can close out straw poll with authorization thing?

<cwebber2> we did the poll

<cwebber2> and we resolved it

<cwebber2> they are not an authorization framework

<cwebber2> we did this

<cwebber2> minutes are above :P

Burn: lets' do it thought we came to conclusion at tpac
... how to ask the question envois about asking on the spur of the moment framing the question fors

anser

<Zakim> manu, you wanted to say we're not ready to ask the question... I can try to fill somethin gin.

Burn: supported effects answer ask the someone propose question to be asked on mailing list or at next call

<cwebber2> right, they *can be* used in it

Manu: will take action vis can be used in auth framework sees disconnect and will try to rid and come to conclusion

Burn: believes manu correct, helpful for manu to undertake

manu he will do

<TallTed> +1

Burn: wants to get right info

<manu> https://github.com/w3c/vc-data-model/pull/214

Manu: have 2 cr blockers which can resolve

<manu> https://github.com/w3c/vc-data-model/issues/207

<manu> https://github.com/w3c/vc-data-model/issues/207#issuecomment-437996604

Manu: points to 214 saving til end other has to has to renaming claim to subject putting into arcs comment at bottom lots of debate changing position
... criticism is that the only attribute whose id is not the top the object rather than subject as argued by David C

<ChristopherA> I prefer credentialSubject.

Manu: claim was a graph thing removing that aspect then subject/object stops being a problem if rename claim to subbed problem goes away is thereobjecttion to change

Burn: make proposal

<manu> PROPOSAL: Change "claim" to either "subject" or "credentialSubject".

<ChristopherA> +1

<manu> +1

<TallTed> +1

Manu: change claim to subject to subject or to credential subject +1/-1 poll

<dlongley> +1

<DavidC> +1

Dave: also removing hidden graph as result of change

Burn: sees no -1s

<JoeAndrieu> +1

<cwebber2> =

<cwebber2> 0

<tzviya> +1

Manu: sees not +1s
... i'll put in pr. objectors can object to pr preference for "credential subject"

<manu> I'll do a PR for "credentialSubject".

Burn: can do another proposal would prefer just pr see if that works

<dlongley> boo for "credentialSubject" because we don't do "credentialIssuer" or "credentialHolder"

<manu> https://github.com/w3c/vc-data-model/pull/214

Manu: that's one the other is verifiable data registry item brent ken manu david discussing closing in on resolution

<ClareNelson> +1

<manu> Verification Material Registry

<manu> Cryptographic Data Registry

<manu> Verification Data Registry

<manu> Cryptographic Material Registry

<manu> Verifiable Data Registry (do we still want to keep this option for the vote?)

Manu: question has to do with with the eco system diagram updates for zips says registry can contain other things registry necks renaming have several options for renaming

<dlongley> and we can also just do "Registries" and talk about different ones in prose.

<JoeAndrieu> +1 for "registries" with explanation / details after

<dlongley> +1

<ChristopherA> please

Manu: just say "registries" detail elsewhere can we just call them "registries" if people don't like can give another name proposal"

Ted: registry is annoying term question of centralization

<ChristopherA> repository?

Manu: some centralized others not
... have one box

Ted: notedtension
... repository better than registry
... repository open registry closed

Burn: out of time

<manu> TallTed, please join that conversation.

ChrisW: uncomfortable with registry

<manu> https://github.com/w3c/vc-data-model/pull/214

Burn: join in conversation one pr (214)
... comment on github

Next call

Burn: chairs ask about call next week unless overwhelming objection

<brentz> +1 to a call

<TallTed> +0 to concall 2018-11-20

<cwebber2> I think I'll be on a plane

<JoeAndrieu> +0

<ken> +1 for call

<tzviya> +1

burn can put comments in irc regarding call

<DavidC> +1 for call

Burn: call over

<burn> -1 for call for me (on vacation and cannot attend)

[adjourned]