<scribe> scribenick: cwebber2

Agenda review, Introductions, Re-introductions

burn: we need to decide what we're doing re: ToU
... I adjusted the conversation list so we're making ToU the primary topic
... assuming we have time left we'll do CR and PR blockers
... but we always do with introductions of anyone new and agenda review
... looks like nobody new

dmitriz: I think rhiaro is just joining us now

burn: don't see rhiaro on the phone

dmitriz: ah, they might just be reading the transcript

<rhiaro> o/ hey, I'm not dialling in cos I'm not technically a member of the WG yet, but lurking

burn: they're with DB?

dmitriz: yes

manu: just to be clear, Amy Guy (rhiaro) is going to be helping us with hanging spec editing so we're pulling her in so we can get to CR faster
... but more than likely it won't be a ton, she's mostly joining us to work on DID style stuff

Unassigned Issues

burn: ok! welcome

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

burn: I'm going to hit the top 3 unless something new showed up
... 294 is new, going to be part of what we discuss today
... this came out of the ToU discussion but DavidC believes there's a more general conformance issue which may or may not be the case
... at this point I'd like someone to take the issue so we can get it to conclusion

DavidC: I'm not doing it because I think it should be (other than???) who wrote it

manu: I responded to the issue, I'm on the fence, I think I'd like to see it closed without action because it's asserting what conformance is, I think there's no disagreement there, it's more about whether or not there's a conformance clause
... don't think it's actionable until we have "conformant implementation MUST do X or Y", think it's more language around conformance

burn: there's a real discussion around conformance language, but I agree that's not what this is about

manu: DavidC, do you object to closing this issue, and then focusing on conformance language?

DavidC: the reason I opened it was because the comments joe were making were in direct opposition, thus we need to agree on MUST and MAY and etc

burn: I'm going to take this one. I'll assign it to me.

<Zakim> TallTed, you wanted to say once more, we're beyond model and into protocol/activity

TallTed: surprise surprise, I'm saying the same thing again, most of the issues about that issue and Terms of Use are about a protocol. If we're building a protocol, we need to start from 0 because we aren't doing it right. If we're doing a data model, we should focus on what data needs to be there so we can make sure it comes up later

burn: we're trying to assign it

TallTed: even assigning it is a problem, I'm frustrated because even assigning it is making it in protocol scope

burn: that's why I took it, so we can get to the real discussion topic of today where your comment is appropriate

TallTed: fair enough

burn: 292 I think there's a mistake
... manu, I think you should take this because the poll will result in something and that's what I'll use
... 276 I'm nervous to raise

JoeAndrieu: We already dealt with this

burn: manu took it, we're done

TermsOfUse (282/293/294)

burn: let's move on to terms of use
... PR 282 was merged, and there were some concerns raised with that, which spawned #293 and #294
... I'm so thrilled to come back from vacation and find a continued ToU mess

<Zakim> manu, you wanted to propose some tstuff

manu: feel free to go first matt

stonematt: go ahead, I was going to pull up the minutes

manu: pulling up 282

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

manu: issue 282 was about Deontic ToU, but it may have been merged too early, there were concerns by JoeAndrieu and DavidC (?)
... my bad, but due to all changes that may be hard to unmerge
... has mostly to do with language with what does "accept" mean

<JoeAndrieu> +1 to a fixing PR. If we can get to some sort of consensus on the call, I'll write something up.

manu: also a whole bunch of meta-issues mixed in
... not a "it's in the spec so don't change it", just trying to make changes clean
... I think this isn't a PR for fix the specific thing is easy, but the broader PR fo what we mean in the specification may be harder

JoeAndrieu: glad we were able to point it out. my concern is more the underlying language not the PR, I was splitting hairs maybe in the wrong place. I think we may be able to get rid of "accept" as in "accept a VC", something more rigorous and specific that doesn't trigger concerns many of us have

<Zakim> manu, you wanted to take a position as DB on "accept" and ToU

manu: +1 to being more specific and rigorous in the ways we use "accept"; I also want to point out that what DavidC said about conformance said is right
... if it doesn't have a MUST or SHOULD, it shouldn't be associated (??)
... I think that people won't object to the way people write MUST/MAY/SHOULD, real question is can we add test suite language

<ChristopherA> +1 to conformance is verify not accept

manu: with my DB hat on, I'll take a ToU position
... we have customers that want to be *aware* of the terms of use delivered to them, but they may decide to use one of those VC credentials even though they know they're violating the ToU. For example, regulation that doesn't apply in their jurisdiction
... so these things are very... they tend to be region specific when dealing with global governments
... any language that forces us as an implementor to not be conformant because the customer is making a decision based on what part of the world etc...
... we want it to be advisory, we're ok with warning about GDPR and etc, but we're not ok with our implementation being not conformant full stop

<Zakim> burn, you wanted to raise TallTed's point that we don't define usage, only limited cryptographic provability that claims were made and remain valid

<DavidC> +1

burn: I'm going to raise tallted's point about the data model... "we don't design usage"... all we design with the data model is a limited cryptographic framework for determining whether the data has integrity

<manu> +1 to that

burn: DavidC: I'd like you to clairfy

DavidC: last week I referred TallTed to figure 1
... we accept in our data model that the holder may pass on the credential to the holder
... thus our data model supports that, it's in our document. If it's supported we should also have fields in our data model to support itt
... so either we say in the document "it's an ecosystem" and there's no subject/holder relationship, but we're not saying that
... because of that the verifier needs to know (but also issuer and subject need to know) if it goes awry the issuer and subject need to be sure things won't go awry

burn: there are many things there... we don't specify all the things one can do with a data object. data object is a data object is a data object. There's a huge variety of things people can do about it. it may be the statement I made. There are statements that can be cryptographically proven and will remain valid. Everything else we don't specify
... just because someone can transfer doesn't mean we have to say anything about it
... I agree with manu that non-normative information about how things are expected to be used can be put in, and PING told us they expected that, but that's informative only

<manu> We do that for the proof block stuff...

TallTed: we should be pinpointing a model, but some pieces should be hand-wavey, so the necessary fields XYZ that must be present must be present, we don't know what they are, just make sure they're present

<manu> so there is an established pattern.

<Zakim> JoeAndrieu, you wanted to note VCs are not about "who should or shouldn't have a VC"

TallTed: the underlying lesson is "how do I do it, how do I do it", and that's protocol

<burn> +1 TallTed

JoeAndrieu: DavidC, in your response there's a "who should and shouldn't have a VC"... there's no way to assure that's true. My focus on this, there may be some personal positions I've been trying to avoid expressing, but I think we should have robust guarantees for the data model, but we have some notions about what can be rigorously said with VCs, and that's powerful. My concerns are that there are some things outside of VCs that

they think can be assured that aren't, and thus they may overlook those concerns which then aren't addressed and they don't realize it. I don't want to accidentally or otherwise mislead people so we don't have to do rest of collective analysis

JoeAndrieu: so that's where I'm coming from

<Zakim> cwebber, you wanted to suggest concretely there may be some protocol layer approaches

<manu> +1 to layering protocol on top of data model...

<dlongley> cwebber2: I hear David is expressing that there are some concerns that are being handled by the data model alone and Ted is saying it's a protocol thing and Manu is saying customers need ToU ... can David Chadwick just provide a protocol/extension on top of the VC data model and define things there. We did the same thing with ActivityPub and ActivityStreams. In ActivityPub we layered on top of activity streams and did this same thing and it worked well.

<dlongley> cwebber2: Can we do that here as well?

DavidC: I've been making notes of what people have said... so response to TallTed, I'd say this doesn't close door to inovations. VC has an expiry time, but you don't have to use the expiry time. If you use it after that time it's not conformant
... to respond to JoeAndrieu, I agree, but if we say that "holder must be subject", that leaves it to the protocol

<ChristopherA> -1 holder=subject

<Zakim> manu, you wanted to note that we're having a (good) meta discussion, but I need some guidance on what to change in the spec (or approval by the WG to go in and change some stuff

DavidC: to cwebber2 "should we put a layer on top", sure, though I think there are certain things underneath that might use it

<TallTed> Yes, we can define some fields as optional (e.g., expiry). But "the verifier needs a way to verify that this holder is authorized to hold this VC" is not the same as "the holder's DNA sequence should be in this (optional) field such that the verifier can check it" which doesn't leave the door open to *other* fields/methods for such verification.

<Zakim> burn, you wanted to remind that we can standardize other pieces later

manu: right... so I think we're having a good meta discussion, but it's a meta discussion at this point. I'm searching for things to apply to the spec as spec-text. I kind of get where most people are right now, and I'm painting with a broad brush... it seems like DavidC's opinion is that you seem to want to go more into the protocol than I hear more than other people on the call want to do, and that may be the crux of the issue. I

think we do have rough consensus at this point, I think the main question of whether or not DavidC will object to.. The consensus seems to be we're a data model only, and anything more than that we can do non-normatively, so into the future that's how we approach that. I wonder if there's concrete spec changes we can make or if we're talking about... I wonder if we can move onto something more specific to apply to the conversation

burn: I want to remind the group we can standardize other pieces later

<oliver> +1

burn: I think we've been trying hard to accomodate DavidC but I think you've been unable to convince the group... I'm not seeing consensus on more detailed information... I'm not sure how to say it, I'm not seeing support for the kinds of changes you're looking for WRT ToU. I'm going to ask bluntly: is this spec unusable by anyone without what you're proposing and do you formally object if we don't include it in this version of the

specification

<brentz> +1 to the dog

DavidC: I'm arguing to keeping it in the specification as-is

dog: woof woof

DavidC: I'm not asking for new things to go in, I'm asking for what's in there to be protected

burn: I'm assuming 282 is commpletely reversed

DavidC: I think 282... I think that's miniscule... all it did was refine the language that was in there. the language says the ToU must be abided by. You can have obligations and etc, so all it did was refine it to have those places.. so it didn't change the bones of the ToU at all

<JoeAndrieu> @DavidC is correct that 282 was minor. It exposed the larger issue.

DavidC: I was happy with the original ToU without 282, but I'm happy if 282 is not pulled in

burn: overall issue of ToU is what we're not agreeing on

<Zakim> JoeAndrieu, you wanted to note although I don't like "holder must be subject" as a ToU, it is valid. Issuers can say anything. What's not valid is claiming that conformance depends

burn: all of that can be yanked out of the spec if we don't get agreement
... and that's where we're headed

JoeAndrieu: I'm not a big fan of subject must be equal to holder. But it's valid, but the ToU could even say that. The only concern is tying the acceptance of the ToU which relies on shared legal understanding to verification or verifiability to whether or not someone can use that VC. It seems beyond what we can technically assure in this framework

manu: I don't think we need to revert 282, I think JoeAndrieu's PR will modify language, and other debate is "what do we mean about ToU MUST/SHOULD/MAYBE apply"... it's more than that, also bleeds into Subject!=Holder, it's all over that
... and it's true that we're hitting the point where the group is getting frustrated with this discussion; usually what happens at that point is we rip things out, or people dig their heels in and won't implement, and that may also result in ripping things out
... we might end up having things affected by "I'm not implementing XYZ"
... I don't think we're there yet
... I have a general sense of what consensus of the group is, can make editorial pass; I think DavidC will be ok with 80% of it, and as long as no strong objections we can move forward as long as there are no strong objections
... if we don't have formal objections, we can be done and move on
... so that's a concrete suggestion

burn: I like that suggestion... if we get to the point where Joe's PRs come in, and this needs to be ASAP, and you put in that PR, and we're not getting quick agreement, then we need to discuss stronger actions
... possibly removing text from spec

brentz: I'm not a fan of ToU, but I haven't spoken up because we'll just ignore it if it appears in the spec

burn: I think you said after you work with that one there will be a PR
... I'm nervous that might mean January

manu: I think if you make an objection, be very careful and intention

burn: when can you get your PR in, JoeAndrieu

JoeAndrieu: I'm trying to pull it in, my hope is today or tomorrow
... I'm dealing with flow issues it may create
... I'll try to get it today or tomorrow.

burn: rather than going through blocking issues and PRs i'm asking manu as editor if there's anything specific that deserves a summary of actions that have happened or something which can get a quick result

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

manu: but I do want to point people to the registry identifier discussion

<manu> https://docs.google.com/document/d/1dCPGKiW9uqVd1X_Ye6BCFt4qzRRGjPNfTuYEQKIZk6k/edit#

manu: there's a google doc, I'll call a vote
... if you want an option to show up in the poll, put it up there
... if you want a specific thing, you've got until thursday morning EST to get it in
... the other thing that folks should pay attention to
... pull 255
... no, it's an issue... I'm trying to find it... TallTed or DavidC where's that diagram I did at

<manu> Diagram in this issue: https://github.com/w3c/vc-data-model/issues/268

manu: right in issue 268, TallTed I'd like your input
... here's a diagram of what a credential actually looks like

<manu> Actual graph for credential: https://docs.google.com/drawings/d/1v293yj2Z4J9JHDTrTjnLEBs_D1zQTMp1ocgR8KF2DgI/edit

manu: DavidC said it's useful, suggestion is to put this kind of thing in one of two places
... either put it with the handwavey section or...
... if people like this, then do the same thing for presentation

TallTed: we're making up a credential here.. there's no such thing as a proof of age credential. there are things used as such. they have various things about them but real world example makes comprehension much clearer. a couple of real world examples... here's a genericized presentation that covers every possibility
... there's obv not a field for every credential
... but based on a couple of concrete examples

manu: you like the direction but you'd like a real world example?

<stonematt> DMV doesn't issue "Proof of Age"

TallTed: I'd like something real that exists, like a drivers license, as opposed to proof of age, which does not exist

<gannan> Do we need to represent all the fields?

<agropper> A Social Security card is very simple

<manu> remember that PING didn't want scary correlatable stuff

oliver: replacing proof of age with driver example

stonematt: I'm +1'ing what oliver said

<Zakim> bigbluehat, you wanted to mention web form age gates

<stonematt> suggest: change text "ProofOfAgeCredential" to an actual attribute that they issue

bigbluehat: age gating is a common thing on the web though, so it may be useful in some way

<TallTed> (while many driver's licenses now say "over21" or similar, the actual attribute is DateOfBirth)

<Zakim> manu, you wanted to note that PING didn't want us to lead w/ PII

<TallTed> (because under21 may change to over21 during the valid period of that license, while DoB remains constant)

cwebber2: yeah I suggested the diploma which ChristopherA also suggested

<burn> +1 for uni

<stonematt> +1 to degree

<burn> +1 to degree

<oliver> +1

<TimTibbals> +1 to degree

manu: PING said no PII, though I like the university degree example, as long as there are no examples I'll do that

<agropper> +1 to degree

<JoeAndrieu> +1 for getting rid of Over21

+1 to degree

<ken> +1

<dmitriz> +1

<dlongley> +1

<TallTed> +1 university degree better than age gate ... but should not be the *only* example

<stonematt> +1 to eliminating over21 and using our charter domain

manu: seeing lots of +1s, very helpful

<ChristopherA> +1 to eliminting over 21

manu: I'm looking at other PRs, I haven't seen if JWT has been updated since last week's discussions?

<oliver> https://docs.google.com/document/d/18BRHGHxMTKpCI8te68HWol2dFmnG4p2ooA6FyhuftBE/edit#heading=h.9g8lf8al0fdm

oliver: trying to work on it, summarized it in this google document, was not able to apply to git repo yet but will do it tomorrow or day after tomorrow

manu: cool, we have a number of ZKP PRs, and we have a conversation later today about it
... that'll take care of many PRs outstanding
... I did a readability of the spec, it's not very easily readable right now, but I'll try to do an editorial spec, might move things around but am hopefully not removing anything, just trying to move it

<Zakim> burn, you wanted to ask what Grant can do

manu: yes, Grant has been super helpful, if he can keep making suggestions that would be awesome

burn: yes that's what I was going to say. He was trying to be careful, clear editorial fixes rather than readability improvemnets, but willing to go as far in that direction as you like, has time and direction
... anything else that must be discussed today

<ChristopherA> Ciao!

burn: ok thanks everyone, I know that was a difficult discussion today, I don't think I've seen a working group without difficult discussions sometimes, so nice job everyone talk to you next week

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/(???)/figure 1/
Succeeded: s/suggested that/told us they expected that/
Succeeded: s/pull/point/
Present: Adrian_Gropper Allen_Brown Benjamin_Young Brent_Zundel Chris_Webber Christopher_Allen Dan_Burnett Dave_Longley JoeAndrieu Ken_Ebert Manu_Sporny Matt_Stone Oliver_Terbu TimTibbals Tim_Tibbals dmitriz mike-lodder David_Chadwick Ganesh_Annan Gregory_Natran Ted_Thibodeau Yancy_Ribbens
Regrets: tzviya
Found ScribeNick: cwebber2
Inferring Scribes: cwebber2
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0020.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.)