Verifiable Claims Working Group -- 24 Oct 2017

<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Oct/0018.html

<scribe> scribenick: gkellogg

Agenda review, Introductions

manu: There are a bunch of PRs that I’d like some time to discuss at the end of the call.

TPAC Planning

<manu> ^^^ TPAC Planning Document

burn: we had sent a request to privace IG, and haven’t heard back from them, so there may not be meeting with them.
... But, we have an open slot at the end, the last two hours for things that come up during the meetings.
... The main thing we need now is volunteers for discussion topics.
... Credential creation vs presenttaion, TTL of Use and revocation.

<nage> I can lead a Claims vs Proofs discussion

burn: Leading a discussion does not require expertice, but should have perspective and understanding of the topic. Then lead and moderate a discussion.

<JoeAndrieu> I'm willing to lead D1s3.1 VC where subject is not holder

<Zakim> manu, you wanted to ask if ODRL folks might be able to participate

<JoeAndrieu> As well as the use cases one I'm already on for

manu: TTL/ODRL, the ODRL group is really interesting in colaborating. Have chairs reached out?

burn: No, can manu send an intro email. At this point, the timing won’t change must.

manu: maybe we can pull people into the group.

matt: I can reach out if you have their email.

manu: too late :)
... Ed Bice (sp?) has expressed interest, but hasn’t shown up on call.

burn: agenda is in good shape, OpenID/SAML is crossed out right now, as we may get to this before TPAC.

<burn> https://goo.gl/iC6tSq

Web Commerce IG

burn: We created a presentation for people to fill in use cases. The chairs plan to do a refresher/intro to the VCWG to cover status and scope. We’re not going to review the documents in that meeting.
... Then we plan to list initial use cases. THen we’d like manu or dlongley to present their demo.

manu: Yes, dlongley would love to!

burn: The chairs will add some use cases, but would like to leave it openn for the commerce group, or anyone else from this group, to add more use cases.
... After Commerce/VC Use Cases (nudge dezell), fill in extra use cases for us to discuss. Either add slides, or fill in google slide doc.

manu: THe demo is the credential handler demo?

burn: yes. It’s part of the explaination of the use cases we’ve been looking at.

manu: use cases like showing a passport when buying a ticket.

burn: there’s value outside payments/commerce about how someone might deal with passports.
... THis gives us something to refer to when talking about use cases later.

dezell: I would suggest that, in addition to status of working drafts, talk about how the community is responding.
... I’m going to forward a link to Matt’s email to the Commerce IG to get this started.
... It’s a forward motion area for commerce/payments.
... Apparently, there are 80 people signed up for Commerce IG, but will be smaller.

Readiness for Privacy Group exposure

<burn> https://github.com/w3c/vc-data-model/pull/73

burn: This PR has not been applied yet, but is there anyone to speak to it?

manu: There’s been discussion on this. I think the PR is good to go and would like to pull it. THere’s been some review.

burn: any discussion/concern on pulling $73?
... seeing none, go ahead and merge.

<Zakim> manu, you wanted to discuss other privacy things

<manu> List of all privacy section related PRs: https://github.com/w3c/vc-data-model/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20privacy%20

manu: We have 5 outstanding PRs to expand privace section. This competes every section we’ve identified.
... A while ago we identified concerns and were going to work through them before privace review. Because this may happen soon, I’ve added PRs to fill in other sections. I’d like to pull them in before review.

<reto> There's also: https://github.com/w3c/vc-data-model/issues/75, just an issue no PR

manu: I don’t expect there has been much review, but it would be great if people could review so we could pull.
... we should add something about that too, I’ll get that in.

burn: As I understand it, you’d like to finish these up before we request a review.
... Personally, I’m fine with this approach; we called out to the group, and it’s better to engage sooner rather than later, but we need to show we’ve been thinking about it.
... I think we’ve done what we need to to show it’s important to us. If we can speak with some at TPAC, great, otherwise, this shows progress.

manu: It would be nice to have a number of the PRs merged before TPAC, so the document is in a full form. The only part of the spec missing is the security considerations section. I’ll have 5-8 more PRs in this section shortly.

<ChristopherA> Just added https://github.com/w3c/vc-data-model/issues/87

manu: After these, we’ll have a full/cohesive document. It would be nice to have for TPAC. However, we only have two more calls, people would need to review within the week and merge next Tuesday.

burn: I don’t want to pre-judge when they’ll go in. The most we can do is ask for review. We’ll see where we are next week.

<ChristopherA> (it was a subset of #75)

Data Model Spec current milestone issues

<burn> https://github.com/w3c/vc-data-model/milestone/3

manu: Those topics haven’t had work, except the second one. I’m trying to schedule changes to the spec that fill in content. These are bigger changes we might discuss today.
... dlongley raised an issue on the spec that we keep talking about VC as this thing, as if they’re self-contained, but they’re not. They’re only useful when inside a credential and signed, and that’s what the data model is all about.

<ChristopherA> +1 agreement with Manu on this

<dlongley> you don't just "sign a claim" to make it verifiable ... you encapsulate it in a credential (which contains other semantics as well)

manu: When we say “Verifiable Claim” it confuses people, because you can’t reallly point to something in the spec. THis boils down to that we should probable call it the “Verified Credentials” spec. We should talk about credentials vs. claims.

<TallTed> +100 confusion abounds and rekindles during reading/re-reading

manu: Does the group stay the course, or push for a change to talk about Credentials? Does this have charter implications? We should start talking about Verifiable Credentials. This is limiting progress.

<dlongley> there is further confusion that arises from "Verifiable Claims" -- namely that some people tend to get confused about *what* is verifiable -- they think that the *claims* are verifiable. That's not the case -- what is verifiable is their authorship.

<dlongley> "credential" does a better job of communicating that.

manu: The vocabulary is easier in time.

<dlongley> people understand "credentials" to be documents from some authority making assertions.

manu: The hold up is claims vs credentials.

<nage> In the identity space credentials are more commonly used for things like access tokens, so signed data envelopes for data being called credentials confuses folks too. Moral here: all vocabularies we chose will confuse some group or another.

<dlongley> i think that the confusion with "login" is limited to one community -- (the security community)

matt: We get a lot of pushback during chartering about credentials which are used for login. We may have traided one confusion with another. THis is a morass that will be hard to get out of

<dlongley> whereas "claims" is confusing to ... almost everyone.

<dlongley> +1 to richard

varn: I always liked Credential; I’m not sure how many people _only_ think that credentials are related to login (not many).
... We can deal with it in how we build our data model. YOu could just define Claim to include Credential, a Claim being a special case of Credential.

<dlongley> +1 to nage that someone will always be confused -- let's go with confusing the fewest people, which i believe would be to use "verifiable credentials" instead of "verifiable claims"

varn: Perhaps we could change our name sometime.

<dlongley> in our data model, there is no "verifiable claim" entity.

manu: I don’t think there’s a sub-class of Claim that’s not a Credential. Except maybe some text with a signature. There’s no such thing as a verifiable claim that stands on it’s own, only verified credentials that contain claims.

<dlongley> only "verifiable credential".

burn: When we first created the document, we had to avoid the use of the term “Credential” I referred to a set of claims, such that not each claim is verifiable, but that the set of claims is verifiable.
... If we think we should change the name, we should do it sooner rather than later.
... That kind of name change could require another FPWD, due to potential for new patent exclusions.

reto: For me, Credential is associated with what you need to identify yourself, and is necessarily verifiable.
... I like the terminology in the charter which distinguishes between claim and credential, and uderstand that claim is broader than credential.

<reto> https://factsmission.github.io/twee-fi/

<reto> http://schema.org/ClaimReview

reto: I interpreted the term Claim as being the same term as used in ClaimReview.

<Zakim> tzviya, you wanted to comment as newbie

tzviya: When I first started to explain this to my group, the term Claim was quite confusing. Both terms have their own problems, a new term would be worse.
... I found the term Credential was clearer.

JoeANdrieu: We’re not verifying the underlying claim, which is confusing, but only the credential, but we should have a term for that attestation.

<dlongley> +1 biggest problem with "verifiable claims" is that it miscommunicates what is being verified

JoeANdrieu: This might addressed by changing the language when talking about what’s been verified. We usually talk about presenting claims, but we really present profiles. The validity of the claims is verified by verifying the credential. I’m wary about changing names.

<varn> +1 on claims as the payload we are NOT verifying

<burn> not verified, but verifiable

<dlongley> the claims are never being verified -- they are being *trusted*.

<dlongley> trusted claims.

ChristopherA: I sill think we fall into trap. We’re talking about credentials/profiles, and we need to put this language first, because it’s causing too much confusion.

<dlongley> you can trust a claim when it is presented in a credential that is signed by an issuer you trust.

ChristopherA: It’s doing so in some harmfull ways, we’re trying to move forward on “verifiable news”, and getting people like TimBL involved makes a weak argument.

<dlongley> if we're going to talk about "claims" at all, we should be saying "Trusted Claims".

ChristopherA: I’m fine without changing the name of the group, but everyplace we say something we need to correct any misunderstanding.

<dlongley> "Trustable Claims" being too silly :)

<JoeAndrieu> +1 for trusted claims (a rare appreciation for the word "trust" in a technical context)

<varn> at least we are not verifying claims. someone can. not sure what we call that when they do.

TallTed: I’ve been speaking to this for the last several calls. The problem with reusing overloaded terms is that they get interpreted with a previously existing meaning. It doesn’t matter what you put at the beginning of the document, you end up falling back to the base understanding of the term. We’d be better off using a made-up word.

<TallTed> +1 it's not about the group name, but it *is* about the terms in and titles of the docs we produce

<varn> no. gosh no.

burn: I wouldn’t worry about the name of the group right now. People are used to the name of the group being unrelated to the name of the specs.

Test Suite Progress

manu: The test suite we’re hoping to have done before TPAC. The heavy lifting is done, we just need to put it into something that runs tests. Hopefully by the end of the week.

PR discussions

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

manu: There are a number (5) of PRs that add to privacy section; shouldn’t be too controversial.
... Please comment on these and new PRs.
... PR #77 changes inspector-verifier to just verifier. We’ve had people looking at the spec that have been confused with inspector-verifier, because it seems there are multiple classes of inspectors and verifiers. Let’s just pick Verifier and go with it.
... The word Verifier seems to be broadly used in the market place.

<Zakim> burn, you wanted to remind people this is not just the Manu spec

<nage> +1 to picking verifier for now (ABC4Trust inspector implies validating the contents of the claims, where verifier is validating things like signatures)

burn: Reminder, it’s not the “manu spec”, anyone can submit PRs. Please propose different text if you disagree.

JoeAndrieu: I want to highlight #26, where there was some strong interest at OAuth; they’d very much like to see JWT supported for simple use cases. THere are other specs where they tried to take out the need for C14N to make it easier for developers.

manu: We looked at JWT a lot, but with nobody from JWT engaging, it’s difficult to make progress. Without people pushing JWT, it’s going to be hard to get supprt there. There are also problems when you don’t C14N.

<dlongley> also, there is a JWS-compatible signature method that works with Linked Data Signatures.

manu: The compromise seemed to be supporting JWS.
... JWS seems to be the compromize solution in the community.

<burn> s;https://goo.gl/iC6tSq;Commerce IG planning doc: https://goo.gl/iC6tSq;

- DRAFT -

Verifiable Claims Working Group

24 Oct 2017

Attendees

Contents