<scribe> scribenick: bigbluehat

<stonematt> agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jul/0003.html

stonematt: we've got 6 items on the agenda today
... anything else that we need to add to those?
... or any we should reorder?

Introductions & Reintroductions

burn: Claire Nelson is joining us for the first time

stonematt: have you had a chance to dive into our content

Claire: I've started, and am exited to be here

stonematt: feel free to reach out to any one of us with questions

<manu> I think this is Claire's affiliation - https://sedicii.com/

<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+no%3Aassignee

clare_nelson: thank you! glad to be here

Action Item Review

<stonematt> https://goo.gl/V4XTBT

stonematt: there's only one there
... manu had a task to cover

manu: so I did respond to it in the issue
... now I'm not so sure we should add anything to the spec
... it really seems like there's a thousand ways to attach things
... and I'm not sure the spec should single out any one of them
... what would help is someone else taking a look at this and following it up with their thoughts
... I did reach out to one person and am awaiting their feedback

stonematt: I'm going to remove it then from our running action items
... but we can continue to discuss this on github
... do you recall the issue #?

manu: let me find it

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

stonematt: I don't think we need to go into it more today
... but I did want this part in the minutes for posterity

burn: actually, just a second
... we have Bob on the line?

stonematt: could you say a bit about yourself Bob

bburke: I've been watching this group for awhile and reached out to manu recently
... we're interested in digital offers on the Web

stonematt: you said you're CTO of Koupon Media?

bburke: yes.

stonematt: welcome to the group today

<manu> Koupon Media -- http://kouponmedia.com/

unassigned issues

UNKNOWN_SPEAKER: the few that are out there are in the icebox
... so we can move on to the next item

External Review

stonematt: we have a few other items that require reviews from other W3C groups

manu: just as a reminder, we're about half way through our charter
... we're about a year and a few months through
... so at this point, we should start wrapping things up
... no new features, finalizing existing features
... and pursuing horizontal review
... specifically accessibility, internationalization, etc.
... we're required to have these ready for 3 months before CR
... and, given our plans, we're already on that deadline
... some may argue we don't have all the features we need
... but if we delay for that, then we're going to cause problems with our timeline
... and potentially run out of time to issue a candidate recomendation
... we still need to go through all the stages of getting the spec out the door
... all that to say, we need to get the spec out the door for review in the next week or two

burn: are there any objections from anyone for starting this review?
... a document is ready when its ready, but we can't move forward until the group says we're ready

<Zakim> manu, you wanted to note that we could be ready for I18N, A11Y, Privacy... at least.

manu: so. let's say we can get some of these started where I don't think it'll be hard to get positive review comments
... a11y, i18n, privacy, and even security seem like they would go smoothly
... we have good stories in the specs for all of those

<burn> Privacy is the only one I was worred about. The rest are fine.

manu: and I'd propose we at least send them there

<burn> But let's ask

manu: and we may want to discuss security and authentication a bit further
... as well as a few in we mention in the charter
... actually the ones in that list may also be fine
... the Web Payments group may not have too much to say, but bburke is in the group, so perhaps he can say more
... the one we should brace ourselves for are the Web App Security group
... so, to be clear: i18n, a11y, privacy, web payments, credentials CG, and permissions and obligations
... and that gets us 90% of the way there for external reviews

stonematt: so it does feel like we're zeroing in on feature complete
... we've been sort of sitting on the Subject != Holder discussion, but we can get that discussed soon
... are there any objections to this proposal from manu?
... like taking these in two tranches?

tzviya: I have done the a11y review in the past
... and especially in cases like this where there are likely not a11y people already familiar with the spec
... so they might not actually get to it for another month
... but they may ask me to do it
... and you can request that I do it--which would be fine
... so, yes, when you send this on to a11y, feel free to mention that I've been working on it

DavidC: I'm all for feature freeze
... I think that's fine for the first version
... what I'm concerned about is that there are currently
... ambiguities in the spec
... so we should have a spec that is complete and consistent before review
... to avoid confusion

stonematt: just as a follow-up DavidC
... do you think it's a problem to send out to these smaller groups first?

<Zakim> manu, you wanted to say review early and often - noting open issues -- is usually ok.

DavidC: that does seem like a reasonable approach

manu: I do agree with DavidC that we should avoid bad reviews if possible
... and that we should remove ambiguities
... but "early and often" is also a key part of doing this well at the W3C
... and referencing open issues is also fine
... it shows that we've thought about something they might raise as an ambiguity
... so I'd encourage us to get this reviewed "early and often"

clare_nelson: for clarification, the spec mentions a simple scheme for revocation
... so I'd say yes, yes, yes, to that
... I'd be happy to look through that scheme and review it
... I also have a basic functionality question

stonematt: is it really quick?

clare_nelson: the idea of a verifier is a new idea to me
... is there a way to deal with a dishonest verifier?
... or is that out of scope?

DavidC: it might help to think of the verifier as a "relying party"
... and if they're behavior is bad, they're only shooting themselves in the foot

clare_nelson: I'm thinking more of inspector/verifiers colluding
... is that something we care about?

stonematt: I'd like to open that as a separate topic either in a separate call or on the mailing list

<nage> collusion among relying parties is a risk, especially where that collusion creates information leaks for recorrelation (there are strategies in the group to counter these)

stonematt: we're getting into intent and bigger topics that we could all get into and loose track of the meeting today
... I don't think we've had discussions about it yet, so I want us to discuss it
... but we're short on time today

TallTed: it'd be great if we could flag issues within the document and point to our discussion issues

<tzviya> +1 to TallTed

TallTed: so it's clear from the spec that there are issues that we know about

<DavidC> +1 TallTed

stonematt: so this would be a request to reference issues from the spec to the issue tracker

manu: I can take that on
... I'll do that as an editorial pass
... to avoid a PR back-and-forth about it

<stonematt> ACTION: manu to do an editorial pass to reference open issues in spec text

burn: yes, you can have editorial license to include those references.

stonematt: that would definitely help the review process. thank you TallTed
... any objections?

<cwebber2> +1 to sending to those groups for review

stonematt: are there any objections to the earlier proposal to sending our spec for external review
... first to that smaller group

<manu> +1 to sending to the groups for review

stonematt: and then later to the remaining "10%"?

+1 to early and often

<cwebber2> security may be more tricky as things change

manu: there are really only two groups we'd want to wait on Web App Security and Web Security IG

stonematt: maybe there's a way to use GitHub projects or something to track the status of these

tzviya: the POE group formerly closed
... so I'm not sure who you'd contact from that group
... it's formally closed as of April

manu: we may just want to reach out to Renato from that group
... in case the Director has a question related to that group's work
... and that way we can be prepared there

RESOLUTION: send Data Model spec to first set of groups soon, with follow-up to remaining two groups afterward

Data Model PR review

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

stonematt: we have a few that don't yet have discussion
... and some of these are probably close-able now

manu: I can do a quick review of these so folks have a heads up
... there are few that could use further review
... there are a few things DavidC raised around the current spec wrt to JSON vs. JSON-LD processors
... a number of us have been working to unify that processing section
... so that JSON-based processors could handle even extended VCs

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

manu: this PR enforces strict @context ordering
... such that JSON processors could hard code things
... without worrying about a JSON-LD processor would interpret it differently
... we're looking for technical feedback here primarily
... we're wanting JSON and JSON-LD processors to look at the same document and come to the same conclusions

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

manu: moving on to 197
... our specification hasn't talked about conformance criteria
... such as what are the conformance needs and requirements and/or classes
... is it syntactically valid--which is a document level concern
... and is processing conformant--such as enforcing expiration dates, signature checking, etc.
... 197 adds these things

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

manu: DavidC updated his PR 198
... there is still some discussion there
... we may want to take some time for that today--up to you DavidC
... PR 199 was added just this morning

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

manu: it's about attempting to address issue 164

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

manu: it's called time to live on the credential
... I've tried to reformulate it as caching
... and how does an issuer instruct how long to cache, etc.
... PR 199 suggests that we use the HTTP Cache-Control headers and values
... it's well known, battle hardneded
... and this would be far easier than creating something for this ourselves
... so that's a quick overview of the open PRs

stonematt: I have a question about 199 the caching headers
... does that allow for the credential to be shared an reshared or repacked into a new profile or presentation?
... and still retain that kind of lifespan?

manu: short answer is yes

stonematt: I'm all for not reinventing the wheel
... so if this handles the spirit of that requirement, that seems great

DavidC: so, caching is different than something that might be revoked at anytime

<Zakim> burn, you wanted to ask about PR197

DavidC: mostly my concerns are about the validity period

stonematt: one of the discussions that came up with Joe, tzviya, and I while working on the focal use case
... was what's the current status of the credential
... some of that is time-to-live related
... so that they'd have some control over how long that lived in the wide world

<Zakim> manu, you wanted to note that we have a few concepts that are related that we should not conflate.

manu: if we don't have this in 1.0 the whole system will fail
... the issuer should always have the ability to take something back
... as a result the verifier *has* to check that revocation list
... in addition, the issuer may state that the credential may be considered valid for a period of time
... and there is an issue related to how that connects with checking the revocation list
... and it's probably use case centric
... and it comes down to liability
... then there's a third thing--the refresh URL
... if the cache is out of date, you shouldn't cache it any more
... or if it's been revoked, how do I get a new one?
... there are privacy concerns with the verifier being able to reach out and grab something
... so there are a few things we should have some bright lines between
... there is some interaction, but there are also distinctions to be made
... status information for credentials
... guidance, for how this would be handled generally
... and then the refresh URL thing
... the PR addresses all three of those

stonematt: we've made some distinction here already
... and this does not deal with revocation status on its own, correct?

manu: correct. we already deal with that in the spec now

stonematt: are you talking about status? or the cryptographic version of revocation?

manu: well...they're coupled...or can be coupled
... explicitly status, but it does extend to the cryptographic layer because you may have signed that status--although that's not required

stonematt: any other thoughts on this PR?
... PR 199 on caching credentials?

burn: manu I wanted to ask briefly about some of the things that moved here
... did you also change stuff when you moved it?

manu: I believe what I did is move the text up

burn: looks like you made it part of conformance
... oh...wait...no you didn't

manu: let me look at it again

burn: looks like it's definitely moved, though

manu: mainly, I wanted those things talked about in a certain order
... let me look at the diff for a second
... yes. so conformance was added to the "Advanced Concepts" section
... which is a little weird
... usually that's section is higher in the document
... in this version, though, I tried to talk about basic concepts, advanced concepts, and *then* talk about conformance
... such that conformance means you're doing the stuff in sections 5, 6, and 7
... and document conformance means you're doing the stuff in section 8
... things that are syntactically valid, but from a verification standpoint you wouldn't be.
... but now that I say that, I'm not sure it actually accomplishes that...
... do you have a preference with how that's done?

burn: as long as you're defining "conforming processor" and "conforming document"

manu: actually...strike everything I just said...I now remember why
... I tried to put syntactic conformance first--wrt to sections 5, 6, 7
... processor conformance has to do with section 8
... basically, this groups the types of conformance together, rather than mixing them confusingly.

burn: are you hoping to get this merged before we send this out for review?

manu: yes.

burn: k. I'll read through it and give it my review

stonematt: quick time check, we're inside 10 minutes for end of call

Review least recently updated issues; how to jumpstart?

stonematt: issue 198 and 197 have some intertwined content related to subject != to holder, delegation, and profiles

<stonematt> - issue 106: https://github.com/w3c/vc-data-model/issues/106

<stonematt> - pr 198 https://github.com/w3c/vc-data-model/pull/198

<stonematt> - issue re: profiles 107: https://github.com/w3c/vc-data-model/issues/107

stonematt: where do we stand on those topics?

manu: DavidC would you like to sum up what you've done here and then I'll follow-up?

DavidC: mainly, I'd proposed a relationship object
... but that got objected to, so we introduced some properties
... and then you've got the object and can say what the type is
... for instance
... if the subject is a child

<stonematt> chair: Matt_Stone

DavidC: then you can state the relationship with its parent
... when this happens in delegation--like organizational roles
... the example I've got is where a holder who is the subject
... delegates the role he's got to someone else
... manu is still opposed to having delegation within the spec
... manu are there any other things?
... some of these are editorial, highlights, etc.

manu: yes. that's a good summary
... the biggest concern is around delegation of credentials
... it is a use case we need to be aware of
... but I suggest that we discuss it, but not include it in the spec
... because there are ambient authority and things that we'd get dinged on if we attempted this in the spec
... but we should certainly say that we've thought about these things
... without going so far as stating that this is how you do it in a VC
... mainly, we need more people with opinions to help discuss this

DavidC: I'd be opposed to shipping the spec for review without us saying something about it
... anyone can issue each other VCs
... like in X.509 there was nothing to make a distinction between a CA and further issuers
... and we're in a similar situation

stonematt: I think we have to stop because we're at the end of our time

<manu> So, i disagree ... but we're out of time :P

stonematt: but this is a good cliff hanger to end the meeting on
... any parting thoughts?

<manu> the thing that prevents that from happening is the issuer subject identifier...

burn: quick comment for clare_nelson
... there's a queue being managed in IRC
... there's docs for that which we can get you those instructions

clare_nelson: thank you! I'd thought it was via WebEx

tzviya: we should definitely send out IRC instructions. It's very helpful

burn: we'll definitely do that

<stonematt> caio!

stonematt: thanks all. meeting adjourned

<burn> IRC instructions at https://www.w3.org/wiki/IRC

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/stonematt: next topic are unassigned issues/Topic: unassigned issues/
Succeeded: s/..specifically/...specifically/
Succeeded: s/...just as a follow-up DavidC/stonematt: just as a follow-up DavidC/
Succeeded: s/Claire:/clare_nelson:/
Succeeded: s/send to/send Data Model spec to/
Succeeded: s/whell/sheel/
Succeeded: s/sheel/wheel/
Succeeded: s/Joe, Steve, and I/Joe, tzviya, and I/
Succeeded: s/$$$ missed the first one $$$/status information for credentials/
Succeeded: s/childe/child/
Present: Adrian_Gropper Allen_Brown Benjamin_Young Chris_Webber Clare_Nelson Dan_Burnett David_Chadwick Ganesh_Annan Manu_Sporny Matt_Stone Nathan_George Ted_Thibodeau Yancy_Ribbens Tzviya_Siegman Bob_Burke liam
Found ScribeNick: bigbluehat
Inferring Scribes: bigbluehat
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jul/0003.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: manu

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.)