Meeting minutes
<TallTed> zoom.app says "An unknown error occurred ... Error Code: 100000502" and prompts to join thru browser (hate hate loathe despise overloading browser!)
<ivan> Date: 2022-09-15
<SamSmith_> I am getting a bad gateway on the zoom link
<Orie> zoom seems to be 502
<brent_> new zoom meeting room: 492 908 0639
<brent_> passcode 2022
<TallTed> one click to join new room -- https://
<SamSmith_> zoom just died
<Kosuke_Koiwai> I can't hear anything
Introductions and Welcome
brent_: Welcome everyone, we have a full agenda today and tomorrow. Let's start off with some logistics.
brent_: We are meeting under W3C IPR protections, welcome to observers, but if you have not agreed to IPR policy, please don't share anything that concerns IPR.
brent_: We expect you to wear a mask, take your daily covid test, and practice good health practices throughout the day.
Slideset: https://
brent_: We are going to have 4 scribes throughout the day, we have a sign up list.
brent_: Please jump into this slide if you're willing to scribe, if you want to jump in, please add yourself to the scribe list.
brent_: We are live in zoom and IRC, if you want to join the queue, we can add you to the queue.
brentz: I think that's mostly logistics
ivan: please present+ if you are in IRC
Agenda
brentz: We are going to start out by talking about use cases. We will then break, then talk about transformations of core data model.
brentz: We've already decided to split up securing VCs into separate specifications, JWT and Data Integrity
brentz: In the core data model, properties for credential and verifiable credential. We are going to talk about where serialializations should go and where to specify them.
brentz: Then break for lunch, then joint meeting with accessibiity WG, they want to talk about use cases that they have.
brentz: We'll spend the rest of first block of afternoon about cryptosuites and Data Integrity streamlining.
<Orie> Awesome context setting Kristina. Thank you.
brentz: We'll finish off the day with VC Extensions registries, where should they go, then introduction to AC/DC. Full day today. These are the three primary topics that WG discussed as "the big questions" for the group.
kristina: We are not necessarily trying to reach conclusions, we want to know a direction so when we work through issues/PRs we have a direction, we can streamline conversations. Please be productive, talk to each other, don't try to block -- trying to be constructive and agree on direction so Editors and members are clear on next steps.
ivan: This is a big room, we all wear masks, there are people around table w/o english as primary language -- articulate, don't be super fast when you talk, please try to be loud.
brentz: If you are scribing, you have the power to stop the meeting.
brentz: (to ask people to repeat what they said)
Mission and Goals
brentz: Our mission is to make expressing, exchanging, VCs easier and more secure on the Web. It's what we're here for.
brentz: We have these deliverables in progress -- VC 2.0, Data Integrity, JWT, JWS2020.
brentz: This is what is in progress.
kristina: If people are familiar with Linked Data Proofs, that has been renamed to Data Integrity.
brentz: Some of these are in working draft stage, some are pre-FPWD, WD doesn't imply consensus, it's a working document to get comments and feedback. Once the group feels that the work has progressed, it's done, ready for implementation, we make it a candidate recommendation.
brentz: We enter CR when we feel it's feature complete, review by privacy, TAG, etc. In order to leave CR, we need implementations in place, normative requirements need multiple independent implementations.
brentz: once we have proof of implementation, we do proposed rec to see if rest of w3C agrees. REC doesn't mean done, it's "done enough" -- we are working to improve VC 1.1 REC.
brentz: We have until June 2024, we need to go into PR by May 2024, it feels like a long way off, but it's not. We need to go into CR by september of 2023 to do a 2nd CR, we have about a year to get everything done with our primary specification.
brentz: This is also the timeline for every other normative spec, we need to have thigns wrapped up in a year, we have a lot of process to go through to finish them, etc.
brentz: This means that for primary spec, we are looking at march next year for feature freeze, that's about 6-7 months out.
brentz: Goals for this meeting is to make progress on core data model, transformation, border between DM and securing VCs, disposition of non-normative content, data integrity streamlining, vc registries, test suites.
kdeangs1: We've stated in charter that we're not comitted to backwards compatability.
<Orie> +1 to breaking changes to fix things!... when we need to.
kristina: Yes, but we do not want to do breaking changes without deep consideration.
<mprorock> +1 esp. on the when we need to
kdeangs: Yes, we don't have to go in with a sledge hammer.
brentz: When you introduce yourself, name, and something interesting about yourself.
brentz: Hi, Brent Zundel, I'm here representing Norton Lifelock Avast Evernym. The song that was in my head was The Smiths, lyric was "if a double decker bus crashes into us to die by yourself is such as heavenly way to die"
brentz: I don't know why that was in my head.
Kristina: Hi Kristina, I represent Microsoft, song stuck in my head "Man on the Moon".
Cole_Davis: Hi Cole, Switchboard, I have had Miles Davis in my head.
Dave_longley: Hi Dave Longley, Digital Bazaar, the most recent song stuck in my head was "What does the Fox say", intersting trick, if you're able to do short jingle in your head, you can stop rememering the song by doing tat.
David_Chadwick: Hi David was on University of Kent, founded Verifiable Credentials LTD, bought by crossword cybersecurity director of identity.
David_lehn: David Lehn with Digital Bazaars, working w/ DIDs, VCs, etc for quite some time now.
Jay_Kishigama: Jay from W3C, song in my head ... is "Saturday in the Park by Chicago"
Kosuke: Kosuke from KDDI, BTS in my head at times.
Prorock: Mike Prorock, Mesur.io work w/ VCs/DIDs "big city" in my head right now.
Orie: Orie Steele, CTO at Transmute, work with VCs/DIDs -- song in my head is Linkin Park -- crawling in my skin, these wounds they will not heal.
Osamu: Osamu, Osamu from Keio, overseeing some of this work there
Paul_Dietrich_GS1_: Paul from GS1US, work in innovation group on digital identity work -- "I look just like Bob Dylan"
Reisako_Hamano: Risako, software engineer at yahoo Japan.
RyosukeAbe: Riosuke Abe from Keio, working on DID with Shigeya
Sam_Smith: Sam Smith independent general partner with Digital Trust Ventures, Prosapien, working in this space for a while, most recent work is with AC/DC and KERI and one adoption vector is VC / identifier credentials.
… was former interim chairman at Sovrin, Dwarf song from Misty Mountains.
TallTed: Ted Thibodeau, OpenLink Software, working with everything Linked Data, VC, DIDs, x509, etc. I have no song in my head, rejoicing in my heart from a new fridge.
Chris_Abernethy: I'm Chris with mesur.io working with VCs for supply chain interop.
JohnBradley: John from yubico, sex pistols god save the queen.
DavidWaite: David from Ping Identity, alternative have screaming trees I nearly lost you in my head.
Sebastian: Sebastian working id.now, recently working on electronic signatures, work with ETSI, EUDI, FIDO Alliance, interested in work here could reach entire population for EU eople. <scribe missed song>
Shigeya: Shigeya Suzuki from Keo, marble machine
JoeAndrieu: Joe from VC Editor of Use Case document, song in my head, C&C music machine everybody dance now.
DavidEzell: David Ezell from Conexxus, song in my head steven sondheim from web side story, brilliant melody, dysptoian mood, onward christian soldiers.
TonyNadaline: tony Nadalin chair WebAuthn group, mr sandman
MikeJones: Mike Jones from Microsoft, work on a variety of standards,, JSON web token, go out and clean stall for horse, often listen to music on headphones, blood sweat and tears, spinning wheel is running through my head, what goes up must come down.
<phila> phila: selfissued is being modest. See this tweet from Pam Dingle https://
KarenMyers: Karen with W3C, member outreach, business deelopment, new member steve McCowen from Anonyme, I'm his buddy today. We have had many new members join fro VCs. Song, red solo cup
VitorioB: I work for Okta, been in identity space for a coupel of decades, beliver in t... chang of season by green threater
RichardWorth: Richard from Capital One.
Yie: Yie working on blockchain, and working on VCs for payment, No music in my head.
SteveMcCown: Steve from Anonomy labs, brand new at W3C, what's stuck in my head, REM, end of the world as we know it and I feel fine.
Sakamoto: Tkuya from ... Working on trusted internet.
Mahmoud: Mahmoud from Mavennet, I have rumors from Fleetwood Mac
DavidCohen: David from Block/TBD, song in my head, ... scribe missed
<decentralgabe> Gabe, not David
Hiroki: Hiroki from Sony, standardization; our member can't join tpac, i'm here to learn more about VC work
KevinDean: Kevin from GS1, co editor of VC use cases document, fun fact, from my university ... rented classic hearse with coffin and went into prom.
PhilArcher: Phil work with Kevin at GS1 and Paul, as retired radio jock, trying to fogget songs, LBC news theme is song in my head.
Manu: Hi Manu
SamGoto: Sam from Google Chrome, I have baby shark stuck in my head, my email is goto at google and chromium
PierreAntoine: Hi PA, work on RCH WG and DID WG, have a lot of interest in RDF nd linked data, song in my head, sound of silence, second voice and lyrics of that song.
Ivan: Ivan Herman, from W3C team, staff contact for this working group, was at DID WG to Pieerre, song in my head, flew into vancouver, blues guitar, joe bonamassa, kept me awake, I need to stay awayke, i needt his in my head.
WonsukLee from ETRI, member of DID WG
<TallTed> an earworm antidote for those who may need or want one, now or later: https://
cel: Hi Charles Lehner, from Credentials CG.
brentz: Thanks for everyone that introduced themselves
Real World Use Cases
Real World Use Cases
brentz: This is an open conversation, what feedback have we gotten with VCs, I grabbed examples, we know these things are being used for travel documentation, staff onboarding, customer relationships, age verification, supply chain tracking, education credentials, content authenticity, government ID, eKYC, what else?
Slideset: https://
kristina: I do have feelings about this tpic, not just VCs being used on left, we are doing v2, breaking changes are allowed, and we want to be careful with those, what were limitations with specification, how did specification help you to realize what you wanted to realize. How can we do better with updated specification?
kristina: One of the biggest reasons, better standardize data integrity, updated data model is in scope, I do want to make sure we have enough implementation experience flowing in to reflect that
manu: One of our biggest deployments is in retail age verification
… we found the model adequate but big gaps in in-person presentation
… getting the credential small enough to fit a small QR code was a big problem
yeah, per conversation above, mission says "on the web"..
manu: In-person presentation at PoS really hard with exiting software
manu: Other thing we've heard from retail, gov etc want their credential to look a certain way
… they have no control over that. Adding a PNG makes the credential huge
… WoT looking at presentation layer
<oliver> can somebody share the zoom link? the one from the invite seems to be the wrong one.
manu: we'd be fine if none of that happens here as external model works, but those are the buggets challenges we see
I think CSS group in W3C was working on standardizing "visuals" which could be expanded to VCs too
sebastianelfors: Sebastian, EU has a large scale pilot going out, public tender, a consortium will be selected, each one focusing on use case, mobile driver's license, covid certificates, payments, we could add those.
<Zakim> phila, you wanted to talk about DPPs
<brentz> DPP is Digital Product Passport
phila: To pick up presentation issue, like manu I'd be ok with it not done here, support existence of rpresentation layer, digital product passport, that should be VC, anything that goes with sale of goods in EU. They will want that to look like Digital Product Passport, presentation layer will be important, we may not need to specify it, we do need to include a hook wehere it can go.
just to note, when drafting the charter, we agreed "The normative specification of APIs or protocols" is out of scope, but yea, we can talk about those
<Zakim> mkhraisha, you wanted to talk about connecting presentations of credentials to other presentations
mahmoud: When we're working with presentations, when it came to connecting set of credentials, no way to say "hey these six credentials are related to other credentials w/o issuing all of them together"
brentz: Can you speak more to that?
mahmoud: I need a way to relate VCs/VPs together.
<Zakim> JoeAndrieu, you wanted to talk about display AND operability of unknown VC types
JoeAndrieu: I wanted to focus on presentaion effort, large and small, I want to see whole credential, how do we represent it in a way to select one of those? Related, confusion about how generic wallet can handle generic VCs it hasn't seen before, haven't dealt with interop to ensure that works well.
<brentz> There is also wallet rendering work happening at DIF: https://
manu: We'll hear more about this later today but the a11y folks have a lost of use cases they'd like us to consider. I am crossing the border and my service dog has its vax
… preferences on websites, I#d like font to be > size X, contrast >= Y etc
… we don't have those in the UCR thay'll come in with
phila: Adding an issue to data model to add hook for presentation (visual or otherwise)
brentz: That was what I was hoping from for that conversation.
kristina: Let's discuss use cases with Joe.
Updating Use Cases
JoeAndrieu: What we've done with use cases, what we're doing in next phase, kevin has stepped forward to help with use case.
JoeAndrieu: Current document, we have four major roles, we identify user needs, we have 30 se cases, in 7 domains, have a paragraph. We have user tasks, actions that we expect what people need to do, there are 8 user tasks... issue, verify, assert, amend, etc.
JoeAndrieu: We have shifted some of the names here, these are the tasks that we have in the document, requirements, motivations, needs.
https://
JoeAndrieu: Then we have focal use cases, deeper dive on specific use cases, request us Citzienship, expert dive instructor to maintain certification, international travel with minor, expnded background, why this is intersting, who needs to trust whom and who is liable, and finally threat model.
JoeAndrieu: Understood threats, how system can erespond, we have user sequences, creating VC, using VC.
JoeAndrieu: We have 5 example VCs, that are probably out of date. We should look at current use cases.
JoeAndrieu: Lessons learned, amend -- we don't really amend, so maybe we can take that out. We have evidence, but no use cases, there are features that people want, in the fullness of time, we don't have us cases. Evidence we have one github convo about capturing the result of a DID Auth -- evidence to verifier that issuer had DID before issuing.
<decentralgabe> @joeandrieu created an issue about a month ago re:evidence https://
JoeAndrieu: Present a VC of issuers authority in that particular domain, from state, DMV chartered by state. We don't have any examples, not well highlighted.
JoeAndrieu: how do you refer to a VC canonically? How do you link?
JoeAndrieu: We refer to identifiers in VCs but not VC about another VC.
JoeAndrieu: another lessons learned, it's hard to get contributions -- easy to get at beginning and end, but not much inbetween.
JoeAndrieu: Maybe we have a more regular rhythm with main call, perhaps keep conversation going, don't want to build tech and use cases, not most exciting thing to do.
JoeAndrieu: There is an understanding of VCs that they are statements from a knowable author, there are systems you can build, knowing statements and what you can do with credential, it's most problematic wrt. VCs should be an authorization or not.
JoeAndrieu: Not sure use cases are helping us there.
JoeAndrieu: I've already talked about presentation layer. Queue?
kristina: Chair hat off, I heard you saying they are not about real life use cases but functions, but at same time, you talk about real life use cases, what is the rationale there, title of document 'use case" feels misleading, maybe it shoud be implementation guide. Might be requirements wishlist for data model.
JoeAndrieu: There are three sets of use cases, problem domain use cases -- tasks of issuing/revoking/asserting -- those are not tied to specific problem (like revocation)
JoeAndrieu: Two different ways to look at same functionality
phila: I really wanted to make sure GS1 use cases were reflected, we have a lot of people here from Japan, are your use cases for Japan reflected properly here? I'm conscious of large number of people from Japan and Korea, are your needs reflected properly here?
Shigeya: there are several use cases missing, I think we need to add several.
Vittorio: As an external person when I hear use cases, I'm confused a bit, I understand taxonomy of capabilities and class, there is one extra level that's useful, and that is actual usage. I hear often people point to european use case, they're exploring. Ethiopean airlines might have a few people using, if something is in production, that could diffuse some of the criticism, you are talking about theoretical scenarios, vs. real world use cases. If you
have numbers, that's incredibly useful.
JoeAndrieu: Yes, I like that, thanks.
here is the list of 13 use-cases Japanese governments are funding on VC/DIDs: https://
it's in japanese, but I think browser translate feature should do a fairly good job
Jay: Related to question from Shigeya, one of the Japanese and Korean language, There are some things in v2 that will help, Any use cases that requires support?
<Orie> +1 to better language support in v2... we are very interested in that related to international supply chain documents.
the actual framing is "Trusted Web", how a Japanese government expects to make Web more "trustworthy" without relying on the platforms.
but the technology expected is VC/DIDs
the Japanese gov is expecting cross-border collaboration, so if you have interest please reach out to shigeya or me (we are both on the advisory board)
<shigeya> 1.42Mil USD (200mil JPY) on 13 projects. It's announced last Tuesday.
Yan: From digital twin WG, there are some useful things there. Right now VC standard is useful, at least 6 different projects, two are deployed, there are challenges, but overall its pretty good. We are issuing diplomas based on VCs, actual academic performance. We also work with WiFi alliance globally, we are going to use DIDs and VCs to solve authentication problems for wifi network. From south africa, use VC for payment, VC had to be ZKP, some argument
in VC standard, which things to use, in that situation, VCs can support decentralized gateways. The current draft is useful, we are happy to discuss, with Canadian government, toxic chemical substance tracking in forest industry.
Paul_Dietrich_GS1_: Use cases domain needs, question is around focus on B2B vs. B3C, business to consumer individual, individual to individual, was that reflective of what you say, or are there B2B use cases?
<Paul_Dietrich_GS1_> Thanks
JoeAndrieu: It was not intentional, would like more use cases for B2B, where work started, etc.
<Orie> https://
YanZhang: Payment is B2B, customer is merchant who is hiring a payment gateway to handle their payment, in that situation all transactions were processed on blockchain, prove to say you have money, their transaction history is on chain, otherwise compatible VC/VP to prove that you have enough money in payment gateway. That is important, implement VC, issuer side is a important part, you need SDK/library to integrate with ID systems.
JoeAndrieu: Proposal for new content, real world deployments actual usage, need to understand how these are used in the wild, we can add that. We need to formally adopt this as a work item, hoops to jump through, myself and Kevin are willing to be Editors, with regard to actions, want to repace amend w/ reference, more important use case. A more open ended use case is store, retrieve issue present, ... it has to do with VC API, OIDC work, kevin has
talked a bit about evidence traceability. What about mobile/web integration, use cases that have that, and then accessibility -- huge oversight.
JoeAndrieu: Accessibility is a big gap, using VCs to make the lives of people with a11y lives better. We would like to get some use cases in about presenting VCs.
<Orie> +1 to accessibility overlap, there are some really awesome accessibility features you can build by cleverly interpreting machine readable semantics.
<Zakim> TallTed, you wanted to clarify meaning of "replace amend with reference"
TallTed: You said replace amend with reference... for documentation? amend is important.
JoeAndrieu: I did say replace, curious -- why is amend important? How do we conceptually amend a VC today? Handwave to say "we don't say this" -- we should discuss.
<Zakim> manu, you wanted to mention i18n
how do you amend a VC without breaking a signature? feels like update/reissue are more accurate
manu: i18n - we have a full i18n solution in VCs but I don't think anyone's used it.
… ?? has proposed an alternative solution that I think we're talking about later.
… We have addressed i18n, but I don't think it has resulted in internationalized creds
<dlongley> +1 to Orie's VC status list example
Orie: To comment on "amend", not interpreting it correctly, but one of the primary paces I've seen this applied, is revocation list block, you want a stable identifier for credential, but you are making changes to credential as things change status, maybe revocation isn't right way to think of that, you can have credentials with multiple statuses, entry point has to be updated frequently to associated/related reference has been updated. Just clarifying.
<Orie> The spec says we refer to things by `id`.
JoeAndrieu: that has an interesting tie by back to how we refer to VCs. If a VC changes in a way a revocation list changes, VC doesn't have a way to be cognisant that they are the same thing -- then we could talk about that sort of update.
JoeAndrieu: If we use a hash, can't update.
<Orie> +1 to stable identifiers for several version of a credential.
<Orie> (the use case)
<JoeAndrieu> +1 Orie
there is a conversation on this topic in OpenID4VCI, raised by Tobias: https://
kdeangs1: There are use cases from GS1 that may need to use these references, there might need something at registry level... would be able to say VC has been replaced/amended. We might have use cases from others than GS1 that refer to this use case. If I change my name legally, there would be a replacement credential for identities.
ie how does the wallet know two credentials are the same type, just "updated"
<Zakim> manu, you wanted to about canonical way to refer -- two ways
<Orie> For the record we have this today related to "revocable" bills of lading / other supply chain oriented credentials.
manu: We have this concept of I want to point to a VC and use a crypto hash, that specific version, so we can detect any change, and there are other things about changing VCs
<Orie> +1 to the separate immutable / content id use case.
manu: We have at least 3 classes of use cases, one is covered. The one about the external one being changed is one we'll need to look at
<Orie> +1 to update being necessary for a number of privacy preserving extensions to VCs.
YanZhang: Regarding updating VCs, long conversation with ZK SNARKS, in cryptography domain, snarks are propular. Essence of VCs generates action between different parties, always have timestamps, ZKSNARKS have simplest mechanism, but we might need something in time progress related to VCs, clear to be different between ZKSNARKs and other domains.
kdeangs1: Traceability - The Problem - GS1 are the "Barcode People". We manage barcodes worldwide, we have a large number of standards that speak to supply chain, it's about data, transactions, traceability, for us is more comprehensive than what most people think, from point of manufacture to when its received.
kdeangs1: What is traceability, about provenance, traceability is abou how it got here, what ingredience were used, when was it stored, who carried it, if it's produce -- was temperature maintained?
kdeangs1: from carrier to distributor to retailer to store, traceability can tell you everying along the way. But discovering this data is difficult, large number of parties, fruit, grower aggregator distributor, prepared food product , traceability can go all the way back to ingredients farm. hard to know where data resides.
kdeangs1: We can do 1 up 1 down to look one place up the chain or down the chain to understand one hop in the supply chain.
kdeangs1: What if there were a discovery service that could respond to a broadcast request for traceability, who gets to ask the question? Consumer with product in hand?
kdeangs1: For example, if they have serial number, sparse number, some condience is someone asking has seen this item.
kdeangs1: what about trading partner, trading partners might get this information. Retailer, what if I want to ensure chain was maintained?
kdeangs1: Then there are regulators, they make the rules, they can see whatever they want.
kdeangs1: Next question, how is discovery service respond, even if they respond with something as simple as "yes I have data", that can reveal something with supply chain, that could compromise supply chain. if I know a distribution center has a useful product, no response timeout don't want to target supply chain center, want to avoid that.
<SamSmith> Hello
kdeangs1: Once it's responded, whether it has data or not, how does it respond to query itself? Again, no resonse, filtered data, or no data -- all the ways discovery service can respond depending on who you are and how sensitive the data is.
<SamSmith> Another way of viewing traceablility is as a chain-of-custody of the data so one can provenance the data.
<SamSmith> provenance
<SamSmith> Supply chain manifests as they flow through customs are a common use case
kdeangs1: Where do we see VCs play a role, if I'm a manufacturer and have traceability data, who do I give it to, let's start with distributor, VC hat's issues, hey ar a distributor let them have the data. Retailer, if I'm giving out data as distributor, I can give data out. Distributor has relationshipi with retailer, manufactuer might do end run around distributor and sell directly to retailer. One of many use cases where you might not to publish lots
of data.
<SamSmith> This is a prime reason ACDCs support chaining
kdeangs1: Supply Chain is a gold mine of VC use cases, FDA has regulations around KYC, pharmaceutical products should only be handled by authorized parties, to prove yourself to trading partner might require multiple credentials. Another VC showing authorization to handle certain classes of narcotics, then creditworthiness, another credential in GS1 ecosytem that identifies you as a trading partner.
phila: Our GS1 colleague Mark Harrison wrote a paper on End to End traceability using VCs https://
Vittorio: This is an interesting scenario, in a number of relationships that you express, your token between organizations vs. granted individuals, cardinality of relationships supplier vs. relationship between company X and Y, with Y can just give "this ser is part of my company". Rules of engagement is around federation. What are your thoughts on how VCs can improve on main scenario -- combinatorial exploion vs. org to org.
<Zakim> brentz, you wanted to make a proposal
kdeangs1: The answer is we don't know that we do, maybe we submit the use case and maybe VCs are not a viable solution
<dlongley> VCs... distributing trust without having to distribute infrastructure
kdeangs1: We have been looking at these use cases and tech soutions weren't there at the time. In our evaluation of VCs, wha we really liked about them is disconnected nature of them, although in many use cases, you need online access for revocation checking and the like, th enature of VCs allows us to create self-assembling ecosystems and to work w/ other ecosystems to prove things in ways you can't do before without dictating a single model for
verification. The process for vaidating a trading partner, several different VC ecosysems, FDA certification, trading partner capabilities, four copletely separate VC ecosysems each with rules, verification and validation rules defined by their respective ecosysems that can be used to prove things about a potential trading partner more rapaidly than we could before.
<SamSmith> Another way of described this "disconnected" nature is an open loop authentication verification model. Where the verifier does not need to directly contact the issuer but can use a verifiable data structure. This enables open loop authorization models which is the primary different from access control moelds
<brentz> PROPOSAL: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors.
brentz: want to run a proposal.
+1
<Orie> +1
<shigeya> +1
<mkhraisha> +1
<TallTed> +1
manu: +1
<JoeAndrieu> +1
<dlongley> +1
<brentz> +!
<brentz> +1
<Jay> +1
<wonsuk> +1
+1
<dwaite> +1
RESOLUTION: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors.
JoeAndrieu: We welcome additional collaborators, if you have suggestions, lionel, reach out to us if you have use cases you want to have covered.
<shigeya> I want to mention about one of the use cases we analyzed at Trusted Web is supply-chain traceability related to the chemical composition of products and their exchanges. In certain cases, the participant needs privacy (trade secret)
Begin of break for 15 minutes.
Serializations and the Core Data Model
kristina: trying to be careful and considerate as possible with my words, In VC datamodel v1 we have a data model, a serialization and proof sections, i.e. how do you sign those credentials
… : in practice whats happening is there are implementations that are doing what some are calling JSON or Incomplete JSON-LD serialization, with the biggest difference is @context @vocab is used
… : either you have a valid @context or you do not, in which case you use out of band mechanisms to understand the claims
… : in 1.1 all these components were in 1 document. The serialization might not have been explicit but it is there
<Orie> disagree with the framing of this... does not represent consensus on v2 (wrt the data model / serialization side)... the securing side seems accurate.
kristina: : in 2.0 we are separating into different documents: Core Data model document, 2 Security Documents: JWT/Data Integrity. Under Data Integrity theres a number of other docs such as JWS2020
… : what i really want to bring up is the SD-JWT use case, a json format that allows selective disclosure without advanced crypto, theres JWP, CBOR, ACDC, and others. Where do these sit?
<Orie> This slide mixes security and serialization incorrectly imo.
kristina: : This slide does not say we have to work on ALL of them, the question is do we want to have an extensibility point to open the path to these different represenations, or do we want to say ONLY JSON-LD is the appropriate serialization.
… : Can we get on the same page? do we want extensibility point to find out which document is responsible for defining those. if we want to open up the door for SD-JWT is that under data model or under an SD-JWT document?
<TallTed> Did we not already decide that serialization was an open extensibility point? by means of the abstract data model?
kristina: : this is one of the framing that we have been discussing as chairs.
TallTed: I thought we already decided serialization is an open extensibility point, by virtue of the open data model that all serializations have to go to?
manu: We have not done that yet, we have done it, in the DID WG. There were many reactions, and many, including myself, have concluded that was a mistake.
<Orie> My slides also address this... but there are parts of the framing Kristina presented which I do agree with.
manu: : Question 1: Do we want to represent VCs in a variety of different syntaxes? I think yes.
… : Possible second question: Do we want to create a new abstract data model for VCs? big -1 on that.
… : we do have a deployment demonstration right now, you take a VC, secure it as a JWT, and that seems to be working that way. in Data integrity theres examples of translating it to CBOR using CBOR-LD so that is possible
<TallTed> so instead of forcing translation thru an abstract data model, we force translation thru a physical data model?
<dlongley> whether a VC is translated at one layer or another (e.g. for transmission or securing) doesn't mean that there shouldn't be one single representation "around" those things.
manu: : the question really is: when do we need to do the transformation? we could look at the data integrity spec and the transformation part there, fundamentally, talking about a serialization in the core data model is probably the wrong layer.
… : I suggest we push it out to security layer.
Orie: I am not in love with the grouping between serializations and the data model piece, but i agree with the intentions. I have my own reinterpretation of these components. I think there are serious flaws in how we defined proof types in 1.1, my primary mission is fixing those flaws while preserving the data model features in 1.1
… : what i mean is data model of 1.1 is valuable in its current form, and I would like to tap that value consistently for the two proof formats that were defined already in much the same way. This ties directly to the serialization questions being tied here. There is a risk of opening up additional points of optionality while addressing the abundance of optionality in security we have. Im concerned about tackling that prior to closing the is[CUT]
… : like manu mentioned for JSON-LD to CBOR-LD theres a path, but that may not be the only binary path people are interested in, i do not believe it is a wise choice to start tackling this serialization complexity now, its a question of prioritization. I am worried about adding too much scope.
… : I think we can make improvements on the spec from 1.1 to 1.2 that are valuable before we tackle the harder bits
<Zakim> manu, you wanted to note that JSON section in current spec is problematic.
<justin_r> second most useless
manu: i will note that in the 1.0 and 1.1 we tried really hard that a full blown JSON-LD processor was not really necessary, we added a JSON section to the spec, which if i remember correctly Jritcher said its the most useless section.
… : second most useless*
https://
manu: : I think we need to look at that section to see if it is buying us anything.
<Zakim> justin_r, you wanted to say the first if there's interest after
Justin: The most useless is extensions may allow, prohibit etc, this is a close second.
Kristina: If no other comments moving forward to Orie's Presentation
Orie: Hope my snarky attitude translates remotely.
Orie: extending where kristina left off, what are we doing to define the Data model in v1.1 and what are we doing to secure it, and at the end I will drift into a series of hand wavy proposals, trying to intro topics so we can talk about in WG calls.
… : they will take a while, i suggest we get the lay of the land then begin solutioning.
… : On the right hand side, you will see some version of GPT-3 of a true scotsman on an envelope.
… : this speaks to the core data model and the branding problem associated with it! I hope the directness doesnt come in any way offensive
<ivan> [slide #42 onwards]
<Github> https://
Orie: : we all have software we are relying on, I see a lot of topics that people are excited about that are somewhat unique to VCs and W3Cs, it seems unique to our community.
… : one of them is semantics and graph theory, and the question ends up how many of this is related to browsers etc?
… : This elaborates a bit further, what is the point of VCs? How do they reflect w3c values? why not do this work at IETF ISO DIF?
… : what is the relationship between w3c values and the communities we're a part of? is semantic web dead?
… : Ive seen privacy and accessibility considerations as a big consideration that is unique to W3C.
… : framing this as a core data model, because it is a huge part of the core data model. What is the relationship between semantic web and v1.1 credentials at w3c.
… : one of the questions is: What are we defining? whats to define here? its a question of Decentralization.
… : how can issuer/holder/verifier agree without a central registry? what is the value of these claims? whats diff about claims in this specification and other specs that represent claims?
… : Crediting mike jones for this, and this is something i have now come to believe: A new specification has to improve. When is innovation worth the switching cost? we have JSON and have JOSE, we have CBOR and COSE. Why are we here?
… : why are we talking about another way to sign and secure things? why do we need another standard/WG? there answer must be we are doing something that is worth it. I believe we are, but we are disagreeing on what it is.
Ivan: non-w3c hat: I don't want to start the discussion of pros/cons of semantic web, or what semantic means. I prefer to use the term Linked Data, which has different connotations.
… : for me the value of having the VCs being done using Linked Data standard, is that LD gives you pieces of graphs coming from X or Y, and by combining them I get something greater.
… : these days it is not fashionable to say that, but if you look at knowledge graphs do, some people have to acknowledge that it came from semantic web. The question is, are we creating pieces of knowledge that is creating new value by adding it to the knowledge graph? I don't have the answer, but the use-case doc should probably have the use case where the link effect is relevant.
… : I want to push back on using the word "semantic", I do not think we are interested in that.
SamSmith: I think there has been a very valuable contribution from the semantic web work, but the idea of knowledge graphs, and semantic inferencing goes back much further. There have been multiple branches of work in the field of automated reasoning that have been parallel to that for some time. it is entirely appropriate to discuss other models of knowledge graphs in the context of moving forward and in the context of Orie's presentation of[CUT]
… : security, we should be able to talk without knives out. from my perspective, many other knowledge graphs include uncertainty as a first level citizen, which depends on directed edge knowledge graphs with weights.
… : the work being done at w3c has precluded those types of knowledge graphs, and we should be open to them. we can do some things from security perspective if we take a different approach, and i'll mention it when I talk about ACDC
<Zakim> JoeAndrieu, you wanted to talk about disambiguation more than graphs
Joe: I think the focus on graphs is a bit of a distraction. graphs are one way to represent data, the challenges of adding an adverb to an RDF triple. my point is there are debates about having a coherent graph about everything in the planet even makes sense. What does have value is the ability to disambiguate.
… : that ability is far more valuable to get the data from multiple different sources.
nadalin: I somewhat agree with Orie here. I believe that the core data model is the problem in that it tries to unify things. we already have JSON/CBOR/COSE, we should let them go as they are and not try to fit them in this core data model.
… : they have their own data model, defined at IETF. We should not have to tie them to the VC model.
Orie: JSON CBOR, JSON LD, there are many data models that have value and adoption.
<SamSmith> My point about using knowledge graph models that support uncertainty speaks directly to the ambiguity problem. Ambiguity is a quantifiable type of uncertainty. The hard problem of polysemy is not solvable without uncertainty measures on meaning drift between terminology corpus.
Orie: : Everyone has bias, I'm very passionate about many things sam mentioned, I get really excited about that work, sorry if semantic web is a triggering term. I believe in the original vision. I will continue to support the value of linkages between data, concepts and machine processing
… : I want the core data model to provide a bridge to link the semantic web of the past to the semantic web of the future.
<SamSmith> Reasoning with uncertainty is more robust than reasoning with certainty. Links that do not represent the uncertainty in the link limit the robustness of the inferences so traced.
Orie: : I am very much in favour of these graph structures, I love these things, in particular applying these technologies to supply chains, traceability etc.
<SamSmith> +1 @mkraisha
<TallTed> Consider, "Webs of Semantics" or "Semantic Webs" ("Webs" intentionally plural!) instead of "*the* Semantic Web" ("One Web to Rule Them All, and With the Specifications, Blind Them!"). Main idea being, context lenses are important.
Orie: : You should hold me accountable to my bias.
… : The core data model has many non-normative statements. This is the transition to talk about securing it. We should be able to clearly see what are my requirements? what do i have to understand? There is lots of value of the informative section, but I think there are so many of them that the value of the core data model is in jeopardy because of all the extranuous information.
if we don't we should probably have a placeholder issue to revisit non-normative sections in the data model document..
Orie: : This is essentially Kristina's slide with my own bias. I think the core data model is RDF. The current v1 and 1.1, focus on a single serialization using JSON-LD, secured via either VC-JWT( which operates on JSON) and Data Integrity( which operates on JSON-LD)
<SamSmith> RDF does not support weighted edges this is why I cannot use it.
Orie: : I understand there will be disagreements on the framing of previous slide. lets focus on that before we focus on securing it.
… : there are parts that already start to create real trouble for us as a group: a few ideas are:
<cel> SamSmith, maybe RDF-star could support weighted edges?
Orie: : The idea of the signature/proof. These issuer/proof/created properties are not disambiguated from the core data model. The core data model is about defining the terms in a non-ambiguous model, some of these other properties are about the securing part and not so much the data model part.
<JoeAndrieu> +1 for clear layers
Orie: : I think clean layers are what we need, the blurry edges create lots of risk the VC-JWT in particular im worried about that edge.
<SamSmith> +1 for clear layers
+1 I agree that in the slides these components are clearly separated, but in v1.1 they are not that clearly separately defined
Orie: : Second blurred line area: Content Type pieces.
… : for VCs under current vc 1.1 model, what is the content type? different per signature type? I think we can use the patterns outlined in IETF and elsewhere to define a series of normative statements together.
… : there are also issues with schema languages, in the current spec we have seen people use JSON-Schema, and JSON-LD, and there are problems because JSON-LD and JSON-Schema are not exactly the same thing.
… : The issue is this can get into your way if you try to get into content-type negotiation. This is something that we really struggled with in the did-core work, because resolvers in DID-CORE have to have an accept header, which affects interop quite a bit.
… : this is an area we can easily run into issues that snowball.
Ivan: I want to avoid mixups, JSON Schema is great, its about defining constraints on the JSON structure. JSON-LD and the context has nothing to do with that. To combine these two things in the same sentence invites confusion. its a mapping of JSON to RDF mapping, but its only a mapping and does not constraint and the vocab that is used is not about constraint
Orie: Super strongly agreed, if you think about semantics of JSON Schema properties, we already have these things in the spec and there is necessary cleanup and issues with overlap.
<SamSmith_> If we have clear layers we can use JSON Schema for the security layer that wraps a higher layer that includes JSON-LD. The JSON-LD is opaque to the lower layer with JSON Schema.
decentralgabe: JSON-LD has been used out of necessity, and JSON Schema can be used instead, and wasn't because it wasn't defined properly.
Orie: I would add one other note, I have seen people use JSON schema to create vocabs before, and I think Manu commented on this, but this is a thing people are doing it, the UN does this, others do similar work, mixing it together, might have confused people. We have to be careful here.
<Zakim> manu, you wanted to note that we might want to focus on what people are implementing and let that drive the work.
Manu: I'm having a hard time concrete decisions we're trying to make, this feels like a meta conversation we've been having for a while. I want to focus on implementations and actual deployments. I think its important to reflect, but fundamentally we have many implementers and we should focus on what they are doing.
… : I want to understand where the conversation is going
Orie: I'm not here to tell the WG what to do, im here to make everyone feel where we are.
Ted: I'm concerned that, these slides are doing more blurring than already exists. In a group where we're trying to increase clarity, what i'm seeing, both Orie's and Kristina's betrays a misunderstanding of the things on the slides.
… : if we cannot understand the tools we are trying to work with we cannot clarify it for anyone else. For example there are 6 media types one of which is legal i believe.
… : that makes it impossible to discuss
… : i want to put boxes on misunderstandings based on prior output, because it helps us clarify it in the spec. That can be done in the spec either as a note or in the main spec, that doesn't really matter to me. Its difficult not to be upset at these media types because it violates how they are constructed.
Orie: Which core terms do we see in the core format? Link on left is the term in our spec, link on right is my best effort to map to VC-JWT language that i think is relevant.
… : the point is we will go through this process potentially whenever we add a new security format, so we ought not to do this if at all possible. It could be that we must do it if we do a lot of securing in the core data format.
… : we have to do this in the CORE DID model because of the translations we have to do.
… : these mappings are expensive and complicated and the main point here is: who wants an unbounded number of mappings? we can have an infinite number of mappings that can become legal?
… : this was a core point of concern from the DID objectors.
… : please read the private claim names in the associated IETF specs, and asking what is the relationship between them and our work.
private claim names: https://
(I think..)
Orie: : this is one interpretation of taking the did core route. which should align with kristina's slide.
… : we'll map RDF to infra and infra to CBOR and JSON and RDF will map to JSON-LD, and we get security that depends on the serialization we like.
… : want to hear from folks who think infra went really well or not so well
justin_r: i'm not here to defend the use of infra specifically, i will say though that the concept of what we did in the did:core work is a good idea but it ended poorly
… : one of the things that is really important here is that everything in and out of a serialization should be really tight and defined, and we had that, but a lot of the text got removed , over my protests.
… : in my view that is where we lost lots of value. losing that tight coupling. In the json text says a "boolean must be a boolean" that is absurd, we can do this very stricly, the http header spec gives us a very good example of a very good serialization and very good parsing language.
… : it does a really good job of saying "this is a boolean, this is what it looks like in this serialization" leaving open the door for other serializations.
… : that was at the core of my argument for the representations language for DIDs VCs and all of this, lets not repeat the mistake of loose coupling that was done in did core, i DO see the value of having the two layers of existence
… : if what we're talking about is a data model and not just a json-ld schema we should be able to go to multiple different serializations
sam: +1 to strictness of serializations, very important to round-trip between different serialization, but where we have creep where some components are used to tunnel from one serialization to another that is problematic.
I think members of the industry have adopted tooling that is core to their business, if we cannot accomodate the major tooling sets, to get something that has interop across the industry we will run into the serialization wars.
… : notably we do not have XML. We need to have enough flexibility to have serialization to reflect the major tooling stacks in the industry
… : almost all of the fringe serializations have well defined round trip paths to the major ones, which means we only need to define the ones that are important and address those.
<justin_r> +1 the data model needs to go strictly in and out of these major stacks
<Zakim> manu, you wanted to note experience using infra for core data model in DIDs.
<justin_r> new serializations have to follow the same path
<justin_r> manu: weren't you the one who campaigned for us to use infra?
manu: to speak to abstract data model and did core spec. I continue to believe it is a massive mistake to do that, having been the one who had to take the JSON-LD rdf model, we had to invent a new data model in infra, we had to rewrite everything. and we were promised that we will have all these serializations, at the end of the day there was a semi attempt at CBOR, we ended up with two serializations JSON and JSON-LD with the only difference[CUT]
… : @context and just about everyone ended up adding it. We spent months working on it, and to this day we do not have anything to show for it other than JSON and JSON-LD. Theoretically I agree, but in reality we have not seen any of that in the past.
… : very concerned of committing the WG to months of work. if you look at the chart up here what is the extensibility model for JSON or CBOR? is it @context? is there a new registry we need to create?
… : that is my concern because it backfired on us in did core and fairly certain it will backfire here.
<Zakim> JoeAndrieu, you wanted to say abstract data model is a failure, in part because it is innately untestable. Only serializations can be tested.
Joe: I want to endorse everything manu just said, i don't understand why the abstract data model was even considered.
… : the abstract data model is innately untestable, all we can test is serializations.
<Zakim> Orie, you wanted to comment that did core data model is trivial compared to vcdm
Orie: in general i agree with manu's comments about registering new representations of the data model. Its important to note that the two data models are pretty different. One is an open world type problem, while the other is more constrained.
… : The abstract data model might work better for how do we return a specific key, its not just about how do we make a representation, its also about the cost on the tooling to manage all the representations. how do I get the representation i want from the resolver, how do i get the representation i want from the driver? this explodes when we have an infinite number of serializations to the data model.
<mprorock> +1 Orie
Orie: : I echo the words to the group, but i think its very different from did core.
+1 orie
+1 Orie
<decentralgabe> +1
<dlongley> +1 to Orie
selfissued: I'll echo the point that only concrete serializations are testable. ultimately real software uses concrete serializations, we have to get these right and interop. I agree in the abstract with we don't want to support extensibility model, JSON-LD and JSON has one.
… : atleast for those two things and also for CBOR that is true. a little later this afternoon, we'll talk about registries, and how they help define extensions. I agree we want to keep things simple, but there will be multiple representations, and we want to make them first class.
… : if they are informed by a common perscription of what the normal fields are that should appear in the representations, but that is not testable.
<justin_r> so a model ... for the data ... that is abstracted .... 🤔
<Zakim> manu, you wanted to note that we need to try and reduce optionality, not increase it. and to note "adding new fields" is a local extensibility model, not a global one -- and requires registries.
<decentralgabe> +1 reduce optionality
Manu: we need to reduce optionality. What we've seen is massively explode optionality. that is difficult for a new ecosystem to grapple with. the idea that we will have all these different types is a dangerous one. NxN matrix for interop is all that much more difficult.
<mprorock> I am not opposed to going JSON-LD only
Well.. speaking of implementations.. And pain points.. chairs hat completely off. knowledge graphs are great, but, in some use-case for VCs (ie verifying the user in external identity use case) linked data has been a little overkill... at least for now.
<JoeAndrieu> +1 to reduced optionality (especially at the "envelope" layer, that of the credential, without constraining the claims)
<decentralgabe> +1 Kristina
Manu: : we should optimize for reducing optionality. JSON has a local extensibility model, and it often requires you to have a spec that is published, and it requires you to have a centralized registry around. I'll note that alot of orgs that are using this work are focused on decentralization. forms of centralization are problematic
… : we have something that is working for us. I think anyone who is arguing for opening up optionality needs to defend how that is going to lead to a bigger tent.
selfissued: will respond to your comment about registries and centralization, this WG is a centralization point. we are the authority on defining what the VC is, its not evil its just practical.
… : likewise if you want global interop, you need to have it written down, thats just practical engineering.
Orie: Where do we feel like we should open the aperture and where do we feel like we shouldn't?
… : this is my proposal, I think we should increase the aperture in the securing side, I think we should not increase it in the data model side.
… : we have problems in the current document and draft, and would like to fix them prior to creating new ones. I think the group is asking for alternatives at the core data model layer, and I think that deserves its own charter, and we can really help the industry without blowing up this charter. I think we can help the industry by increasing the aperture on the security side.
<SamSmith_> Property Graphs are a superset of RDF graphs. It seems to me that exapnding the core Data Model to include property graphs solves the problem. Its the right amount of flexibility and if forward looking
Orie: : Some of these have come up during our WG charter process, for example dizzy/anoncreds/ACDC
… : I recognize this a recommendation and is in contradiction to positions folks have taken on the call. I think this is the safest path forward to protect the value of the existing standard
… : and protect security formats and focus on improving them
+1 to what orie is saying
… : I think we should open up the lower box, without the top one, without endangering the primary mission.
… : if i can't secure it properly then the value of semantic VCs is destroyed. we can get to some of these mission objectives in another WG charter where we are building on top of a strong security foundation.
… : I'm excited about VC-JWP and VC-SD-JWT, and don't agree with where kristina put them, I think if people are distracted fighting over the core data model, we will not be able to do these security well.
… : these are open PRs for several repos i would like people to review.
<dlongley> +1 to Orie, leave alone / clean up data model (very small changes), focus elsewhere for larger changes
<mprorock> +1 orie
brent: we have 30 mins and a concrete proposal.
kristina: I think the proposal is the data model is RDF JSONLD and minimal changes will occur there, with most of our focus to be on securing the model.
<Orie> Thats ok Sam, I did that based on Kristina's slides last night :)
sam: Im going to talk about ACDC, and I'm guilty of often changing my slides dynamically and will take the liberty of talking specifically about ACDC extensibility model. which should answer manu's challenge
… : RDF is a subset of a property graph, if this proposal said this will do a property graph.
so no enabling additional "serializations" but that extensibility handled in the securing documents (not happy with the wording but one way to put it..)
<mprorock> +1 Ivan !!!!
<dlongley> +1 to Ivan
<Orie> There are beginning of standardization on the graph query languages, such as Cypher though...
Ivan: on the property graph thing, bad news: AFAIK property graphs are still a moving target, but it is not a standard we can rely on. The good news: as of today, there was the first WG call for RDF-star, which is doing extensions to RDF to include property graph concepts, it is work happening, that may cause race condition of references
<dlongley> +1 -- sounds like we can get support for what Sam wants in due time.
<dlongley> whilst still using standards today
<Orie> but both LPGs and their query languages might be tough to cite as normative dependencies for us right now... at least in my current understanding of them.
Ivan: : the work is ongoing, we will not need to leave the RDF model if we need to get property graph features, without leaving and using new serializations.
<Zakim> JoeAndrieu, you wanted to challenge the presumed for a registry in a world where "anyone can say anything"
<SamSmith_> +1 to contextual vocabularies
Joe: I like Orie's basic proposal, I like that it explicitly uses RDF. I want to talk about the separation between the envelope and the payload of the VC, we should lock down the envelope, but we should keep the payload open, and allow people to say anything that isn't tied to a registry. as long as we in a community can agree on a payload then we should use the vocabulary.
mprorock: I cannot echo enough support for lets get the data model trimmed a tiny bit, but focus it on one concrete testable thing. We need this to be flexible to not need to know every keypair in the credential, the nature of VCs is that they are Verifiable, which implies the security model must be rock solid, by doing what Orie is suggesting here, with refinements to the language, it allows us to set us up for RDF-Star/CBOR-LD
… without taking away the focus on security aspects that we must ensure are fully addressed.
<Zakim> manu, you wanted to note that we want a constrained set of JSON-LD, not to open up to full blown RDF.
Manu: would like to spend some time talking against going full blown RDF, i agree with the gist of what Orie is saying, we tried really hard to strike the right balance by not focusing entirely on RDF, I think it would be a mistake to take that away.
<ivan> RDF-star WG charter
<mprorock> +1 Manu - I think setting ourselves down a testable path, without requiring hard overheads for payloads
<dlongley> +1 to using a "profile" of JSON-LD to reduce optionality and make things simpler.
<brentz> +1 to JSON compatible
<JoeAndrieu> +1 to json-compatible JSON-LD
+1 manu
Manu: : we focused on making sure you can use JSON compatible JSON-LD, which does not imply you can do any JSON, but you can make sure it can be translated easily to JSON-LD, i think going further than that by saying you need JSON-LD processor is too much. We want people to take JSON that is JSON-LD and put it in a doc database all without using a JSON-LD processor.
<justin_r> -1 because if we are claiming JSON-LD is the extensibility model then we can't pretend it's not JSON-LD
<Orie> my favorite way to secure JSON-LD, is using JOSE / COSE.... specifically using JWS / CWS.
<dlongley> justin_r: we should not pretend it's not JSON-LD ...
Manu: : when you put RDF in there you end up attracting the wrong sorts of people into the group, and i think we have done a good job walking a fine line. I think the shape is right, but want to make sure we don't lose the balance isnt lost
<dlongley> we should say it's JSON-LD ... but a specific profile of that that is particularly JSON friendly.
<justin_r> dlongley: I'm fine with that tbh, but then we shouldn't claim it's a "data model"
<dlongley> justin_r: yes, it's an RDF data model with a constrained JSON-LD serialization
<Orie> +1 manu
<mprorock> +1 manu
selfissued: I often agree with Orie, but i disagree here. In practice as Kristina pointed out, lots of people have built VC implementations that don't use context or LD correctly, many devs took a stab at it and got it wrong.
<Orie> For the record, GitHub signs commits incorrect with respect to PGP.... that doesn't mean we say thats ok by changing the OpenPGP spec.
selfissued: : in some ways i agree with what manu said, if we can make it easy for devs to just use JSON in a way that, with a defined serialization with clear properties, will do the dev world a world of good.
… : trying to require RDF, while an attempt to unify things will end up dividing people
sam: I want to respond to Ivan's comment, property graphs are admittedly a later development that has been around since the 70s/80s, whether you call that a property graph or an ISO standard, that is not an abstract data model.
<dlongley> ...but you need a standard serialization for it that is popular and easy enough to use
sam: : the model has been around forever and theres tons of papers about how you build graphs with edges. I don't want to preclude anyone to use RDF or JSON-LD, i don't want to be precluded from directed weighted graphs, we should be allowed to be able to put weights on the edges to enable machine learning.
<Zakim> dwaite, you wanted to separation of envelope and payload
sam: : why are we constraining this, other than considerations to tooling?
<Orie> If people can't get RDF/JSON-LD correctly... whats the chance they do LPGs (a super set) correctly?
<Orie> I think David is agreeing with me that we need to fix VC-JWT : )
dwaite: Many things defined in the data model, especially how to represent it as a JWT, you will see lots of overlap between the envelope and the payload. That is one of the things people get wrong. There are mappings of values to JWTs that are not part of the data model. where is the line drawn here?
<SamSmith_> @ORIE LPG are easier to get right than triples
<Zakim> manu, you wanted to "don't use @context correctly" means "we have a non-conformant implementation".
<Orie> SamSmith, show me a standard for them that's better defined that RDF.
<Orie> I'm a huge fan of Neo4J / LPGs / Cypher btw,
Manu: wanted to speak to the comment about devs today that are not using context correctly, those are non-conformant VCs, there is a danger if we open up the aperture to allow semantically ambiguous VCs to be defined that is a problem, we need to do a better test suite that will fail those VCs.
<mprorock> +1 dlongley
Manu: : we need to stop saying those things are part of the spec, they will fail a linter, and will continue to fail a linter, we need a hard line on what is and isn't a VC.
<Orie> +1 to stoping calling everything a VC.
<Zakim> mprorock, you wanted to ask if we are clarifying to a minimum of one context for the root VC envelope
<dlongley> +1 to Orie
mprorock: I do want to comment on the ML side of things, i spent lots of time on ML, the thing that is important there, is that it is too early to say, why do we want to standardize edges? the biggest advancements have been about auto encoders and semantic encoding, these are cool cutting edge thing, that isn't anywhere near ready for standardization.
<Zakim> phila, you wanted to talk about JSON-only approach, edge weighting etc
mprorock: : we will close paths of if we do it now. We should look at adding weights into edges, it just doesn't necessarily belong here. We should stop making mistakes on it, stop developers making mistakes and focuisng on security side of it.
phil: entirely happy to have something that is entirely in JSON. I am surprised to hear about sam talking about the importance of edge weighting in this context, isn't the whole point of credential that I am saying X is true? isn't that always a weight of 1? am i misunderstanding?
<Orie> 50% chance your GS1 license is not expired phil ; )
<mprorock> Lol
<dlongley> again, this weighting sounds like a great 3.0 feature to consider
<Orie> I'm still a fan of LPGs tho...
Dwaite: you can attach multiple weights to the different claims, because you can attach different weightings to different pieces of evidence.
<TallTed> +1. "I believe this to a 70% certainty" is a valid thing to verifiably assert.
<mprorock> We can use vocab and schema to easily attach probability to values
davidC: want to make a comment about envelopes, we have info that has everything to do with crypto that is in the core model, should be in the proof section, like expiry time. we have a lack of clarity between what has to do with the proofing and what has to do with the crypto.
<Orie> +1 David, cleaning up those blurry lines is our primary mission IMO... opening up the date model, puts that mission in jeopardy... new work items I am a part of at IETF, don't even offer JSON as an option, its just CBOR / COSE.
<Zakim> JoeAndrieu, you wanted to say the developer challenge with JSON-LD is more about DEFINING good data model. It's easy to model with a JSON mind-set and get the underlying RDF wrong. But that problem is inescapable. It is in fact, the right obstacle.
davidC: : the second point is what is a valid VC, we are encountering this in the Open ID connect, a valid context, with a valid IRI, but you can easily specify those types using their URIs, I bet you these will break if you replace user friendly names with URIs
<Orie> btw, I am also in favor of using `@vocab` to create explicit support for. "private claims" in the VCDM 2.0.
Joe: I want to share some learnings I had: profiling a learner with two different wrappers, one for the learner, If i did not have access to excellent resources I would have struggled. Defining a good context is hard, most devs do not need to do that. what we want is a VC that i can use a context/vocab/schema that people understand.
<dlongley> +1 needing more effort for a shared understanding vs. private modeling of "whatever" :)
Joe: : most devs are not designing information context, the designing part is hard. Forging a shared understanding is where we get the benefits but it is an extra lift.
nadalin: you should not force at what is a VC today, and look at why are people not conforming? you should look at why the mistakes are happening, look at why they are not conforming, find the reason.
<JoeAndrieu> FWIW, here's the LER Wrapper I mentioned: https://
<Orie> nadlin How does knowing why GitHub fails to sign commits properly with PGP, help us decide if we should change the PGP spec to make what GitHub is doing legal?
Sam: one of the advantages of property graphs is not weight but that you can have properties on the edge. this lets you say that an edge matches an ACDC that is points to a schema that is on the edge. This lets you extend by adding a new node to the graph without cooperation with what was specified in the past.
<mprorock> That is what vocabularies give you
Sam: : one of the hard part of mapping with context, is that meaning of words drift between contexts. The mapping is never 1, there are lots of things we want to do with VCs that require making inferences across links that do not have 100% certainty
<kdeangs1> +1 to Sam's statement about RDF vs graphs
Sam: : the verifiable data structure is enabled by having those property graphs, you can build them all using JSON and JSON schema, this enables people who use JSON and JSON schema tooling to build more sophisticated systems, because it is much easier to build property graphs.
<Zakim> brentz, you wanted to ask next steps
<Orie> I get the desire to reinvent RDF... in JSON... its always easier to build on what you know, than to build on a standard that you don't know that is already adopted.
<decentralgabe> strawpoll?
Brent: What are concrete next steps here? we have outlines of a proposal from Orie where we keep the data model as is, and focus on opening the aperture on the security side? Where do we go from here?
<Orie> Lets poll to measure
<mprorock> JSON Compatible JSON-LD for the envelope / core data model - focus on the security model
Kristina: we do not have consensus but the issue is more clearly framed. There are three options: what we see on the screen, closer to what manu was proposing with JSON as JSON-LD, third closer to how do we reflect people who cannot use JSON-LD correctly
… : do people agree with that framing?
<mprorock> +1 dlongley
<dlongley> +1 to mprorock's framing of one of the options (plus with a focus on helping JSON devs however we can) (unemoting this)
brent: some calls for polling, i'll frame the question and throw it in the chat.
+1 on mprorock's and kristina's formulation.
Ivan: to avoid misunderstanding, i get the value of property graphs, we are in contact with the people in that community trying to get them to come to the W3C for further standardization and we were sent away.
<Orie> I am also in favor of tackling this topic directly, in 3.0.... with property graphs... just not with the current fires we need to put out.
Ivan: : I get the value and you don't have to convince me. The situation today is do we want to restart the work and reformulate the current VC spec by throwing out our current model, or as Dave put it just look at RDF-STAR which allows us the possiblity of 2.5,3 or whatever which will bring in the features later on.
<dlongley> +1 to Ivan
I do not see enough support for property graphs for v2.0 at least among current participants, and hear sentiment maybe v3.0
<Orie> +1 ivan
<dlongley> plus -- we get some incubation period to get that right in between
<mprorock> +1 ivan
Ivan: : I think throwing away everything would be an enormous waste, and an enormous amount of energy, and waiting for RDF-Star is much cheaper.
<mprorock> Happy to make sure a draft gets incubated if folks want to work on it in CCG
+1 to ivan
Kristina: I do not hear lots of support for property graphs for 2.0. Please open an issue
Brent: +1/-1 poll
<brentz> The core data model should be written in JSON-compatible JSON-LD
<SamSmith> This is a false dilemma. The choice is not RDF vs RDF*. Its do we allow in JSON people to use data models that are essentially property graphs
<kdeangs1> +1
<Orie> +1
<DavidC> +1
+1
<JoeAndrieu> +1
<mprorock> +1
<sebastianelfors> +1
<ivan> +1
<mccown> +1
<shigeya> +1
<justin_r> -1 that statement is meaningless
+1
<cel> +1 (as observer, not representing any organization)
+1
<dwaite> -1
<dezell> +1
<dlongley> +1
<TallTed> JSON-LD *is* JSON compatible.
<decentralgabe> -1
<oliver> 0
<SamSmith> -1
<hsano_> 0
<justin_r> @tallted only if you close your eyes ....
<dlongley> to me... that means an RDF data model that will be serialized to a specific profile of JSON-LD
<dlongley> that is very JSON friendly (in a variety of ways)
<selfissued> -1
Ted: similar to what Ivan has been saying, I don't think we can cut it out of the conversation it has been shoehorned in different places. Property graphs are not standardized, there is no standard for them. This is not a path forward on standards, W3C work is toward standards. This is not the path of property graphs to the degree i have experienced to this date.
More concretely, "JSON-LD compatible JSON" means "don't use expanded form, don't use crazy @values everywhere, don't use the full extent of JSON-LD"
<mprorock> +1 manu
<dlongley> (a JSON-idiomatic profile of JSON-LD)
+1 to above
<mprorock> +1 ted
Ted: : Maybe in a few years it will be but it currently is not, and at that point there may be RDF-Star, i think we are going to be wasting an hour if we focus on property graphs.
<Orie> +1 to the "this is W3C" angle... there might be better places to do LPG standards that are not W3C... Same is true for DIDs.
<ivan> +1 to Ted
Joe: The question is backing away from Infra is not the issue, I heard a concern about starting from scratch.
sam: i was not proposing we do RDF-Star, or other property graph standards, i was saying we should allow people using JSON, to build property graph constructs, and not be forced to use something that requires them to use it.
I think... we agree we want to make it easier for the developers for whom JSON-LD is a heavy lift..
<JoeAndrieu> me error. INFRA was the DID thing. My comment can be dismissed
Brent: thank you for a good session, we got pretty close to concensus on that strawpoll there, i think we have a path to censensus.
<Orie> SamSmith re LPGs and VCs and RDF... https://
thanks @cel for the huge number of typo fixes!
<TallTed> so you're looking for some explicit expressivity that you see as missing... OK, be clear about what that expressivity is, and we can write something about how to express that in the model we're using -- or make appropriate adjustements as may be necessary to satisfy that explicit use case / requirement
<SamSmith> Good my presentation this evening will be showing the use case and how we express it
<SamSmith> in ACDC
<SamSmith> Which is just JSON and JSON Schema
Joint Session - APA WG
kristina: Calls the meeting to order
brentz: The VC WG dinner is tonight. Meeting at 18:30 at Joe Fortez restaurant
<kristina> starting!
<Lionel_Wolberger> * Lionel asks, can someone put the zoom link in the IRC please?
ivan_: Suggests meeting in the hall at 18:10
<kristina> https://
kristina: Welcomes members from APA (Accessible Platform Applications WG)
… looking forward to hearing use cases
<matatk> Matthew Atkinson
<PaulG> Paul Grenier (apa member and chair of spoken pronunciation)
<Fazio> David Fazio - Fazio
matatk: I'm a co-chair of the WG
… we can lead you to the use cases doc we have
<Lionel_Wolberger> Representing APA: Janina Sajka, Matthew Atkinson, Lionel Wolberger, Scott Hollier
matatk: and we have a couple of specific things to talk about
<matatk> APA's agenda: https://
<Irfan_Ali> Irfan Ali (apa member and co-chair of spoken pronunciation)
janina: We have a specific question
… long standing problem with captures. Were hoping your tech will help get rid of Captchas
… then we have the more general topic to discuss
… at least on a conceptual basis
<Fazio> Accessible Authentication - Web Content Accessibility Guidelines 2.2 Success Criteria
janina: Might be be able to associate user with preferences (font size etc)
… that can operate across devices
… resurrects idea from 1995 when we thought CSS would do it for us, but user overrides have not succeeded
… and even if they had, it would not be cross-device
… that's why we think VCs might help - think of them as config files
janina: But I want to start with the captcha question
CAPTCHA
janina: Everyone's looking forward to passwordless login
Fazio: A11y guidelines talk about success criteria
… one of them is accessible authn - read "Captcha killer"
<MacTed> Sadly, I think the biggest blockers to letting users set their own display preferences are Web designers who believe their way of display is the One True Way, and browser vendors who don't add "override all CSS" checkbox to their preferences which *do* let the user select default font and size (for monospaced and proportional).
<Lionel_Wolberger> The Captcha paper is here https://
Fazio: Problems of security that don't require cognitive tests
Lionel_Wolberger: I'm sharing my screen
… see Turingtest link
Lionel_Wolberger: Sets out the current problem
… the alternatives, like audio, are no better
janina: Speech recognition is now too good. Solving audio Captchas is no longer an effective check
… ASR systems can solve them
<nms01> +1 phila
Lionel_Wolberger: Looking at alternatives for a persistent Turing test
<kristina> I think this was the URL shared https://
Lionel_Wolberger: 'CAP' has a working prototype
Lionel_Wolberger: A recent sharp uptake of FIDO by Apple, we're excited about that also
… Smartphones are ubiquitous. The biometric function is v helpful
Lionel_Wolberger: So... VCWG... do you have any thoughts
<Zakim> manu, you wanted to comment on replacing captcha - "proof of personhood" is being done at some level for digital age verification.
<Jem> Accessibility Guidlines Github issues regarding accessible authentification: https://
manu: Welcome. Thanks for joining us
<matatk> Thank you kristina, sorry for not posting. This one is slightly more up to date: https://
<kristina> ah ok, thank you!
<kristina> is there a pointer to VC use-cases document you have worked on?
manu: I want to point out a number of things that you point out Lionel_Wolberger are representable as VCs, so the question is, can we creae a broader solution
<kristina> or is it the same one?
manu: cf. a single hardware device
manu: The concept of passing a Turing test and getting a bunch of tokens resonates
… The digital age verification systsm in the US, you have to turn up physically somewhere like a convenience store
… You have to show up in person to activate your token and the tokens that come from that. That's actually a Turning test
manu: The tech can suppport these use cases but what we are lacking is how does the individual a11y needs use that
manu: When it comes to presenting that at a website, we're lacking a11y interfaces that we're using
… so we need help from you in defining the interfaces
janina: We know we need to look at interfaces. We're a horizontal review group and 'interface' is a trigger word
Lionel_Wolberger: That was a helpful manu, we face a broader challenge of wallets in general
… in W3C, I hear you're involved in blockchains
… this s a type of wallet
<Zakim> gkellogg, you wanted to comment on asking about general accessibility of VCs
gkellogg: This is not specifically about captcha ... VCs are mainly a data model but they're intended for presentation
… so I wonder whether the VCWG has thought about presentation and esp a11y
manu: We have an a11y consideration in the spec now but it's a massive cop out "it's a data model, of course it's accessible"
… This is all going to come to the fore when we talk about presentation
… Unfortunately, even in this iteration, we don't have that. People are building against our spec but presentation isn't in there and therefore nor is a11y
<Orie> +1 to voluntary exploration of accessibility
manu: I don't know how structure that work other than requesting help from you when it comes up
Lionel_Wolberger: We do sometimes flag in a data model or low level API, we see future a11y issues. We've done that before and we could revisit your a11y section
… and look at that issue
ivan_: Manu preempted me. It's not in our charter to work on presentation of our data model. It will come up eventally. At the moment, it's not part of the our work
… What you just described as a kind of future looking comment... for later... that wojld be useful
ivan_: But to set expectation, we're not working on presentation
janina: We're not expecting something in 6 months
janina: Are you looking at cross-federated environments
<kristina> our charter: https://
<Jem> https://
janina: Is your current scope including - eg. - devices from multiple environments, say between an Android phone and a Mac laptop
Lionel_Wolberger: We also produce docs that are user requirements
<kristina> we can non-normatively talk about APIs/protocols, but cannot write normative documents on that topic
<manu> yes, huge +1 for digital wallet accessibility requirements!
Lionel_Wolberger: It could be that one take away today is that we need to look at digital wallet usaebility
<Orie> +1
scott: I agree
<shigeya> +1
scott: We try to look at each area and see what the potential user requirements are
<matatk> Example Accessibility User Requirements doc - this one is about XR: https://
Lionel_Wolberger: That might be how we engage
janina: It would point in the direction of a next charter
… we would look at the presentation layer and give you points to think about
scott: I agree, we could look at that
Lionel_Wolberger: We have thoroughly documented used case
Lionel_Wolberger: The task force will take up a11y usability requirements for digital wallets
Orie: Thanks for coming and participating today. 2 points to raise
… First, based on the VC data model, one thing I've been exploring, taking advantgae of the structure
… an arbitrarily complex VC might be difficult to perceive. is there a preferred order of nodes in the graph
… or maybe giving the user just what they need
… it's a graph traversal issue
… great opportunities to create experiences to traverse the graph
Orie: I've done a little exploration but a11y and UX for VCs are issues for us to explore.
… audio-visual experiences from the graph would be exciting
Orie: Second - maybe a use case for extensions like ad blockers that change experiences on web pages
Orie: We could take these user pref credentials and apply them in presentation
… I'd be excited to explore a prototype this, as a personal interest in this space
Lionel_Wolberger: Short response - we're always interested in alternative forms of data consumption. Graph traversal would be an interesting
<Zakim> matatk, you wanted to check on agenda timing
<Lionel_Wolberger> * Lionel asks the name of the person who just spoke?
<matatk> RQTF use cases for VC (feedback welcome): https://
janina: 60 million people in the US have 'a disability' but there are 60 million different disabilities [scribe paraphrase]
kristina: I think a brief overview of the use cases doc would be a good use of limited time
PaulG: Going back to the charter and implementations. It would be helpful for APA to have links to implementations you're aware of, even if just in passing
… this will be useful to look at s
PaulG: Looking at the charter, section 2.4, there's a lot there that have a11y issues
… the data model itself we can handwave over
<Zakim> manu, you wanted to note that I don't think we should wait two years to get a11y review, we have an implementation guide. and to huge +1 for digital wallet accessibility requirements
manu: Huge +1 to accessible digital wallet. The time to do that is now
<Orie> +1 Manu
manu: I don't want to wait a yeard for that. There are platforms you could look at now, even though it's out of scope for this VCWG
<manu> Rendering verfiable Credential: https://
manu: 'rendering VCs' work
… there will be some work done at RWOT, including visual and audio rendering
… are there ways of creating human prose about the VC
… and it is targeted at meeting a11y needs
… so a VC can be rendered in different ways
manu: That's something we'd like to get input on
<Orie> I've also looked at GPT-3 processing of content, such as text summary or sentiment analysis... really exciting area, but with some serious privacy considerations.
manu: Finally, today there are wallet engagement mechanisms that are dependent at taking out your phone and pointing it at something
… is that an a11y challenge - scanning a QR code?
janina: I think they're successful more often than not, but you should explore the not
scott: Finding QR codes to start with can be a challenge
Fazio: I know McDonalds were working on something like Monopoly that can be played without vision
scott: I also saw in Australia, guidance on how to get your phone in the right place
Fazio: My Bank of America app when I go to scan a cheque, it guides the user to move closer, further away etc.
<Orie> Related to "recognizing unreadable text identifiers", there is also https://
Lionel_Wolberger: It's successful more often than not. QR codes on menus seen as bad but actually no, because it's much more likely I can find the QR code and have the menu read to me
Lionel_Wolberger: Orie said he had some insights into addrsssing CSS persistence through a browser extension. I'd love to hear more about that
Orie: It's not a thing I've got a working prototype, but I have explored extensions that inject script tags. You have a VC that represents your CSS prefs
… and the extension would parse that and convert it into a style tag and inject it isnot a page. Privacy considerations. What other elements might detect that?
… and discern a disability
… If you look at the extension ecosystem there might be something to help build use cases
Janina: This also might be a way toward accessible wallets
janina: People do tend to have devices from multiple manufacturers
Orie: Password managers are typically sync'd across devices
<Zakim> phila, you wanted to ask about NFC
phila: I have multiple interests here. The applicability of QR codes is important to me.
… what about NFC? The capacity varies. There are alternatives to QR. And better barcodes
<manu> phila: Multiple interests here, interested in use of QR Codes from GS1 perspective. What about NFC? When you talk about QR Code, there are alternatives, QR is not the most high capacity thing in the world, there are better things than QR.
phila: that thing that goes beep at the border gate is not a QR code
Lionel_Wolberger: I'm not sure we know about NFCs
Fazio: I'd be concerned about privacy with NFC
… I'm worried about credit cards being used outside the wallet
sebastianelfors: We had a discussion in the FIDO alliance about VCs. We concluded the Hyperledger approach was interesting
… could be super-interesting for a11y
<Orie> I can say that webNFC and web bluetooth are not well supported outside of chrome... https://
[scribe missed some of that, sorry]
kristina: You mentioned Wallet Security WG in DIF, W3C universal wallet... please add URLs to IRC
Orie: There are several wallet initiatives. ... a series of interaction protocols, openID Connect, DIDComm (popular on Hyperledge Aries)
Orie: There have been conversations about Web NFC and wallets. What's the a11y angle. Outside native apps, those protocols can be less universally avalable
<Orie> https://
Lionel_Wolberger: We wanted to talk about the human care taker scenario ... very often a diabled person is in that situation
<Orie> https://
Janina: The standard example is the onset of Alzheimer's - one day someone else has to start making decisions and we need to cover those legal structures to do it
<Orie> another link, to keep an eye on: https://
<sebastianelfors> Here are the mentioned iniatives for wallet backup/restore:
Janina: I can't do any of this 'power of attorney' work electronically (has to be on paper). I need to find someone I can trust, ahead of time, to take this on. An electronic version would be v good.
<sebastianelfors> W3C Universal Wallet: https://
<sebastianelfors> DIF Wallet Security: https://
<sebastianelfors> Hyperledger Indy Wallet: https://
<sebastianelfors> And here's Orie's issue for specifying backup/recovery for the W3C Universal Wallet: https://
YanZhang: A11Y is v important. we talk about it internally a lot. The VC should be stored locally
<Orie> There are cases where you "sync" your credentials / messages to a new device from an existing one... migrating phones has gotten a lot easier recently... Android has done an amazing job of improving that experience.
Lionel_Wolberger: Something else we'd like to hear about. You say you don't do presentation. OK, but do want to speak for a minute about a person is who is associated with a advocacy association
Lionel_Wolberger: we'd love to see it working
<YanZhang> We are also considering for a certain type of VC or VP, we can make them into non-fungible tokens, which is much easier to be recovered
<Zakim> manu, you wanted to note caretaker/delegate VCs have been discussed, but we need more input from lawyers on what's needed.
manu: We're beyond PoC stage in many ways. There are companies here deploying this tech in real world (cites immigration services digital residency card)
… in the next couple of years. That whole flow is applicable to that uze case you just outlines
<Orie> If you are creating accessibility related credentials, you can consider: https://
manu: What we're lacking is the organisation to issue the creds
… You could hope for a rapid turn around
manu: The caretaker/delegate use case. A child travelling with someone other than their parents, people who have any kind of caretaker needs
… what we're misisng is someone to speak with authority in what those VCs should look like to have legal weight
… we're missing subject matter experts tbh
<MacTed> Need *lots* of lawyers for that. At least one per jurisdiction.
<matatk> Reminder of RQTF's use cases: https://
janina: I think we'll take to Wendy Seltzer
kristina: we're at time.
<Orie> There is a project in Austin Texas, regarding "helper" / "care taker" use cases for persons experiencing homelessness - https://
<Orie> some of our team members worked on this.
kristina: Chair hat off. There are multiple UX issues we need to look at, but they are out of scope of the communication choice (HTTP, Bluetooth)
… I think these are OOS for now.
kristina: Maybe different people are implementing different presentations. Now we know a doc is coming up, that's going to help a lot
<Lionel_Wolberger> * Lionel asks anyone wishing to investigate the accessibility of an implementation, contact me at lionel@userway.org and I will pass it on to APA and RQTF
kristina: Chair hat on. Thanks very much for coming
Lionel_Wolberger: Thanks for having us.
<Orie> I can scribe
Streamlining Data Integrity
<Orie> sorry, remove me from the scribe list.
<manu> Link to slides: https://
manu: This is around potentially major changes that we need to make in data integrity to addrss some of the challenges we've hit in reent years
… this is an attempt to be responsive to the community
… aim to do so befre going to FPWD
… Slides shows 3 topics to cover in the presentation
manu: The problem statement
… crypto suite proliferation
manu: What we ended up saying way back was putting all the cyprto suites in the VC
… we moved on quickly
… people said what about my crypto context
… Here we are many years later and people have had to take a different path.
… Started putting all the cryptosuites in the one context. people complained, and put them in discrete contexts on top of the VC context
… Whenever you need to use a specific type of crypto, you create your own context, include it at the top and you're fine
… no dependencies on others
manu: What this created was a new concern. So many crypto suite contexts, lost "just use the baseline context"
ivan_: This is not only a context file, it's a separate vocab, separate namespace and voc
manu: In practice they all share the same vocab
… each context file just picks and chooses out of that vocab
… typically shares the same vocab but uses a different context. That's today
manu: Some people like lots of crypto suites. Not terrible but in reality they're almost the same. All that really changes is the type That's it. Lots of work just to generate a new cryptosuite
manu: Potential solution
<Orie> Without a `@vocab` in v2: "@context": [ "https://
manu: How can we use effectively the v1 context as is but use the crypto suites people want
<Orie> with `@vocab` in v2 "@context": [ "https://
manu: Proposed solution is to define a base Data Integrity Proof type. All we're doing is changing the type. Proposal is to add a new property of dataIntegrityProof
… specifies crypto type as a string
manu: This is backwards compatible
… nothing breaks
manu: But there may be a subset of us who are keen to move on
manu: [Shows solution example]
… includes a v2 context. Defines the dataIntegrityProof type
… then specifies crypto suite as a string
{
"@context": [
"https://
"https://
],
"id": "http://
"type": ["VerifiableCredential", "AlumniCredential"],
…
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-2022", <-- this is now a string value
"created": "2022-02-25T14:58:42Z",
"verificationMethod": "https://
"proofPurpose": "assertionMethod",
"proofValue": "z3FXQjecWufY46…UAUL5n2Brbx"
}
manu: The V2 context would then cover the majority of VCs. No more proliferation of contexts
… if you need something more complex, the you can still do that.
manu: Bottom of the slide says: "Other potential crypto suites: nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, jws-2022, recommended-2022, selective-disclosure-2022, postquantum-2022, etc.
"
<sebastianelfors> How about post-quantum cryptos?
manu: Many devs have no knowledge of the differences between options. Should we just be specifying what's safe/recommended for 2022, 2023 etc
… Maybe we recommend options to make it easier
manu: Those are just ideas, but show that this V2 context file can cover all these
<kristina> sebastianelfors q+ to talk about post-quantum cryptos.
gkellogg: Have you considered URIs instead of strings
<Zakim> JoeAndrieu, you wanted to ask about semantic disambiguation & centralization in the vocabulary
JoeAndrieu: This in part doesn't seem to use the traditional JSON-LD disambiguation mechanism. Who controls the string for each cryptosuite?
<Orie> A registry use case!
manu: Don't know. We will specify strings
phila: I had the same idea Orie
<Orie> centrally managed registry... just like IANA :)
JoeAndrieu: We're allowing potentially ambiguous strings to be functional
manu: That stops proliferation
<kristina> "The specification of new cryptographic primitives" is out of scope for v2. assume "a group defining cryptosuites is either implementers in this WG or CCG..?
JoeAndrieu: No it doesn't. There's no look up
<Zakim> brentz, you wanted to ask why DataIntegrityProof not its own context
brentz: Chair hat off. Sounds like a reason for a registry...
brentz: Why would data integrity proof be described in the V2 context rather than it's own data integrity context
manu: That would be an option, but it's about convenience. people say I really don't want to have to keep including lots of contexts
manu: This really is a bunch of engineering trade offs
sebastianelfors: Computer security resource centre, currently doing work on post-quantum. Should we take post-quantum into account?
manu: Yes, we have to consider post-quantum
manu: Whatever solution we have has to take account of post-q
gkellogg: Why strings, not URIs?
gkellogg: They can be used the same way but a URI has the potential to describe itself
… and can be used to verify
<sebastianelfors> Here's NIST CSRC program for post-quantum cryptos: https://
manu: we could use a URI in here, but it might be fairly long which has consequences for things like Qr codes
<Zakim> mprorock_, you wanted to likely respond to pqc
<Orie> https://
mprorock_: We know there has to be crypto agility. We had a call with some relevant experts. We shouldn't be defining cryptography here
<Orie> +1 mprorock, I'm q'd to talk about overlap with VC-JWT / JsonWebSignature.
mprorock_: We know that stuff will come and as we talk later about multiple signatures, how are the big guys doing it etc that's when we get into practicalities
… it would be great to hear from people with experience
ivan_: This sounds similar to the discussions we had this morning. For the lambda user, there is only one context user to add. But now they have add something else
<Orie> To be clear, I am in favor of a "single context file" being enough... and for it to include a default vocabulary that covers private claims.
ivan_: This change I think is a big improvement in usabulity
ivan_: But I think we won't avoid having some sort of registry for these things
<Orie> +1 Ivan
ivan_: And to Brent - don't mix up the context and the vocabularies
<mprorock_> +1 ivan
<Zakim> dlongley, you wanted to say that a lot of the discussion here has to do with being practical for developers
dlongley: These solutions are responsive to developers
dlongley: We talked about that earlier (JSON-compatible JSON-LD etc)
dlongley: The number of useful crytpo suites is much smaller than the number of VCs in the wild
dlongley: So it scales
tplooker: Support in general for this. Makes it more manageable. Certainly experienced multiple context files being a problem for customers
<Zakim> Orie, you wanted to explain JsonWebSignature2020 and COSE WG Post Quantum Signatures
tplooker: On the intersect between what Dave was saying - technical purity, I agree. On stability designing extensibility for crypto suites... addressing a subset of problems for practicality
[ tplooker please check my scribing, I don't think I caught your words at all, sorry]
[orie talked about explain JsonWebSignature2020 and COSE WG Post Quantum Signatures]
Orie: We had the slide earlier where we were mapping between terms. Private claims - a crypto suite is a private claim - essential functionality with out of the box semantics - Generally I'm supportive of the idea for a simple context file that covers what we need for V2
selfissued: Why not just have a context for a cryptosuite that is extensible, logical, no registry to maintain
… that seems the logicaloption to me
pchampin: String vs IRI discussion. If there is a registry which, from my POV seems a good idea, then every string can be made into an IRI
… even without that, there are solutions in JSON-LD where those short strings can be made into IRIs
<Zakim> JoeAndrieu, you wanted to say the mere existence of emerging post-quantum cryptosuites highlights the need for decentralized disambiguation.
JoeAndrieu: I appreciate what selfissued just said. I think a single context file is not an extensibility model
<Zakim> manu, you wanted to "why not just use different cryptosuite contexts"?
JoeAndrieu: we have to understand the context and we have to accept a potentially ambiguous string. Doesn't sound right to me
manu: In response to selfissued why not just use a different cryptosuite? Bc people complained
manu: Devs seemed to be fine with creating a context for different use cases. But when you include the crypto suite, they start to complain
<Orie> it would be better to just add this to v2: "@vocab": "https://
manu: It's arguable that we're using the model in this specific way. Are the trade offs worth it?? Fallback is to carry on doing what we're doing today but we know people complain about it
<Zakim> mprorock_, you wanted to ask a simpler question
mprorock_: I was going to ask - what would JOSE do?
<Orie> or this: "@vocab": "https://
mprorock_: Why don't we just define semantics for JOSE kty, alg, etc.. What's the additional complexity we need above what JWTs etc
mprorock_: I want to attach signatures, but are we going too far and creating additional probs for ourselves
<Orie> manu, vc-jwt doesn't DO tranformations ; )
mccown: I like this proposal. Whether the format is right I'm not sure. I chair the DIDComm WG (?) There are 3 acceptable crypto options for post quantum (in hte US)
<Orie> but the point is well taken, you could use the vocab to point to a w3c registry that disambiguated.
mccown: there's always going to be multiple signatures needed
mccown: I can pick my favourite algorithm and then the client agent what it supports. If there;s an industry standard, that wold be super helpful
dlongley: To respond to Mike. JOSE is great at expressing every option
dlongley: What it doesn't do is provide a layer that describes a set of layers that are safe to use
<dwaite> best mic of TPAC so far
dlongley: Might include things like c14n algorithms etc
<JoeAndrieu> sounds like a good use of a context for each of those well-formed cryptosuites
dlongley: being able to define these profiles is very useful.
<Zakim> manu, you wanted to note we can't just point to IANA because they don't cover transformations.
<Orie> Thats correct Manu, but specific to Data Integrity.
manu: Dave has said it best. To be specific - why can't just point to JOSE, We can't just point to the registry and say use that.
<Orie> +1 to a new registry for "new parameters".
manu: [gives example]. There are params that are needed that don't go into these crypto suites
<JoeAndrieu> -1 to new registries
mprorock_: Can we keep this simpler, maybe with registries, think about the dev process.
<Orie> I can't wait to see "ProofOfWorkFreeRevocationList2022"
<dlongley> you don't want software to automatically allow any combination of parameters -- so you need a name (aka cryptosuite) underwhich to bind them all.
mprorock_: I want to keep more aligned with IANA. I trust W3C to talk about RDF canonicalisation, but not to pick "this is the set of crypto you should use"
selfissued: Responding to dlongley - I don't agree that JOSE allows all the choices. It only allows things that we think make sense
selfissued: being able to use bad combinations is not good [paraphrase]
kristina: I think the group agrees with the problem statement an the need to solve it.
… Some divergence on registries
<Orie> +1 manu
[Discussion about what the straw poll will be about]
<mprorock__> Going to clarify: I want JSON-LD, I want an array of signatures, I also want those sigs described and pointed at iana
JoeAndrieu: I'm not sure what you mean by the problem statement?
kristina: The problem slide that Manu showed
<mprorock__> *described using existing terms
JoeAndrieu: I don't know that we have consensus on that. I don't think a context that unambiguously references a crypto suite is a problem, I think it's a feature
kristina: OK, we'll start there
Is the proliferation of cryptosuites a problem for data integrity
<manu> +1
<mkhraisha> +1
<JoeAndrieu> -1
<mprorock__> +1
<Orie> +1 (yes it is)
<dlongley> +1
<tplooker> +1
<ivan_> +1
<decentra_> +1
<mccown> +1
<shigeya> +1
+1
<JoeAndrieu> what about the quantum!?!
<cel> -0.25
<selfissued> -1
<nadalin> -1
<MacTed> +1 (it does and will cause confusion in the user spheres)
<dwaite> -1
<dlongley> (the ergonomics of implementing them is more challenging than it needs to be, it's not necessarily that there are "too many")
<Zakim> kristina, you wanted to ask for next steps
<MacTed> (...we're gonna need a crypto suite rubric...)
<kristina> WG should define a base Data Integrity Proof type
<manu> +1
<ivan_> +1
<tplooker> +1
<mprorock__> +1
<dlongley> +1
<Orie> +1
<mkhraisha> +1
<mccown> +1
<shigeya> +1
<cel> +0.9 (DRY principle - but appreciate extensibility)
<JoeAndrieu> +0 (plus to the definition, - to Manu's version)
<TallTed> _0
<Zakim> gkellogg, you wanted to ask what group would have the long-term responsibility of managing a registry?
gkellogg: I'm guilty of writing specs that need registries
<Orie> great question!!!!!!
gkellogg: Question is what group has the long term resposnsibility for maintaining the registry
<mprorock__> Excellent question
gkellogg: Not saying whether it's a good or bad ide, just asking a question
kristina: We have a session after the break about registries
<Orie> +1 to the speaker.
pchampin: Joe talked about a context that identifies an uanmabiguous crypto suite That's not what a context does. I think you're talking about string vs IRI
<nms01> crypto suites in a standards specification is another form of registry
<mprorock__> +1
<Zakim> JoeAndrieu, you wanted to say cryptosuite proliferation is a fact, not something we can specify away
JoeAndrieu: Whoever is creating this VC will identify the crypto.
… separating out the data integrity proof from the V2 context makes sense. But let's not add in ambiguity. We are going to have more crypto suites
<cel> https://
JoeAndrieu: we can't lock down our crypto suites, we need to allow others and it can't be by reference to a registry that says A is OK, B is not [paraphrase]
<nms01> registries that enforce a policy aren't registries, they are policy enforcement points
Orie: At the risk of blowing the registries conversation, it's worth just checking in what are we talking about putting in a registry. There's always the ability to build your own crypto suite
<mprorock__> +1 orie
Orie: If you think this is going to kill decentralisation, it's not. You can still do crypto for you and your friends. It's a registry of known crypto suites
<Zakim> dlongley, you wanted to say because that disambiguation is worth the squeeze in an open world, but not for a closed or "small" world
<mkhraisha> +1
dlongley: Big +1 to Orie. Disambiguation is worth the squeeze in the open world, but not the limited closed world. The number of crypto suites is use is actually small
dlongley: You just don't need massively decentralised extensibility. In the VC space it makes sense, but for crypto it's a much smaller set
… Need to choose a fit for purpose solution
<Orie> +1 to ivan's framing.
<dlongley> +1 to Ivan
<mprorock__> +1 ivan
<manu> +1 to Ivan
ivan_: I just realised we may have missed a point If I understood Manu, the mechanism we have today would remain as an option. What we're looking at, I think, is making it easier for the 80%. The 20% can use the existing painful mechanism
tplooker: I was going to make a similar point. Manu's proposal was about keeping the simple things simple, but allowing more complex decentralised approach if needed
<dlongley> +1 to tplooker
tplooker: Crypto is a highly specialised industry. Should allow people to innovate - this proposal doesn't stop that.
<dlongley> +1 to getting "more secure by default"
mprorock__: Violent agreement. You won't be secure by default but we can work in that direction. Need to be careful of Not Invented Here
… What put me off VCs at first is that some of this stuff had been solved before
… we do have the ability to make breaking changes if we have to, but we don't want to close things off that we don't need to.
kristina: Thanks everyone for the conversation
<Orie> +1 mike, safe defaults.
kristina: We have good agreement, but not full agreement
… there will be different views on different contexts
kristina: Seems to be rough support for a registry - may change after the break
kristina: Proposal does not eliminate current approach.
… so some support for proposed solution
<JoeAndrieu> note: I don't agree with the statement of support or consensus on this issue