<inserted> scribenick: allen_
Burn: take a look at unassigned
issues
... assign them
... look at blockers
... terms of use
... questions about agenda
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
<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)
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
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]