Verifiable Claims Working Group F2F meeting SFO -- 06 Apr 2018

<burn> hi all

<burn> The room here in SF has just dialed into WebEx.

<burn> No display

<stonematt> Hello, Hello

<burn> Agenda: https://docs.google.com/presentation/d/1xKKpKL2MmxAg9-UACs-VMMABs11NrxrvbIykayaBYlo/

<stonematt> Agenda slide deck: https://docs.google.com/presentation/d/1xKKpKL2MmxAg9-UACs-VMMABs11NrxrvbIykayaBYlo/edit#slide=id.g3697434a92_1_8

<cwebber2> scribe: cwebber2

burn: moving to slide 5, if you did not review or understand these policies, please do so
... if you are not on the list of companies on this list you are not allowed to make substantial contributions to these specs. I've already spoken to the people in the room who are not able to contribute and I don't think we have anyone on the phone who has that issue
... introductions, say your name, whom you're representing if anyone, and a bit about your background if anything, and favorite thing about san francisco

achughes: representing through specops, helping address standards and address issues through identity space

agropper: I'm Adrian Gropper, with patient privacy rights, I probably have a dozen years of experience with identity space particularly with health care and health care standards, my favorite thing about SF is the summer of love exhibit

pelle: I'm Pelle and I'm representing u-port, I've been in the identity space, I like a particular sandwich space with bahn-mi sandwiches

christian_lundkvist: representing u-port, I have been working in the etherium space for a while, my favorite thing is about the weather

<manu> cwebber2: Hi, Chris Webber -- representing Digital Bazaar, do decentralized social networks, DIDs. Favorite thing about SF is the weather - mild murky days.

Allen: I'm Allan Brown
... I'm Allen Brown, representing myself, doing logics stuff, about the weather I used to have to have several changes of clothing

manu: I'm Manu Sporny of Digital Bazaar, ceo and founder, we do lots of work on identity, blockchains recently, standards... favorite thing about SF is the Yerba Buena gardnes

JoeAndrieu: I'm Joe Andrieu, I'm with legendary requirements, trying to reduce accidental privacy violations

burn: I'm Dan Burnett, background in speech recognition, I've been involved in lots of standards... san francisco, I like walking by the water when it's nice... has one of the nicest waterfronts in terms of atmosphere etc

<rschulman> (is this a private meeting or may anyone join in?)

liam: I'm Liam Quin, I'm with w3c, my background is in graphic design etc, favorite thing about SF is that if you're openly gay, SF is one of the few places I can safely go to in the US... a number smaller than I'd like it to be

<rschulman> manu: Understood, thanks.

stonematt: this is Matt Stone from Pearson, just joining as first standards experiential proces,, but have been here for 4 years now, seems kind of crazy... my background is in credential data management in the commercial space, my favorite thing in SF is probably something I'm going to mix my view from my sister's place in Victorian Heights

<rschulman> manu: No, I'm not.

stonematt: in terms of weather, I'm in Boulder, CO, it's a blizzard here so I'm very jealous of where you are

liam: there is molten ice everywhere!

ChristopherA: I was with Blockstream, I'm now with the generous offer from SpecOps to continue to participate in the standard, my particular background is in cryptography and etc, I'm the main person behind SSL/TLS, I've been pushing self soverign identity, my favorite is 24th st, it's a beautiful place

<rschulman> manu: Understood. I have no knowledge of other patents or whatever that I could possibly share. :)

davidc: I'm David Chadwick, I've worked on x509 and etc, my background is in verifiable credentials and etc... terms of favorite place in SF, don't know it's well, but my favorite place in the US is Zion national park, gorgeous and with scary cliffs

kimhd: I'm Kim Duffy with Learning Machines, my background is in distributed systems, in general more math programming and veered into CS. I got into this through blockchain work at MIT media lab, looking at open badges spec, we got interested in the ld signatures suite, ended up attaching ourselves to everything this group is doing, a great group to be a part of

manu: re: IIW, there's a lot of traction around VC and etc and that was well received afaik... there was less hostility at this IIW than at last time, but some of the people who were hostile about it have been still hostile but are engaging in conversation now
... there was more conversation around decentralized identifiers and DIDs and signature formats etc

<rschulman> I'm Ross Schulman, I'm a senior policy technologist at the Open Technology Institute, though I'm just here representing myself. I am passionate about decentralization and try to advocate for it in policy spaces.

manu: I think the work is being received well, DIDs and VCs are being used as a catch all phrase without looking at specs

JoeAndrieu: I think it's worth noting that Soverin released how they're doing things with key management and etc, important to realize how VCs work etc

burn: this was my first time at IIW... DIDs was used constantly and it made me wonder whether it started there or started as work we've been doing

Allen: DIDs in that space mean both decentralized identities and decentralized identifiers

burn: Nathan George and Drummond, you just came in so I wonder if you want to give thoughts on IIW

nage: there's a lot of uptake of interest in zero knowledge proofs. also good conversaitons on how to do pull requests with manu. Several people were given invitation to join the CCG and I hope they do

drummond: the current level of interest in VCs is really high, lots of people counting on the work in this group... no pressure! lots of market forces and social/political viability of VCs, a good thing. as nage said it's great to see the awareness of the need for privacy expecting exchanges
... if you weren't there in person we had a session where zero knowledge proofs were introduced an it was standing room only

ChristopherA: like others the amount of DID and self-soverign identity convo being norm rather than exception... I hoped for it but was surprised by the level. Interesting things happening with FIDO, NUMA?, and other things, but interest on these issues. getting people to join credentials group and etc, but there's still a lot of ad-hoc
... did talk to a number of people with cryptographic knowledge, we're all suffering from a lack of cryptographic expertise. but I was pleased to be able to be there and like others I lost my voice

<Zakim> liam, you wanted to say it's real

<achughes> NUMA should be User Managed Access (UMA)

liam: first time going to any identity conference, at some point I need to go to w3c director and say this is the kind of stuff people are interested in. Very useful to see people implementing ideas, because I put out calls for implementation and I didn't know people were implementing. Seeing stuff was useful. Need to make it more visible. Make group homepage link to implementations and that kind of outreach

<Zakim> kimhd, you wanted to comment on EDU/OCC VCs

liam: I can say to the team "there are a lot of applications of this stuff and are using it"

kimhd: about using it, we have a lot of people from the educational space in the open badges space showing advantages of verifiable credentials. A lot of interest in
... we hope to have prototypes of packages of verifiable credentials fairly soon, in next month or so

agropper: two related things from this IIW, people starting to reuse concept of self-soverin identity stack, it's central
... linking that to the appearance of the decentralized identity foundation
... that's the first time they've been at IIW
... interesting interactions with the self-soveriegn identity stack

burn: any other comments on IIW? ok
... nage and drummond, could you give introductions? name, background, thing or place you like about SF

<kimhd> I forgot to say, but I want it on record that burritos are a best thing about SF. Some options: http://www.businessinsider.com/review-best-burrito-san-francisco-2017-2

drummond: I'm Drummond Reed, I'm at Evernym, I'm chief trust officer, which means I'm responsible for identity/policy/security policies... favorite places... that's a bit hard. I'm a huge fan of the bridges around here... bay bridge esp and also golden gate, had a cousin whose wedding was on treasure island, married a naval officer on that base. the view from there of SF was so stunning

nage: I'm Nathan George, I'm no longer with Evernym and am with Sovrin, I work on blockchain system, in terms of SF I'm always here on business, but I like picking up an ice cream on the bay front when the opportunity arises

burn: *talking about slide confusion*
... from scope perspective, scope of this group is way more constrained than the CG. it does not mean that in the future we might not be rechartered to have a broader scope. Right now we are chartered to recommend a data model and particular syntaxes to express verifiable claims. We might give examples of how they may be used. It is out of scope to define protocols and browser APIs. To deal with the larger problem of identity on the web or

internet. doesn't mean we can't talk about those, we just can't talk about resolutions regarding them

liam: strictly speaking, to be clear, being out of scope in the w3c charter means we're not required, but a working group can produce any document at any time, so it is possible we can produce working group notes that are useful to future work.. not suggesting we do so, just saying we don't need to skip those if useful

burn: it's important that you said can produce a "note", because "notes" are not standards track. however a standards-track document can be blocked as not allowed, and the reason for that is IPR

drummond: some of the things up there are clearly being dealt with the community group, what's the formal relationship between the CG and the WG

burn: no formal relationship, though it's mentioned in the CG, so we're supposed to liase with them but aside from that there's no formal requirement
... informally being involved in this group, I can envision future CG work moving into a rechartered version of this group

drummond: I remember thinking at the meeting thinking that there may never be ways to get people to move over, but that is happening
... and I think people are seeing why
... I see an almost universal reaction which is "it's really easy to see that" but then there's "Oh I'm torn, credentials seem really limiting"

christian_lundkvist: there's also a lot of overloaded terms which can be a challenge

burn: primary goal for today is to review and close as many github issues as possible
... what I'd like to do now is look at the agenda, this is on slide 10
... we're going to need a bit of a time check, we're just now at the 9:00 item, so I think what we'll do is... it's officially break time, what I'd like to do is propose the "getting to CR" discussion, because that was what the big remaining items are, and I think those may come up in the issues

manu: at some point today I'd like to spent 10-15 minutes to get to CR

burn: let's spend 15 minutes discussing that and then we'll have our break

manu: cwebber is going to spend entire next week on this, we're going to try to pull in examples, the question is who's doing implementations
... I'm super concerned, what about implementations, and there may be interop concerns with soverin/evernym, and kimhd I don't know how ??? fits in there
... best thing would be to have 4 completely independent implementations

nage: manu and I talked about this at IIW, we are still delinquent on how to deal with the ZKP things, but we're getting to it, we're also working with the IBM, ???, and there's also various blockchain implementations, and I've been herding cats to try to get that whole group as part of this effort, but I know some of them want to focus on implementaitons and not the spec and that's an uphill battle

kimhd: to respond to what manu mentioned, what counts as an implementation, what we've prototyped around issuing and verification of open badges as verifiable credentials; thing we were plannign to contribute as well around samples. we weren't planning on making good quality code

<nage> We are working with IBM, folks from the IRMA community and others on how a ZKP or zkLang approach works and affects the data model

kimhd: ours may be able to be useful

<manu> cwebber2: I think having examples is useful -- often, if you have incomplete-ish implementations, its still useful to get implementation work done.

burn: and I will jump in to say from a w3c perspective, the w3c encourages groups to be reasonable in their attempts to discover what interop means. in some cases implementations that are not complete, as long as you have multiple implementations of the same piece, that's good enough. if you have two implementations are

liam: our bar has been rising but that's for getting out of CR, because as we move into CR we have to think how to get out of it. typically we'll be expecting implementations that do every feature, but some specs in which every feature is optional, and then interop is fine. in order to get out of CR we have to show the spec is implemented, so test suite has to tie back to specific assertions in the document. I've counted 13 external group signoffs.

normally I fight tooth and nail to reduce signoffs, but I wan't involved in this, and it can be concerning about those veto powers

manu: I don't think that was the intent....

liam: it wasn't the intent but it's what's in the charter
... it also includes privacy and i18n stuff

burn: we haven't talked about that but the chairs are aware

ChristopherA: there's a lot of out of scope stuff htat's becoming visible slowly on stuff with other groups. there is no other signing part of this group that's visible as part of this CR, in order to do this we may have to deal with signing methods and approaches
... I could see some groups saying your privacy sucks here
... all we can guarantee is that say that other standards can do that(?)
... I'm already running into other people making comments that may make an impact on the model

<Zakim> manu, you wanted to do what nage said

ChristopherA: the final spec doesn't include the signing so we should not be held to that standard in getting it approved

manu: nage and I had a discussion about how to do that including other exit criteria at IIW. one way to definitely kill the group is to pull the crypto stuff into the group, we absolutely don't want to do that and that's the way the charter was written. any "your crypto isn't as good as mine" discussion means that we need to be sure that the bar isn't set too high on exit criteria
... we can make things optional
... some of us are not going to do the anon cred stuff, but we want to enable it to be done. eg just plain old signatures

<Zakim> burn, you wanted to talk about review by other groups at W3C

manu: I think we have a good structure for that but we want to remember we're not on the hook to deliver that stuff

burn: I'm next on the queue, what i wanted to say as in terms of review by the group... it's also strongly encouraged that as early as is reasonable you encourage informal review as is possible by those groups
... I encourage that when your thinking is very fluid it's not a good time to get review by the group. if our group is too fluid it'll create confusion
... it may create a firestorm when you haven't selected what you want. when we have settled down enough then we absolutely want a review. so we have to absolutely want to
... we do want to do reviews as soon as reasonable because there will be comments
... that's why you haven't heard me talk about that yet
... manu and I disagree on how complete the spec is yet, that's why I'm hesitant to the "we need this group to review" yet

drummond: I just wanted to... I haven't been as active in the group, so I'm just getting up to speed on this particular question. two things: one, having support for zero knowledge signature formats is one thing that will help the working group pass the privacy scrutiny, and that's as much a question as an assertion. part two is understanding (because I'm not as up to speed) what needs to happen from evernym and sovrin to find out what to take action.

needs to be there to say it's on the table, and from a privacy / considerations standpoint say what's on there

burn: closed the queues

nage: I agree with privacy / crypto guarantees, there are differences in those guarantees that can or can't be implemented depending on what's in the protocol

<rschulman> (I'm enjoying following along here, and would like to do so longer term. Is there an IRC channel where all of the DID people congregate when not in an RL meeting?)

nage: to speak to whether the spec is complete, that bit is missing, the discussion around whether zero knowledge works helps bring together those parts. right now the serialization is that they're conceptually the same but... there are resources we could bring to bear on privacy and ? audits, which could be helpful for exit criteria, but I don't know what timing should be, and what time we should move forward... advice on when to bring them in would help

<Zakim> manu, you wanted to note that we're behind -- on reviews, on implementations, on test suite, just making sure everyone knows... which is why we're spending most of our time on

manu: so I just wanted to highlight the thing I'm most concerned about and that's that we're behind, and not by a little bit but destabilizing behind. we have a year left in the group and 6 months maybe to stabilize

<nage> Addition to the scribed comment I made earlier, there are resources we could bring to bear on privacy and security audits, which could be helpful for exit criteria

<burn> Now looking at pull requests: https://github.com/w3c/vc-data-model/pulls

burn: I'm trying to figure out the best way to go through this, we have a number of PRs that are overlapping in some way? Do you have a suggestion for an order that can be knocked through?

manu: I think so
... so I want to say I don't think any of these are controvercial
... so these are all assigned to me

<liam> ttps://github.com/w3c/vc-data-model/issues

manu: PR 155, so during DID hardening spec

<liam> https://github.com/w3c/vc-data-model/pull/155/files

manu: during DID hardening spec discussions, debate around whether signatures can be reused for specific purposes. one thing JWTs don't have is "I created a signature for this reason". If you don't have proofPurpose in there it enables an attacker ot say "here sign this" and you end up signing it thinking you're authenticating but you're signing vc

JoeAndrieu: how do you not know you're signing a VC

nage: our system handles this...

manu: this is "optional" depending on whether system has it

nage: it may be that where the object is placed in the heirarchy is off

<manu> cwebber2: I think a clear example of this is from the sandstorm community.

<manu> cwebber2: if you have a key that signs requests - you're a notary -- challenge response -- sign this to make sure you're you.

<manu> cwebber2: Here's a block of random garbage - base64 encoded thing - could you sign this to make sure you're you.

<manu> cwebber2: but it turns out that it's a base64 encoded verifiable credential... by accidentally signing this, this is a real attack, you trick someone into signing something that they thought was something else.

<manu> cwebber2: This is what kind of signature you're doing

<manu> cwebber2: for LDP it's necessary, for other systems, it's not necessary.

<manu> cwebber2: "I'm signing this because I believe your statement is true"...

manu: so the intent of this PR... let me phrase it differently, there's a security vulnerability with linked data proofs if we don't put it in here. it's supposed to be optional... if your signature says "use proofPurpose" you have to do that, if your signature suiste says it's not necessary, you don't have to do it. for linked data proofs, you have to do it, but for other systems it may not be necessary. there are a number of papers in the sandstorm

community where you show it's a real attack

manu: so the point is if you believe you don't want this for your signature mechanism, you don't have to use it. but if your signature system says it's necessary you must

JoeAndrieu: I don't understand the attack so I don't understand that attack

manu: we should take this offline, because taking this up to speed on the attack surface
... here's the question about the PR, should we bring it in if it's imperfect, or should we leave it out and try to draft something else
... my preference is to pull it in and make adjustments

burn: are there objections in as a starting point

DavidC: the only point I would have if it's optional it must be made clear it's optional

manu: so we say it's an example, it's non normative, and we say "if it exists"

joeandrieu: issuers don't need to have a verifiable profile so I think that last clause is not tenable

manu: this is part of the signature suite, I'm trying to figure out if we should rip all the examples out. I'm trying to give people guidance on how we validate signatures and proofs but I think we shouldn't be silent on this

<nage> Would it be better for this to be normative in the signature-suite instead of in the main data model?

cwebber2: is -1 on being silent

manu: so I could go through this to make it clearer with an example as non-normative to make it clear it is mandatory in linked data signatures but other systems may make it optional

agropper: editorially could we add another bullet

manu: yes

christian_lundkvist: I was thinking "verifiable profile of the issuer" sounds an awful lot like DID document

manu: yes and we have to discuss that today
... PR 154, examples in spec are wrong with how it comes to terms of use
... we have a terms of use field, the only language and vocabulary we can shove into here is the ODRL vocabulary. these examples are non-normative, all examples are non-normative. So this is how w3c specs are done. we have a terms of use field, I tried to look at ODRL spec and got very lost, and one of the chairs of the ODRL spec said you should do it like this, and here's that change
... this is non-normative, this change is to get more feedback from the ODRL folks. there is no normative terms of use thing in the spec, we're trying to get feedback from the ODRL community

nage: I understand lots of credentials may have terms of use, I'm worried about it's valid to the credential itself

manu: we can do that but again come review time people will say "what goes in the Terms of Use field?" It's pretty typical during review time if you don't give enough examples, and specs littered with examples get less review questions because people understand the type of example.

christian_lundkvist: are we saying this is an example of something you can put in a terms of use block?
... is terms of use part of the data model?

manu: yes because we were asked to do that
... ODRL folks wanted it

christian_lundkvist: but it's optional?

manu: yes

christian_lundkvist: personally I don't feel it should be a top level thing but if there are political considerations I think I am okay with it

ChristopherA: is anyone basically marking something in the spec that is informational but out of the context of verifiable
... it is a reference to the rules that are outside the rules of verifiacation
... something to bring validity already around that, but we don't have to interpret it

burn: closing the queue

<ChristopherA> I don't want things in spec that we have to verify. I'm find to pointing to metadata.

Drummond: as an example, it's important to shows the spec's support for this metadata about the claim
... but it's so broad that it's going about the exemplar

nage: the example of just a credential received, it's confusing that there are two paces

<ChristopherA> More precisely, I don't want things in data spec that requires us to validate things we can't validate.

DavidC: I wanted to say there's a PR about this that tries to tighten up the wording about terms of use to make it less ambiguous

burn: a PR number?

DavidC: will get it

<Zakim> cwebber, you wanted to mention that this is an adjustment to something *already there*

<DavidC> PR£146

<manu> cwebber2: I don't know why we're talking about termsOfUse in the meta - this PR is about adjusting the termsOfUse that we have.

<nage> when you have a credential that is itself a consent reciept, the "terms of use" end up in the schema's model in claims *and* in the envelope, making a confusing situation where terms locations are ambiguous

<DavidC> PR#146

manu: the group already agreed to put terms of use in the spec, we'd have to have a set of discussions about how it's done, this is literally just adjusting the example to be more correct, if people have concerns about terms of use, but I'm a bit concerned that none of these comments came in when the PR came in, which means people are not paying attention to the PRs and commenting when they come in
... we won't be able to handle the issue load we have

burn: we need people to work offline so we can save online time for things not resolved
... we don't have enough conference call time each week to get through things

manu: my suggestion is this at least fixes ODRL usage, other concerns about ToU should be in another issue

+1, merge it from me

burn: any objections?
... this is not an attempt to force something into the spec, it's an attempt to make progress

nage: my concern is about terms of use generally, but I'm not where to use it

<ChristopherA> +1 (I will try to find separate issue to TOS as an issue)

burn: file a new issue

<manu> scribe: manu

David Chadwick's Issues

burn: David, please focus on issues that need a lot of discussion - do not focus on things we can close quickly first.

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

DavidC: A lot of the issues are tied into a fundamental issue -- the data model is built on top of the Linked Data model.
... That's a major part of the debate/discussion. Lots of debate/discussion in the PR, I think the final result was that this was continually causing problems.
... Maybe that causes the root problem.
... The issues it leads to is an unconstrained data model -- any node, any node below it, you can add an infinite number of nodes below it... you have an unconstrained data model.
... Your datatype could be anything... we want to say "VerifiableCredential" is the type.

burn: You haven't picked a specific issue, you've picked a meta issue.
... I'm going to try to time box to 10 minutes.

<ChristopherA> David, is there one specific issue that more exemplifies this?

cwebber2: A couple of short points, we only have a year left, do we really want to switch out our entire data model?
... It's an open world assumption in a Linked Data Model, and people are concerned, but you can always map an open world system into a closed world system by saying "these are the types of things that we accept".

ChristopherA: I want the Linked Data model, I want a lot of the types of properties associated with that, but I do share a frustration w/ David. Regularly, I try something but issuer/subject elsewhere. There are a number of cases where there are implicit things that are challenging.
... I'm putting a request out to Linked Data folks to try and identify some of these implicit things, a lot of them have to do w/ IDs, who the issuer is, etc.

<cwebber2> decision on using linked data signatures / linked data proofs are not part of the data model

ChristopherA: That's my challenge to the team - find some of these implicit things and choose not to leave them open.

<cwebber2> that's a linked data signatures / linked data proofs discussion

JoeAndrieu: I favor an unconstrained data model because we shouldn't constrain what people say... elsewhere I think it's challenging. Anything specified should be able to specify something else - everything should have an ID... I can't make a claim about a claim, then that's a problem.

nage: I don't think we want to lose the value of an open data model, link to vocabularies, but unconstrained nature of envelope itself is a problem, we end up overloading the signature block in ways that things aren't constrained, too much power in signature block.

<Zakim> liam, you wanted to note that a data model needs to be complete/sufficient for implementations, we should explicitly state that as a principle

nage: Making claims about claims is a correlation problem -- this is where the Linked Data Model starts to become a problem for us... there is no one view of all identifiers for everyone.

liam: One thing I've noted as a consequence of an open world assumption is saying that the data model doesn't need to be complete. Our data model should have everything an implemetnation needs, but that doesn't contradict an open world assumption.
... An implementation doesn't need to reference anythign that's not in the spec.

<cwebber2> agreed up to the point of making a claim, but not what kind of data goes into the claim

<liam> [yes]

<DavidC> @liam +1

gkellogg: One open issue is on using a SHeX or SHACL constraint model - it allows us to prohibit types of things, cardinality, etc.
... The purpose of a constraint language is to enable some of these sorts of constraints that we want. For example, we don't want a property to be defined or more than one value.

<cwebber2> manu: I want to go back to something DavidC said, something I said in the issue, that this continues to be in the issue over and over again, but what I meant by saying that was not that this is a technical issue, but this is an understanding issue. when certain things are said, I think there is communication issue around the misunderstandigs. At this point json-ld is on 10-20% of all domains. I'm hoping I'm not hearing people say at this point to throw

<cwebber2> out a graph based data model and json-ld

<cwebber2> burn: DavidC as briefly as you can can you say whether your concerns exiast as you have them

<cwebber2> DavidC: I particularly like what liam said

<cwebber2> DavidC: we aren't constraining claims, and we do need to constrain the wrapper around it

DavidC: I do think it's possible to constrain the data model in a proper way... what is allowed, and what isn't allowed.

burn: We have to time box at this point... cwebber -- make a proposal.

<Zakim> cwebber, you wanted to suggest we specify that constraint

cwebber2: If we change the data model at this time, we're not going to succeed as a group.

<ChristopherA> Only required on envelope

cwebber2: Let's use one of those constraint languages, that's the proposal.

liam: For example, you need to be able to translate something into french, you have to say what to translate and what to not translate.

<ChristopherA> Or just say things like "generically issuer can be implied, but you must not imply it but make it explicit"

gkellogg: I commented on constraint issue -- there is an existing problem using SHACL/SHeX ... they currently work over graphs and not datasets... perhaps we can define something over the default graph.
... That is a current issue for SHACL/SHEX.

<cwebber2> I would even be fine with writing out the constraints in human language

<cwebber2> it doesn't have to even be SHAQL

<cwebber2> let's just say what the constraints are

ChristopherA: I'm reluctant... yet one more LD constraint thing... another technology in there... makes me itchy... "yes, well it's implied"... there are just 3-4 things in the envelop that should be implied

<DavidC> @cwebber2 +1 to natural language

burn: If there is a major concern in the group, shared by more than one individual, it has to be addressed.
... We have to address this, better sooner than later.
... Let's continue this discussion... focus direction, focus discussion on greatest concerns.

<ChristopherA> +1 on wrapper not be open, +1 on claims being open

JoeAndrieu: We have some ambiguity in the wrapper, I don't think the wrapper has an open data model.

<Zakim> manu, you wanted to ask for concrete changes.

<Zakim> gkellogg, you wanted to say “I think we need to define what we mean by Open Data Model”

<cwebber2> I withdraw my suggestion to constrain the envelope :)

<cwebber2> there's also notheing that says your application has to accept all claim structure

gkellogg: I agree with what Manu said, my point is that by defining what we mean by "open data model" -- anyone can say anything about anything. We shouldn't constraint someone else wrt. identifiers... I believe we can constrain what a manifestation about what a credential says. If it's good for us to constrain that approach, credential contains a proof with these elements and nothing else.
... That is in accordance w/ someone else being able to say something about that proof.

<Zakim> nage, you wanted to talk about the backchannel Manu mentioned

nage: To echo what manu said -- as a cryptographer you want the strong typing, but strong typing shouldn't dictate data model... any specific credential should have what you need

<cwebber2> we need crisper criticisms on the "this isn't crisp" vague criticisms ;)

nage: The criticisms that I hear a lot of is... "I don't like this"... I'm getting that from everyone for different reasons, can't get more feedback on it... there is an additional burden on us to articulate what we mean, perhaps give them pointers to how they solve this problem... it's obvious that implementers are running into same issues over and over, and are not satisfied.

DavidC: If the properties of a verifiable credential are open, and foobar receives... I have no idea what foobar means, but do understand every other field, know that credential was issued, what do I do w/ the credential, do I accept or reject.

<ChristopherA> https://lists.w3.org/Archives/Public/public-credentials/2018Mar/0005.html

DavidC: This is what I mean, what do we do w/ the underspecified data.

ChristopherA: The original version of this simple claims... id has the laternative name KimHD.

<nage> The specific type issue gets back to the same "purpose" problem in the LDSignature discussion earlier. The "what did you *mean*" when you signed this question is at odds with duck typing in the sense that I need to know that the thing you signed, meant something specific in terms of business rules, legal rules, and technical schema (vocabulary, types, ontology)

ChristopherA: It was the creator that said a claim... my basic comment is that that challenges me... issuer implies... make it explicit -- before email came out, talked w/ Manu, put issuer explicitly outside of proof.
... Every time I create an example, these issues come up, I have to go to David/Manu to solve those sorts of things.
... Simply, better examples, more people creating examples helps me discover things.
... Getting those to Chris Webber, talking about where we got confused, don't get issuer from creator... don't assume.

cwebber2: A lot of these concerns that are coming up ... is that these concerns are not crisp. We need people to file issues. If you're vague, we're not going to be able to do something about it.

<DavidC> I have raised a number of issues and PRs to crystallise these ambiguity issues

<Zakim> manu, you wanted to say its optional

<nage> cwebber2: this gets back to ChristopherA's point that this broader community is having a hard time knowing what they don't know

<cwebber2> cwebber2: let's make these "this isn't crisp enough" comments more crisp

<nage> +1 to trying to make these criticisms more crisp (right now most of them chose to just ignore me/us)

<cwebber2> manu: if you have foobar in the credential, should you accept or reject it? the spec doesn't say it, that's up to who's doing the application. if foobar is in there and you're accepting a medical credential which shouldn't have anything else, that verifier will reject it. so the open world assumption, if we constrain the open world assumption we're going to kill things. the best we can do is if we see someone put something into a credential or a claim

<Zakim> JoeAndrieu, you wanted to point out there are several issues

<cwebber2> and the verifier doesn't understand it, it's up to the verifier to decide. we can't as a group specify absolutely everything. and I'm really concerned that we say there are only 6 properties and let's lock this down, it's not helpful. the answer is, then if it's not up to the spec, to decide whether or not to let things through. it's not our job to do that.

JoeAndrieu: There are a lot of issues that are crisp -- David thought we might address them if we did it as a meta issue, maybe that wasn't the best thing.

<cwebber2> to be clear my comments on what nage said about criticisms he's hearing, not about davidc's comments

<cwebber2> and not about nage himself either, about "how do we deal with that community"

JoeAndrieu: Can't we require if something is not defined... "foobar" is in a vocabulary, go dereference it.

<cwebber2> JoeAndrieu, ^^^

<nage> cwebber2++ These complaints are vague and a "vibe" I'm looking for how we take the temperature of the crowd and figure out how to make this useful without having to get direct support from a JSON-LD expert

pelle: I'm in general agreement w/ openness, you decide what to accept, maybe that needs to be specified. People that are not familiar w/ JSON-LD, there is a cultural clash of what's going on, it does cause confusion... I have an ideal of JSON-LD and have ideas around principles of it.

<cwebber2> nage, I agree we should deal with that, we need to get those people to talk with us so we can deal with them :)

<cwebber2> nage, and some of that may be bringing things to the json-ld community group too

pelle: It makes it difficult to go in and make a PR, I have difficulties explaining it... can't quite point at what it is... something feels weird. I know this sounds vague, but that's why you're not getting PRs about it.
... I don't know what the solution is.
... I'd like to keep the open data model... I'd like people to understand things clearly.

DavidC: This issue around extensibility has been performed... for x509, critical extensions, you say "this is critical" or "not critical".

<Zakim> burn, you wanted to ask whether we want extensibility (as primary question before describing how) and to say that how this works cannot just live in Manu's brain

DavidC: SAML has similar things, Advice can be ignored / not ignored, there are ways to tell people whether something is critical or not, you have to say whether or not its essential to understand it, or not.

burn: If there is a vision for how something works, but others don't understand how things work... the issue is often, that issue is handled in one way... like pushing a squishy bag.

<nage> To Pelle's comment, one of my senior maintainers described it as "nailing jello to the wall" they continually run into problems and when they ask they are forced to reduce it to something specific that works, but that wasn't really the problem they were trying to articulate in the first place. So they leave very dissatisfied,.

burn: I don't know if this is an education thing, how can this be done w/ model being proposed... but this continual need to refer to specific people is not going to work.

<Zakim> manu, you wanted to note that this is an issue.

<ChristopherA> Maybe in a month if EVERYONE makes examples, this may go away.

<cwebber2> manu: when a good chunk of developers pick this up it seems strange to them, and that's a normal reaction... it's a normal reaction because it's a new way to think about things. It's a graph, not a tree, and there are all kinds of things you pull in. most devleopers are not used to thinking that way and that's why it feels strange. what we've found, the extensibility thing is not new to this group, that's been around for 15-20 minutes. that's how this

<cwebber2> group deals with extensibility and linked data for 20 years at the w3c

<cwebber2> burn: but that's one way to do it

<cwebber2> cwebber2: it's not just the manu approach though

<cwebber2> manu: it's not specific to verifiable claims and verifiable credentials, it's specific to linked data in general

<cwebber2> manu: it's just not how many developers think about this stuff

<burn> I'm not recommending a change, just pointing out that LD is only one way in W3C that extensibility has been done. It is not a bad way, but people need understanding on why that way is a good way.

<cwebber2> manu: we have 6-7 years of experience, lots of adoption through schema.org and many others, hundreds of thousands of developers using json-ld. they do cargo-cult copy-paste. schema.org website has thousands of copy-paste examples. not having enough copy-paste examples...

<cwebber2> manu: we need more examples to show how this is done

<cwebber2> manu: most of the deployment of linked data, html, json, whatever is is through cargo cult copy and paste, that's why html5 is the way it is, why json is so popular, etc

<cwebber2> manu: I absolutely hear the concern, and we have the same feedback asked to people to create, until we hand people a library and then they stop asking

<cwebber2> manu: the reason we're having a deeper conversation in this group is people fundamentally care about how it works

<cwebber2> manu: when it gets put out into the real world there's a lot of copy-paste

<cwebber2> manu: this *is* the normal reaction

<cwebber2> manu: when it comes to broad scale deployment, things seem to go fairly ok

<nage> I would like to point out that my community already has a library that doesn't work this way, and my push back is that they say they like what they have better (I still think there are compelling reasons to move them forward, but cannot do so without answering these concerns).

<cwebber2> manu: the final point, it can't all be in my head, I agree, but it's not, it's in specs

<cwebber2> manu: unfortunately if people want to learn this stuff in depth you have to learn these specs

<cwebber2> manu: I'm happy to try to explain but there's so much there

agropper: I'm trying to understand, from that perspective, I'm caught between two concerns -- regulatory capture and pelle's point, don't feel competent to comment on what's been going on in this discussion.

<cwebber2> agropper: I'm trying to say or understand and play my specops role here, and it's very hard. from that perspective I am caught between two concerns. regulatory capture is how I understand things in health care, and pele's point that I don't feel competent to comment on much of what's going on in here

agropper: My suggestion, goes back to original RWOT

<Zakim> JoeAndrieu, you wanted to point to new issue https://github.com/w3c/vc-data-model/issues/156

agropper: If there were a time/place that would go through prescription use case, so I can map open world assumption, I can understand what this issue is... in framing, regulatory capture... prominent in case of healthcare, then I can contribute, otherwise I'm comparing shoes.

<cwebber2> agropper: my only suggestion goes back to the original RWoT talks. if there were a time or place which goes through the prescription use case so I can understand it in the framing I'm concerned about which is regulatory capature then I can contribute, otherwise

JoeAndrieu: I added an issue... how does an issuer put in an extensibile property
... I think if we had a section on extensibility, that would help

<Zakim> burn, you wanted to ask if a 'developer example-creator resource' could be made available

DavidC: Manu said this stuff is used for Google Schema.org... but what we're doing is writing a security spec.

<JoeAndrieu> good note, cwebber2, which is why we should document how we do extensibility

burn: It feels like we have people in the group that have strong knowledge/experience, but people that don't have JSON-LD experience.
... The answer is to find someone that knows the language to find out.

<ChristopherA> Once the JSON-LD playgrounds are updated with 1.1 & more recent signing, I'm prepared to try lots of weird Verifiable Claims examples.

<Zakim> manu, you wanted to volunteer people.

<ChristopherA> I just need a JSON-LD tool that is more current.

burn: If we had people in mind that we can have create examples, that might help.

<cwebber2> manu: I hear a lot of concerns but can we at least agree that the graph model and json-ld, and that an extensibility section would help

Drummond: There are a lot of parallels w/ what happened w/ DID spec, only this is a much larger stage, much richer than DID Documents. We got to a middle ground where two parties could agree, don't know if that's possible here.

<cwebber2> +1 likewise

Drummond: I do see Manu's point, you need to pick an extensibility model... if you don't want to use that, then you can limit it.

<Zakim> liam, you wanted to note 2 kinds of extensibility, explicit/implicit, x-* vs LD, and relate this to security

<ChristopherA> Who is working on JSON-LD playground to 1.1? ETA?

<ChristopherA> Any better tools to evaluate errors?

liam: There are two primary kinds of extensibility... explicit and implicit -- explicit extended properties begin w/ x-.... implicit - shove extra properties in

<Zakim> manu, you wanted to add to Drummond's point.

liam: a compromise is explicit extensibility -- these properties are extensibility points... may be a good compromise.

<cwebber2> manu: drummond is right that this is done in the did spec but this is richer, we have done this though in json-ld and we have had successful rollouts in schema.org, activitypub, etc. Other working groups have worked through this, we've had a successful marriage between json-ld and tree and graph people, we've set extensibility through json-ld in the group, we've had years working on this

DavidC: Thank you, glad we had this discussion -- liam said something -- we have to treat this as something different , it's a security spec, good documentation in data model spec could address these issues. We want people to read data model document as standalone document, describe fixed fields, verifiable credentials, type information, by doing that, we can eliminate many of the problems we're encountering.

burn: Our scheduled lunchtime is in 1 hour... need to figure out what we're doing for lunch... will need to step out of the room.
... Very tempted to have us take the lunch break now... give an opportunity for informal discussion, best proposals come out of lunch discussions, may help people clear their heads a bit.
... Will try to reconstitute agenda...

Break now until 1pm PT... not sure what we'll continue with, but will know in an hour

<christian_lundkvist> Starting minutes

<burn> scribenick christian_lundkvist

<christian_lundkvist> burn: Joe + stonematt will talk us through "Focal use case direction and examples"

<christian_lundkvist> joeAndrieu: In previous examples didn't have a lot of stuff around revocation etc but more basic stuff

<JoeAndrieu> https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit

<scribe> scribe: christian_lundkvist

<scribe> scribenick: christian_lundkvist

joe: Will give an update

<JoeAndrieu> https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit?usp=sharing

stonematt: Will start with a complex journey/problem and derive more simple problems from that to put things into context

joeandrieu: Want 1-3 use cases. Specicially with subject != holder. Marriage license has 2 subjects
... 3.1 "Citizenship by parentage" in the above Google doc

joe: Example where the mother's name changed between birth certificate and present day

joeandrieu: 3.2 "PADI expert instructor" another focal usecase
... What would the 3rd focal usecase be? "Citizenship by parentage" and "PADI expert instructor" are the two now

stonematt: In the data model spec we can show a usecase where these examples are shown in detail

<Zakim> manu, you wanted to say structure is great, are we replacing/updating use cases?

JoeAndrieu: Want to create detailed JSON-LD implementations in another data model doc

manu: Think structure is great, is this a new document that's augmenting or replacing the usecase document?
... Are we getting rid of some of the simple usecases that was in the usecase doc?

JoeAndrieu: First skeleton is keep everything, but want to see how it holds together before making a decision
... Second thought is TL;DR problems

agropper: What is the hierarchy of trust in the citizenship example?
... Who is responsible for verifying the credentials that go into the profile?

JoeAndrieu: Can break that Q out as a section
... Legal onus is on Sam - it's his fault if he's lying about his mother

<Zakim> cwebber, you wanted to suggest having basic and advanced use cases sections

JoeAndrieu: Section would be useful

<Zakim> burn, you wanted to disagree with chris :) but something similar

cwebber2: May not be bad to have sections "basic examples" + "advanced examples"
... In the usecase document. Potentially two documents

JoeAndrieu: We have a mandate to create one document, I'm hesitant to create 2

burn: Agree we need both simple and complex examples. Perhaps we start with focal ones, and then say "BTW here are other ones" for the simpler ones

manu: Like that idea, would be nice to lead with something that everyone can relate to. Most people looking at the document have a drivers license so that's more relatable

stonematt: Maybe wait until we have a document that we can all review. Don't want to go too far down the line, let's make a doc that we can all comment on

liam: We have some areas in our charter that we should focus on. Would be smart to have things on there like delivering educational content being among the focal usecases.

JoeAndrieu: education will definitely be among them

burn: Would anyone like to speak to progress that was made on the JSON-LD topic during lunch?

manu: Joe logged issue talking about extensibility. We as community should create a bunch of examples. This would help us engage more. Dave Longley is watching issues closely
... We have a VC examples repo but it needs more stuff in there
... Outcome is we are not dropping JSON-LD on the floor, we want to write as much spec text as possible backstopped with a lot of examples

gkellogg: Worthwile to do validation of examples to make sure they fit within the scheme, if there are vocabulary changes we need to update the examples

gkellog: Would be nice to programmatically extract examples from the spec etc

burn: Asked matt to take a look at outstanding issues, also manu would like to cover a big topic. How could we timebox that?

manu: Issue I think we need to discuss as a group is not on the schedule
... Issue is Verifiable Profiles. A lot of stuff in data model is locked down but Verifiable Profiles is something that's a bit loose
... If we can come to an agreement of that that is we can lock that down as well

<cwebber2> manu said bag, I'm sure we all agree it should just be called bag :)

manu: Can do X minutes of discovery of VP: what's the problem etc, then do discussion about if we should still call it "Verifiable Profiles" or call it something else?

burn: We'll spend 30 min talking about Verifiable Profiles

cwebber2: My big concern is we haven't locked down what the "flexible proof section" is. Maybe we can have a call later, but important we don't forget it since to me it's biggest thing for my implementations

<nage> I've said this before, Sovrin's implementation calls credentials credentials, the presentation of credentials proofs and the presentation of multiple proofs composite proofs (we don't have/need the construct of profiles at presentation time). We use a construct similar to a credential for self-signed data and then just think of the "profile" as a composite proof

burn: It is important but is somewhat separable from other discussions. like the idea of scheduling a call
... Is an hour enough to make progress?

cwebber2: Should be enough at least to take the rest offline

burn: Send me an email about it

manu: Verifiable Profiles: What happens when we need to bundle up Verifiable Credentials?
... Someone says "I need to have some credentials". You bundle those in a Verifiable Profile and send it back
... What to call it? Presentiation or Verifiable Profile?
... Digital Bazaar views it as some aspect of the Holder, so it's like a Persona, aspect of Identity etc
... When we talk about DID docs we (DB) see them as Verifiable Profiles

<Drummond> What about keeping it simple and calling a set of credentials a "credential set"?

<cwebber2> https://shed.bike/:)

manu: When someone says "give me these credentials" you hand over either credentials or a DID doc? Can both be Verifiable Profiles, but maybe we want to separate DID doc from bag of VCs

nage: In Sovrin we present a ZKproof so for us a Presentation is more of a single ZKproof generated from multiple credentials
... May introduce a "credential set" as being different as a Presentation (zk-proof)

pelle: what we've (uport) has modelled so far does not follow these specs. We need to present some information to end users when they disclose credentials
... Imagine we have a selective disclosure request, then is what we get back a VP?

Drummond: Strictly terminology suggestion: The term Profile threw me off because very overloaded in ID circles. Why not a term like "credential set"?

JoeAndrieu: have need for holder to hold self-asserted claims, question around if individual is self-signing claims or just put more claims into one credential

<Zakim> stonematt, you wanted to say are they ephemeral

JoeAndrieu: Sam in example could put a bunch of stuff in one credential or sign multiple things, or have an envelope containing all the claims

<Zakim> manu, you wanted to add one other item

As a verifier the things that are presentaed to me is something I'll hold on to, what is the requirements on a presentation in that case?

JoeAndrieu: Is the ID in the Profile corresponding to the holder?

manu: I would assume the ID of the Profile is the ID of the VC?

Joe: I think it should be the ID of the Profile.

manu: This is a separate issue, we will have that discussion later
... Adding data point: Since it's a graph model all the VCs in the container talks about an aspect of you that you are transmitting
... Since we are talking about a Profile it should be referencing the subject

JoeAndrieu: I think that's semantically incorrect

cwebber2: This confused me as well in the beginning.

cwebber2 works through example:

cwebber2: Suppose we have Alyssa with did:alyssa. She has info name, bday etc
... Also has a corresponding graph to this document
... Now suppose someone wants to say that Alyssa has a certification as an engineer

have a graph <a> - cert - eng

{"claim": {"id": <a>, "cert" : ...}}

<Zakim> nage, you wanted to talk about how this profile id doesn't work for non-correlation tech

cwebber2: this VC creates an extension of her original document

nage: In our case our proof format will implicitly bundle things

manu: You don't have to put the ID in there, if you don't you get a random auto-ID. In your case with zk-proof you wouldn't need it

nage: That object would then look like our composite proofs

<Zakim> JoeAndrieu, you wanted to challenge the notion that referring to the DID is referring to the referent of the DID and to

cwebber2: This could be used to do a credential to an anonymous person

JoeAndrieu: But this would then not be a VC since a VC has an ID that references the VC itself
... In this architecture you didn't give me a way to give a statement about the statement itself

Drummond: You guys need XDI :P
... We have to make this clear in the spec where "id" sometimes means the credential and sometimes means the subject

<Zakim> nage, you wanted to talk about linking silos of data (self-soveriegn)

Drummond: People are going to be confused, even we are confused here

nage: We don't want to use any of the identifiers. The thing that is the subject is according to the issuer.
... I'm hoping that the data model will allow us to express this without putting everything in the signature block

<nage> Pre-emptive response to manu. No, you can't be *forced* to use the same DID everywhere. Even if you expect you must for data understanding, you have to accept that for data cleaning and maintenance reasons, this *never* happens in practice. Medical MPI systems are a clear example of this disaster.

pelle: Think people are making good points about the "id" being the ID of the profile. However we may be introducing a clash here in that we sometimes mean different things

Drummond: pelle has good point, that when you reach the top (DID doc) you are clear on what the ID is. It's very important that we are clear in the spec what we mean. It's a graph issue

<Zakim> manu, you wanted to nage -- the thing that ties all of them together is the DID

Drummond: When nage speaks about claims vs proof: the separation of claims and proofs add complexity, but its our (Sovrin's) job to explain the context. If we don't explain it we get confusion about what we are doing

manu: nage's question is "what ties these things together" and in the anoncreds example it's not the DID, but in the other usecase it is the DID

burn: To manu: Is there a conclusion here?

<nage> Even when it is the DID there are data cleaning and error cases where you have to prove they tie together. If you need that language for fixing problems, it might also work to help non-ZKP systems understand what the ZKP systems are doing

manu: We can do a PR with the difference where we have an identifier or not to see the difference between anoncreds and other usecase

burn: manu thinks that a pull request can do this.

Drummond: modulo nage + manu having a discussion

<manu> christian_lundkvist: This is exciting, seems like presentation or profile or whatever we call it... can encapsulate both a set of verifiable credentials or a set of proofs about certain attributes, etc.

<manu> christian_lundkvist: This is important, this may resolve one of the biggest sticking points between Sovrin model and other models

<manu> christian_lundkvist: We don't want to say the identifier in the profile needs to be the DID

<manu> christian_lundkvist: because that conflicts with the sovrin model

JoeAndrieu: What about the statements made by Sam himself?

manu: Those could be verifiable credentials signed by Sam

<nage> The two constructs can be solved by having a distinction between authority and signature of the enveloped object

Drummond: Big +1 to what christian_lundkvist said - we really want zkproofs to be something that's part of the standard. We've been trying to figure out how it fits into this group. This is the most positive thing I've seen. And if manu and nage can agree on a PR that would be great
... Don't want to be in a situation where we want to do anoncreds to protect privacy but we can't because it's incompatible with the spec

burn: Want to switch and talk about "Related Content" issues
... A number of issues about "other stuff" like Evidence, images, representations

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

stonematt: Some ideas come up again and again. One Q we should answer right away is are these equal?
... Different things are sucked into the same discussion and we need to tease them apart

JoeAndrieu: These four are not about evidence

stonematt: I might have missed some here

JoeAndrieu: you are right, I see evidence now

pelle: Quick Q: Why is a picture considered different than a claim?

<Zakim> manu, you wanted to talk through a high level on each one.

manu: People making the points are from outside (which is good!). People are saying "you need to address graphics formats" but that it's out of scope
... They wanted images in the claims themselves, wanted images of the claims itself (badge graphics), also wanted evidence (this is the documents they provided that they are a certified physician etc)

<Zakim> nage, you wanted to emphasize not signing pointers to mutable data

<Zakim> burn, you wanted to ask pelle's question again about why these images are not credentials

nage: Let's not discriminate, metadata is also data. We should leverage the JSON-LD specs for this. We need to be able to link to immutable sources. What I can't answer is if current formats are friendly to that?

burn: Want to ask pelle's question again? You probably don't just want to attach it, you want to make a claim about it

<Zakim> manu, you wanted to say about mutable data and linking to it

manu: Multiple ways of including an image: Can inline the image if it's not too big. Otherwise must link elsewhere, can use ipfs links in a URI. Schema.org Image expects http based URL
... People are asking "why are you not working on content addressed images" but that's not in scope for us

<Zakim> JoeAndrieu, you wanted to discuss referring to claims

nage: Can we just include the whole image? manu: That's very large. nage: Is that a big problem?

JoeAndrieu: Have credentials with five claims. can we attach an image to each claim? Not possible since the claims themselves are not addressable

<Zakim> nage, you wanted to say amen and ask if there are different trust properties couldn't you issue multiple credentials and provide a presentation of both

Drummond: how to reference claims? Needs some text in spec for this, but it's a big issue (graph models)

<manu> christian_lundkvist: Consensus seems to be that this is out of scope for us to have a clear prescriptive way to do this

<manu> christian_lundkvist: All that is needed is to say "here are two ways to do it"... put data in VC.... or use schema.org and link to ipfs gateway, it is HTTP, but if system is IPFS aware, it can change to immutable link.

<Zakim> manu, you wanted to note two ways about how we /could/ do content addressed claims

nage: Consistency in time is important here when revoking etc

manu: How do we do content addressing of claims individually? You can do content addressing through canonicalizaition, but probably don't need to solve it right now. There is a way to attach metadata to claims. if you want to be able to be very descriptive you can add a lot of data through content addressable links

nage: we do content type encoding

burn: No one else on the queue, do we have a plan now what to do with these issues?
... Maybe some general understanding what to do?

manu: We (manu + dave longley) will do PRs for all related content issues

burn: Next issue #72 - delegation + attenuations of rights

JoeAndrieu: If you are not a subject holder or issuer you are not in the spec

burn: Are there political requirements like GDPR?

JoeAndrieu: Those obligations are for the data controller or processor for the subject

burn: The technology does not need to specify those things

JoeAndrieu: What would a controller need to do to wrap data to send to a processor? Might just be a Verifiable Profile?

cwebber2: David Chadwick suggests merging object caps and verifiable claims
... manu suggests having that in a specific ocap track
... VCs is a correlation mechanism - way to express claims about somebody. Interesting bit about termsOfUse may say things about if it's acceptable to disclose or spread those things
... May make sense to separate VCs and ocaps, may make sense to have termsOfUse section more as human policy than programmatic ocap stuff

agropper: I don't think it's a rathole, I have deep experience with UMA delegation model which is highly applicable to GDPR
... In healthcare space interesting this in the following sequence: research owner alice says to hospital : "delegate access control to VA"
... VA hospital can attenuate the token that comes from the delegate
... The only way it holds together is for authz server to attenuate the scope of the credential, and the resource server needs to further attenuate the credential
... That's why I introduced UMA to RWoT
... If you don't do it you need to bundle resource server to authz server which has problems

JoeAndrieu: Can a capability be expressed as a credential about a credential?

manu, cwebber: think would be bad idea

manu: Can be confusing. If we make everything a credential devs may be confused

pelle: Like the capability idea, could make sense for it to be a credential.

<Zakim> manu, you wanted to suggest a concrete way forward for this issue.

pelle: also makes sense for clarity for them to be separate

manu: want to make clear distinction: you use a verifiable credential in order to prove something which allows you to get a capability so you can do something
... should not do attenuation as VC

agropper: Think what I'm hearing is VC component only has to deal with presentation of cred to authz server and has nothing to do with caps

JoeAndrieu: disagree with that

cwebber2: Gives example with Xerox copy: HP is customer of Zebra copy, they have widgets w1, w2
... HP has employees A, B, C who wants to access the Zebra widgest
... Using ACLs is tricky since need to copy the HP ACLs over to Zebra
... Using ocaps is much easier here: Zebra gives HP a capability to access w1. HP gives an attenuated cap to group G1, G1 gives further attenuated cap to A and C etc

agropper: There is 2 kinds of creds going around: 1. The ones the requesting party gives to authz server, 2. the ones given by JWTs with scopes etc. to the extent I'm giving a real-world usecase there seems to be 2 different kinds of creds/tokens

JoeAndrieu: We have not talked about holder giving an credential to another holder which is attenuation

agropper: simple point: issue in terms of delegation: In UMA it doesn't have to be a bearer token, could be a token that says "go ask me"

cwebber2: you can have a cap that is an entry point for getting more stuff. Maybe Joe and I can have a discussion during break

<manu> christian_lundkvist: JSON-LD capabilities are one thing, it has its own track... verifiable credentials are a different thing and has their own track.

burn: Let's make sure we include David Chadwick into the conversation

<manu> christian_lundkvist: for example -- we may want ocap-ld to use verifiable credentials...

pelle: Caps are separate from creds but they can live together

<Zakim> cwebber, you wanted to say I added a framing to the issue

<JoeAndrieu> how do I make myself scribe?

<manu> scribenick: JoeAndrieu

cwebber OCAP-LD editor is wary of taking on doing it as Verifiable Credentials

cwebber: can we delegate policy information?
... might be useful for terms of use
... delegation is easy
... just a matter of handing it off
... the question of ...

burn: I don't agree delegation is as easy as handing it off

cwebber: what are you going to do with it?
... if we're not treating VCs and OCAP as the same, we are just sharing information
... saying someone is sayin something about someone else
... it's not about what you can do, but what you can share
... so its out of bounds of the machine, but is in th realm of human action
... e.g., I have some medical info (from you), and I'm sharing it with Manu, but I don't want Manu to share it with anyone else
... I could wrap that in terms, but that can be stripped off
... Linked Data includes an algorithm about whether or not an operation can be performed

burn: I think nathan george would have something to say about this.

<Zakim> manu, you wanted to say these things are very different and we'll need time to show how they're different and perhaps we can defer this item or assert that there are very strong

manu: in attempt to close issues, we've gotten somewhere, which is that delegation is possible and representable via verifiable credentials, that delegation is important
... there are deep concerns about mixing VCs and capabilities and we aren't going to be able to resolve them today
... we can add it to the data model later one
... with this issue, the question is whether or not the group is going to handle it?
... There's no problem with kicking this back into the credentials group. It's not preventing us from getting some of the core use cases done.

<Zakim> JoeAndrieu, you wanted to say the human is not computation

<manu> JoeAndrieu: termsOfUse for information is going to invoke the human, not computational, I can still sue if termsOfUse are violated.

cwebber: terms of use is going to invoke a human process, not a machine process
... if we agree on that, then we did demonstrate that it would always be possible to strip off the attenuation and get the raw data.

<Zakim> manu, you wanted to move on to another issue.

cwebber: There is nothing stopping you from peeling of that outer layer

<manu> JoeAndrieu: What you're talking about is the analog hole, and it exists, and you can sue people over it.

manu: I'd like to move on to another issue.

+1 to moving on

<Zakim> burn, you wanted to ask whether we enable a technical enforcement of human-determined terms of use

manu: I think there are other issues we can make progress on

burn: I was next on the queue: do we plan on enabling any technical enforcement of human terms of use.

christian_lundkvist: I just wanted to say I feel like this issue was a bit broad to begin with. "How do we support delegation". That's a whole research project on its own.
... so I'm not sure how we can do anything but say it is out of scope
... We should probably not preclude it, but its probably out of scope

burn: this is nice, all well and good, but this question WILL come up again. So what will we say? Just "It's out of scope"?

manu: We'll say the CCG is handling it. For human style, we have ToU, for computational, we have OCAP-LD in the CCG

liam: it can be useful to have use cases that we note are not testable, or are out of scope

burn: there is some work
... is there anything else we need to discuss?

cwebber: the question is can we close it?

manu: we can put in a PR and that would let us close it.
... chris is going to write a PR that will go into the spec

burn: there is a question of what to do now
... I don't think that any of the issues we put off as needing additional work, none of them seem useful to discuss now
... Matt & I had thought we'd just work through the list.

<Zakim> manu, you wanted to suggest a few items to discuss in closing.

manu: I have a few to suggest

<ChristopherA> @manu: @cwebber2: discreet (not a typo) log contracts https://t.co/ZgTswlKL2B

pelle: we can primarily use JWTs. I just want us to have as much interop between jwts and VCs.
... we need them to be JWTs for transport reasons
... maybe I could just do a PR
... a first draft of improving that a little. being more detailed about how these credentials look like as a JWT v JSON-LD
... mainly that JWT has fields that have the same name as some of these, and I would prefer a mapping

burn: we started with multiple mappings in the past

<Zakim> manu, you wanted to provide background on JWTs.

manu: this work started out using JWTs. We were pure JWTs five+ years ago.
... High level: yes we want interoperability
... after conversations with Mike Jones and John Bradley, we decided to use JOSE JWS and the latest signature thing
... we are open to other standards as long as they make sense
... the problem with JWTs is the base-64 encoding thing. If you want to next credentials, it made the JWTs giant giant files
... because of that, we said we wanted to be able to compose these things together.
... the other problem was compatibility with schema.org data
... wouldn't it be nice to be able to just add a signature on top of schema data.
... Google wants to enable vendors to publish priceses, WITH signature with a way to verify what the real price is.
... JWTs would not work particularly well for that use case
... Third reason is we needed to do normalization.
... All that being said, there are reasons we didn't use JWTs.
... The spec did have a place where we tried to map JWTs to our current data model.
... The concern is that if we do both JWTs and LD-signatures and LD-Proofs, then the toolset you need to verify these things are going to grow.
... I don't think we should prevent someone from doing that as long as it doesn't throw a wrench in the interoperability
... Also, signatures are totally out of scope for this group. I'm not sure where that conversation goes.
... Sure, put a JWT in the signature. You can do that. But then the question is why?

pelle: a lot of the use cases Manu mentioned have nothing to do with our use cases.
... most of our use cases are just packets of data being sent as QR codes, push notifications and push notifications that you can expand to get stuff.
... for those purposes JWTs are way more suitable.
... that's why I think there is space for both of these. There are only 4-5 fields that map.
... yes, there are some complications.
... We'd have to ALSO support JSON-LD, but we can't change our current data model. So having to us JSON-LD is a deal killer

manu: if you need to wrap in a JWT, that's doable.

pelle: in our flow, we really need JWT.
... we are open to other flows, we are open to supporting other formats. For us, focused on mobile, we really need the convenience of JWT.
... I will come up with a PR. I'm sure we can find some way...

<Zakim> manu, you wanted to ask if it changes the data model

pelle: once we get a way of getting the JSON-LD VCs into our system, we'll support it.

manu: does it change the VC data model in any way? Or is it just wrapping it? So does that mean there is nothing to change in the model?

pelle: no, just rather than repeating certain fields, instead of a full VC inside a JWT, let's just promote those fields into the JWT.
... there are a lot of people that have expressed interest in that.

manu: the only two concerns I have (for you, not for the spec), those JWTs can get fairly large.

pelle: yes, maybe there are some ways to help with that.
... instead of having the credentials in the credentials, expanded out, maybe the jwts are just in an array.

manu: the working group has the option to break into any pieces we want.
... that would be a separate spec, fully standardizing in W3C as a recommendation

burn: I was thinking the same

manu: that would be a wrapper specifying how to pass VCs in JWTs.

burn: and that can proceed somewhat independent of the core spec.

- DRAFT -

Verifiable Claims Working Group F2F meeting SFO

06 Apr 2018

Attendees

Contents

David Chadwick's Issues

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output