<scribe> scribe: dlongley

Varn: Any new comers?

none

Varn goes over agenda

varn: Any changes or comments on the agenda?

none

TPAC Topic Review

varn: We now have people who have volunteered to run every session. Anyone see any need for changes? This is the last chance.

<manu> TPAC Topics: https://docs.google.com/spreadsheets/d/161h0QO8QODtS04eyLQqc6errV7RamcbS-xOPJL6S0g0/edit

<varn> akc manu

manu: Have we heard from the policy and obligations WG or the ODRL folks?
... Renato who is the co-chair of that group said they'd be happy to drop in and help us on the Terms of Use/Service problem... Matt you took and action to follow up with him but I know an email bounced. I don't know what the status is there.
... We need to figure out if and when that's happening

Stone: That is on my list, we did get an email bounce. I will follow up this week.

manu: He said he was ok through a github issue but I don't remember what issue that was.

stone: I will try and track that down, let's keep going on the meeting.

JoeAndrieu: I would like some guidance on what I should do to prepare, I'm running two sessions. Am I supposed to have a powerpoint or what's the approach?

varn: The general rule is to use a powerpoint if you need one to organize, that's fine, we can support that. The basic responsibility is to just organize the conversation so we can reach a conclusion and move forward on the topic. So organize overall discussion on the topic and lead the group through it.

burn: Matt, this is your queue to talk about the slides.

stone: I created a slide deck that mirrors our agenda for the two days at TPAC. I have a placeholder slide for each session on the agenda. I'll grab the URL.

stonematt: The idea here is that the discussion leader has a choice for how to best use this resource. Either put slides directly into this deck if it makes sense or put a link or URL to the resources you want to use to lead your discussion.
... The idea here is that we wanted a slide deck to flip through as we go through our sessions over two days and queue up our discussions and give the leaders easy access to resources to lead.

JoeAndrieu: Is there a deadline for getting content into the deck?

varn: Before your session :)

manu: And it's usually a good practice to give the group a heads up so they know what to expect. Usually you're supposed to have all the content for them when they show up, it's usually 2 weeks in advance so we're already past that, so a couple days at least so people can prep and have opinions.
... Otherwise it's just you talking in front of the room with no feedback, so not a successful way to run a session because people won't be ready with review/feedback.

<stonematt> agenda as slides: https://goo.gl/5NXb2v

manu: More prep time the better.

<ChristopherA> Is there a URL for Wednesday TPAC schedule?

varn: Any other discussions on the agenda or TPAC?

stonematt: Generally speaking, certainly a way to approach this would be to look at the issues and topics we have in github and use them as a construct for the discussions we want to have live and face to face.

varn: Let's move onto the next topic.

Web Commerce IG agenda (Use Cases)

<stonematt> slides for IG: https://goo.gl/iC6tSq

varn: We have a deck. Matt and I will finish background slides on that. We still need use cases.
... Do we have people willing and able to put in use cases at this point or no?

stonematt: Is David Ezell on the call?

Ezell: I just joined. I'm planning to get some use cases in there for discussion. Manu sent me an extremely long list of already existing use cases. So I either have to choose some of those or come up with new ones.

JoeAndrieu: If you'd like to bounce some drafts off me I'd be happy to contribute, so we can put something together.

dezell: Ok, sure.

JoeAndrieu: I can fill you in on our thinking on the existing use cases.

dezell: The sort of thing the IG is going to be looking for is "how might we translate some sort of correlation in a use case into actual work for W3C"
... I think it's also good to talk about simply good ideas, but specifically we'd be looking for new work items

JoeAndrieu: Ok.

varn: Could you say a bit more with new things to do because I was seeing a lot of overlap with VC and what needs to be done with Web Commerce.

dezell: Let's take one and maybe we need a driver's license ... some of this is hypothetical so far. I've still got a head full of digital offers and this idea of having them traveling along rails in the Payment Request API. But maybe there's a separate API for that. So maybe we need a driver's license to travel along with a claim proving who they say they are. If we come up with extensions for Payment Request or Payment Handler API -- that are required

to use VC in commerce then that's the kind of thing ... yes... we need this ability to use a VC here so that's an API change.

varn: We're limited to data model, so other than contributing new data model elements... so we need you to tell us what data elements are missing and then you'd do the new API bits.

<Zakim> manu, you wanted to note that this conversation might turn into rechartering... or new charters.

manu: Right, I think what David is saying is that we should think a bit larger than that. The Web Commerce IG has the authority to charter new groups in entirely new directions of work.
... It could be the minimum feedback we provide is to say "the data model needs to change this way".
... But what David just said is that maybe these VC needs to go over payment rails and that's a larger conversation, maybe IG needs to talk about that, Dave Longley and I are working on a blog post outlining some concerns in that area. It could turn to larger rechartering questions, new charter questions, things of that nature.
... I know that the Web Commerce IG's (correct me if I'm wrong) purpose is to identify what changes to the Web Platform are needed for commerce and maybe data model isn't enough and we need protocol and the IG can propose something along those lines. The conversation can get fairly big and the chairs need to spend some time figuring out the scope.

dezell: Thank you, Manu, for helping what I was actually thinking sound simple.
... I think the outcome ... what we're not looking for necessarily is for the IG to dredge up a bunch of things that become work items for VC. And vice versa, but from what Manu just said there is a possibility to put work items to the IG. What's likely to happen is as we see the use cases that are in common, discussions will ensure or the API that Manu just mentioned, that's a great idea to bring up with how things might work.
... In the discussions that follow the use cases that this API would handle things better than the payment rails. We've discussed this a bit with digital offers. Claims with offers is a little more direct except in the simplest case with credit cards.
... I don't think that anyone should feel constrained that all you can do is data models but also figuring out what's next. The IG is a good instrument to move things forward.
... There are other ways to do it too, not saying IG is the only way. The IG is one place these seeds could be planted.

<Zakim> manu, you wanted to also raise "Verifiable Credentials" vs. "Verifiable CLaims" discussion.

manu: I don't want to dwell on this point too long ... we are currently grappling with a language issue in the group, but there is this "verifiable claims" language that was used as a suggestion by some orgs. But it's a problematic term because people think we're talking about verifying a certain statement is true when in reality we're just saying that we can prove someone said something. So verifiable claims is the wrong language, we should be talking

about verifiable credentials. Every time we change the language in the specs from claims to credentials it becomes so much simpler and easier to explain.

manu: So something we may want to say in the conversation with the IG is that we made a mistake with naming and we should rename at some point, we don't have to have that discussion at TPAC just bring it up.
... The language is backfiring on us as we go to other areas.

varn: Any other last minute comments?

none

varn: We will only be seeing additional use case work from Ezell and Andrieu.

<nage> I'm still unsatisfied that the "authorization" vs "disclosure" concern has been addressed, but that is better for in-person discussion.

Data Model Blocking PR

varn: So what's blocking us from advancing most prominently right now?

manu: We've gotten a lot of feedback, thank you everyone.
... There are three issues that have received no feedback yet.
... Those ones are not critical so we could probably leave those. Given the reviews, we could ask the general question, does anyone have any objections to the PRs that have comments on them right now? If not I will propose that I make the modifications people have asked for (all editorial).
... And then after that I will say that the PR will go through (be merged) before Sunday of this coming week.
... That will give us a fairly new spec to review at TPAC, a much more complete spec to review at TPAC. Any objections to that ... and objections to the outstanding PRs?

<kimhd> +1 to approach

<JoeAndrieu> +1

+1

<gkellogg> +1

varn: +1

<stonematt> +1

manu: If you haven't had a chance to review and you still want to do that, you can still go into the PR before Friday.

varn: Ok, looks good, thanks, Manu.

manu: We could spend a bit of time talking about the next set of changes.
... I could draft text based off of those suggestions.

varn: We do have some time, we have 5 minutes to spend on that.

manu: Yeah that's good. Let me put a proposal out there, this has to do with "verifiable claims" vs. "verifiable credentials". As mentioned our spec can say whatever we want.
... We could modify all the language to talk about verifiable credentials, and still mention claims but only in the context of credentials containing them.
... The language just really cleans up quite a bit when we make that change, I want to thank Joe Andrieu and Dave Longley for the suggestion.
... Does anyone have any objections to shifting the language over to focusing on verifiable credentials vs. verifiable claims?

<ChristopherA> +1, no objections

<stonematt> +1 no objection

JoeAndrieu: Yes, I just had a question -- will we also at the same time will we be using the term "verifiable profiles" as part of that package as well?

<TallTed> +1 good change

manu: Yes, but that's already in the spec.

+1

<JoeAndrieu> +1

JoeAndrieu: I don't know if it ever makes sense to share profiles that aren't verifiable... but it makes sense to get that into a draft. I'm generally supportive, I think this is the right way to improve the language.

nage: My only concern isn't with the shift to credentials it's the rest of the potential protocol that implements it and the other terminology. Whether the contents is verifiable isn't solved by the terminology fix. The trouble with shifting to credential makes it harder to talk about the selective disclosure constructs. How verifying the contents vs. proving the contents.
... The subsequent move to profiles also seems to muddy the waters. I'd like to see the distinction between a bearer token/authorization vs. the direct disclosure of data. We've talked with credentials in other communities, like those familiar with JWTs, there's confusion that credential means some kind of authorization token. What we're using them for is the direct disclosure of data.
... It's similar to authorization but about sharing information directly.

varn: Yeah, not sure how we deal with that.

<Zakim> manu, you wanted to discuss non verifaible things and to note we have section on bearer credentials in a PR

<JoeAndrieu> +1 for auto-form fill

manu: Joe you asked about use cases for non-verifiable profiles and non-verifiable credentials, there is a fairly general use case which is like form auto-fill -- it's someone saying "here's my information". You could use non-verifiable credentials (no signature/proof) but the data structure is the same for things like form autofill. I haven't heard anyone say strongly they want that other than Deutsche Telekomm saying they wanted to see it.

<JoeAndrieu> good use case

manu: We actually have a security section (open PR) on this now. We do talk about it in the spec now and when that PR goes through we'll see it.
... PR 88, please check it out, review it.
... Nathan mentioned that this may help some of the language but may make other stuff more difficult. We do have a section on bearer credentials now. PR 78, we will pull that into the spec. I think it's very important that if we start using "verifiable credentials" that we don't start short circuiting to "credentials". We mean something specific when we use that term, it's defined in our spec. Hopefully that will help people coming from JWT/JOSE land.
... That's one of the problems we had and why we used "verifiable claims" but it turned out that was even worse.
... Richard and Matt had been wanting to add a word in the beginning to create a distinction. So "verifiable credentials" are different from JWTs.
... Nathan, I don't think we have every just right yet and we will need more deep thinking and tweaks.

<manu> we also put proofs in verifiable credentials :(

<manu> signatures are proofs

JoeAndrieu: I wanted to draw a suggestion for Nathan's concern, we don't have a whole lot of time to discuss, just to plant a seed. What about using the language that we put proofs in a profile -- and the simplest form is to just use a verifiable credential directly. If there's some more sophisticated mechanism then that flows as well.

<ChristopherA> signatures are a subset of proofs

<manu> +1 ChristopherA

nage: This is one of the ways that the word "claim" helps us -- when you make an aggregate of various claims and put them together you create a credential. Now we're shifting the word from claims to credentials, and we lose that symmetry with that traditional use case. Anyone can claim something without having the authority to claim it or the ability to produce a correct output.
... I don't think switching from claims to credentials helps solve that problem. We're looking for the integrity on the information being disclosed.

varn: Ok, let's move onto discussing privacy-related elements on the spec. We need to identify volunteers to help address privacy issues -- is that where we are?

manu: There are two privacy parts, the privacy document (W3C privacy assessment).
... And there are all the sections that were added to the privacy section in the spec and all of those except PR 90 have feedback on them. If someone can review PR 90 that would be great. I think we're unblocked, we got feedback from the group. We will merge this stuff in unless someone objects by Friday.

varn: There are remaining issues where we don't have a congealed element, PR -- no discussion or way to address it yet.

manu: I went through the entire issue tracker and I think we've addressed every issue with the caveat where there were three issues where it was unclear if it was a privacy issue. Once we merge this stuff it will autoclose lots of issues.
... We'll have a better idea if we're missing things once that happens. I think we've done a fairly good job of addressing all the concerns people wanted us to address in the spec, so we'll now move onto adding new issues.
... Bulk of this stuff will get into the spec after Friday.

varn: Ok, any other comments on the privacy topics before we move on?

none

varn: Ok, we'll see how we'll we've done when people review.

Data Model Spec current milestone issues

stonematt: This is a standing agenda item to review blocking items for this milestone in general.

varn: So nothing in particular, so it's addressed already?

<Zakim> manu, you wanted to put dlehn on the queue.

stonematt: The PRs we have address a lot of the blocking issues, if there's anything remaining, the following question is ... once we pull these PRs in do we declare the milestone complete and move to the next one?
... What's left?

manu: Right, I think we just addressed issue 66 in the milestone -- the language issue, this change to verifiable credential will address that issue. The RDFS owl vocabulary is another issue, we have some great progress on the test suite, which Dave Lehn can report about in a bit. To get it working we needed to create a context and put it out there, a loose JSON-LD @context. We will likely have a good discussion with Gregg over the next week on that.

gkellogg: Indeed, I was just at Dublin Core 2017 last week giving a discussion on vocab and @context generation, so that is what I will be adapting as well as some background on RDFS and Owl and that includes tools and practice for generating both that and human readable documentation associated with that.

dlehn: I did some work on the test suite, we have some minimal tests in there right now, they are rather basic. Just testing schema things and so on. There's a Python driver that calls out to external applications to run the test to do issuing and verifying. The way it's written right now should allow different language implementations to have a common driver.
... We can look into better ways to report results. At the moment it's using a local @context, there's a "w3id.org/vc/v1" context. We haven't updated the old experimental "credentials" context on w3id.org yet. We have a JavaScript implementation working with the test suite now.
... Anything else anyone else wants to know?

manu: We're in good shape with the test suite now so we can start making more rapid progress on things people might want to add like revocation, terms of service/use, consent, so on.
... We're in good position to start cranking forward and addressing milestones more rapidly because the framework and structure is there.

stonematt: I'll echo that good news on the test suite, thanks for everyone working on that. Follow up question to your comments on this milestone. On the vocabulary, we were hoping to make some progress on autogenerating the vocab this week and you have some time set aside to cover this topic at TPAC. We have it listed as a blocking item for this milestone.

manu: I don't think it's blocking any more but we need to hear from both Gregg Kellogg and Chris Webber because they've done a decent bit on vocab autogeneration. The reason it was a blocking item was because it was blocking the test suite. We have a document now so it's no longer blocking and we can push it off to another milestone. Two parts to this...
... JSON-LD @context and then generating human+machine readable documentation.
... The first item is done, the JSON-LD @context that we can keep modifying as the group progresses but the human readable docs is less important now and can improve as time goes on.

stonematt: Is there benefit to us to try and publish this milestone before TPAC.

manu: I don't think so, I think it's an internal deadline, we've made decent progress. Maybe it would make the group feel warm and fuzzy but that's about it.

stonematt: Not necessarily a bad thing.

varn: Anything else?

gkellogg: I'd be wary of pushing something out there that we may, upon further review, miscommunicates where we're going. I'd like to have the discussion at TPAC and I could then with anyone else that's interested in making that happen, the technical aspects. Then we can have something come out that's a basis for doing future work.

<manu> +1 to gkellogg

varn: Any suggestions for future agenda topics? We will be trying to organize agendas for meetings post TPAC.
... I think the next agenda after will be the 28th of November, I don't know if there's one the week after.
... Thanks!

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/Quinn/Quin/
Succeeded: s/item.s/items/
Succeeded: s/PRs>/PRs/
Succeeded: s/=//
Present: Chris_Webber Colleen_Kennedy Dan_Burnett Dave_Longley Gregg_Kellogg Joe_Andrieu Liam_Quin Manu_Sporny Matt_Larson Matt_Stone Richard_Varn Ted_Thibodeau Christopher_Allen Nathan_George David_Ezell Kim_Duffy David_Lehn
Found Scribe: dlongley
Inferring ScribeNick: dlongley
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Oct/0025.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.)