Verifiable Credentials Data Model 1.0 #343
Comments
|
Hi. Chaals Nevile suggested that @hadleybeeman might be a good reviewer for this. PLH also suggested that it might be helpful if we were to get on a call and give an overview and answer questions. We would be happy to do so - just let us know. |
|
Our original answers to the security and privacy questionnaire last fall (before support for ZKPs and JWTs) are at: https://docs.google.com/document/d/1cU2WHRWZ3rM4pzff87HMHIPlZIA_NZ0EyFR9YVuwOvo/edit Our answers to the new questionnaire from about a month ago (including all features in the spec) are at: https://docs.google.com/document/d/1k1Y3XLRJ25iTNC_U5rOywxd4di4ytm1y-ARUaGZIjH4/edit David Chadwick, PING member, helped us write these. |
|
+1 for using the new security/privacy questionnaire :) |
|
Quite verbose privacy considerations, I'd say. Long, too. If desiring to simplify, this might be the place:
When discussing later "It is recommended that privacy-respecting systems prevent the use of these other tracking technologies when verifiable credentials are being used. In some cases, tracking technologies might need to be disabled on devices that transmit verifiable credentials on behalf of a holder." It's not clear how/when "tracking technologies" should be disabled or why this would be preferable. Maybe better like "Systems deploying ... should consider disabling tracking technologies..."?
Good thinking and illustrative. |
|
Thanks @lknik . PING was quite extensive in their requests for considerations outside the scope of our document model and charter. We will look at your suggestions and see how much we can apply without encouraging a request for more detail again :) |
plinss
changed the title
|
Hi TAG! I just wanted to make you aware of these concerns, and also that we've recently opened a number of tactical issues agains this spec that the TAG might want to look at as well--primarily these focus on places where the spec assumes JSON-LD and doesn't leave room for JWT/CWT. (For example, see w3c/vc-data-model#491) |
|
Hi all, and thanks for bringing this to us. We have a couple of questions here, though we'd like to look into the data model further for next week and get back to you on that:
Thanks again! |
Yes, the core vocabulary will be the Verifiable Credentials Data Model v1.0 vocabulary, a working version of which can be found here: https://www.w3.org/2018/credentials/ Note that this is a base layer vocabulary that is expected to be extended by particular market verticals (those market verticals, specifically education, government, and supply chain) are participating in the VCWG. More on that below... Did the answer above address your question, @hadleybeeman?
To provide a concrete example of a real world deployment... a number of US Supply Chain companies (importers, manufacturers, and retailers), along with the US Federal Government, are utilizing the technology to modernize old paper based processes using Verifiable Credentials. See the US Capitol Hill testimony for direct references to support of Verifiable Credentials at W3C (UPS was also a part of the testimony): https://youtu.be/J7aCUM2RfJA?t=35m25s An article outlining how Verifiable Credentials are being used can be found here: https://www.americanshipper.com/news/cbp-planning-blockchain-tests-for-trade-compliance We also shared who some of these organizations are under W3C Member Confidentiality at last year's W3C TPAC (see slide 9 -- yes, it's for the DID WG, but the reason they want the DID WG is because almost all of them are using Verifiable Credentials and they want to tie them to Decentralized Identifiers): Another concrete example (that's public, there are many that are wrapped under NDA right now) is the Canadian Province of British Columbia's Verified Organization Network: Also note that education organizations such as Credly and BrightLink are also involved (to issue VC's for learning use cases). The thread that ties all of these use cases and organizations together is the Web. They use websites to issue, store, and present Verifiable Credentials. Many are defining Web-based/HTTP APIs for the protocols (work continues in the W3C Credentials Community Group on that part, since larger organizations at W3C were successful in constraining the charter to only work on data model and not protocol or signature mechanisms). The products that are being created today are: Verifiable Credential issuing platforms (Credly, BrightLink, Veres Issuer, etc.), Verifiable Credential Repositories (Digital Wallets - Attest Wallet, Veres Wallet, Connect.me, Verify.me, etc.), Verifiable Credential Verification libraries/products (Attest Enterprise, Veres Verifier, Connect.me, Verify.me, etc.), and fit-for-purpose blockchains (Hyperledger Fabric, Veres Delta, Corda, etc.) that utilize Verifiable Credentials (off-ledger) to provide provable/auditable statements from governments/industry. Does that provide enough background, @hadleybeeman?
The VCWG is currently working through the large amount of issues filed by Microsoft and will be doing so for the next 3-4 weeks. @hadleybeeman there is much more I could say, but am limited by time and github comments. Happy to have a recorded/scribed conversation to elaborate on any further questions to help in the W3C TAG review. There is a lot to what is going on wrt. Verifiable Credentials deployment and usage around the world. |
|
Hi all. We've revisited this in our face-to-face in Reykjavik. And thanks for your extensive comments. From us:
|
|
Hi @hadleybeeman and TAG I'm one of the co-chairs of the VCWG. Here's where our schedule sits. We are closing the CR period and preparing to transition to PR. Implementors are active and implementation reports are coming in with positive coverage. Since we have limited time in our charter, we're very motivated to help bring the TAG up to speed on these related topics. We'd like to setup an informational meeting at your earliest convenience. I'm sure we can get aligned on the narrow Data Model scope and how it fits in the web ecosystem. We hope there will be future work that extends this concept but it is outside the purview of our charter. Is there time on the schedule before July 5 for a sit-down? We'd like to close this issue by mid-July so we can complete our transition to PR. |
|
It seems that there have been enough normative changes to have another CR before moving on, I still have unanswered questions about interop of the data model and usages of changing specification (JSON-LD C14N and JSON-LD Signatures) as proof points.
From: stone <[email protected]>
Sent: Thursday, June 27, 2019 9:11 AM
To: w3ctag/design-reviews <[email protected]>
Cc: Anthony Nadalin <[email protected]>; Mention <[email protected]>
Subject: Re: [w3ctag/design-reviews] Verifiable Credentials Data Model 1.0 (#343)
Hi @hadleybeeman<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhadleybeeman&data=02%7C01%7Ctonynad%40microsoft.com%7Ca112775e90d142122a2808d6fb19fd66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636972486370056759&sdata=qfB6HBsHFhwVnT%2FRauCnBCQQeet86a7Osthahj7QNhY%3D&reserved=0> and TAG
I'm one of the co-chairs of the VCWG. Here's where our schedule sits. We are closing the CR period and preparing to transition to PR. Implementors are active and implementation reports are coming in with positive coverage. Since we have limited time in our charter, we're very motivated to help bring the TAG up to speed on these related topics.
We'd like to setup an informational meeting at your earliest convenience. I'm sure we can get aligned on the narrow Data Model scope and how it fits in the web ecosystem. We hope there will be future work that extends this concept but it is outside the purview of our charter.
Is there time on the schedule before July 5 for a sit-down? We'd like to close this issue by mid-July so we can complete our transition to PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F343%3Femail_source%3Dnotifications%26email_token%3DAB4R4Y6AGYW4V7YZTEKJ6Z3P4TQ7XA5CNFSM4GWRA7M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXTT5Q%23issuecomment-506411510&data=02%7C01%7Ctonynad%40microsoft.com%7Ca112775e90d142122a2808d6fb19fd66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636972486370066754&sdata=g6GsPSmpWxAERFwtPopqCDiG126cgivoux%2BPa91RnsI%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB4R4Y7WUP6QVJ5QBAB2RUDP4TQ7XANCNFSM4GWRA7MQ&data=02%7C01%7Ctonynad%40microsoft.com%7Ca112775e90d142122a2808d6fb19fd66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636972486370066754&sdata=CpMvAdaEkY8cQuBJG31BKtr%2BgEQEFkAp%2Fp37A6HbyZQ%3D&reserved=0>.
|
|
@nadalin wrote:
There have been ZERO substantive/normative changes to the specification. In fact, the Working Group has been very careful and methodical to NOT do that. It is not appropriate for you to make these sorts of assertions about a Working Group for which you are not a member. I defer to the W3C VCWG Chairs to provide an official update to the W3C TAG. |
|
@nadalin wrote:
As one of the Editors of the specification, and as one of the people that either authored or reviewed every single one of the changes you are citing, your assertions are baseless. The WG has a resolution for every single one of the changes being non-normative and or non-substantive and is prepared to defend every single one of them in a transition call if that's what it comes down to. I suggest we let the VCWG Chairs take it from here, @nadalin, as you are not a member of the VCWG and thus it is inappropriate for you to make these sorts of statements as to the status of the work. |
|
Hey all! The proposal for a potential PR transition came across our transom, and quickly reviewing the spec I had a few questions:
Regards |
|
JWT Serialization is pretty straight forward, Compact Serialization is the most common serialization format that I have seen for JWT, just Base64 Url Safe encoded information separated by an dot. What I have not figured out yet is the RDF DataSet Normalization that is required for the JSON-LD Signature specification . |
|
NOTE: This is not an official response from the WG, just one of the Editors of the spec (and a corporate implementer) responding.
Great question! Yes, we considered CBOR and yes, we're aware of JWTs shortcomings :) ... https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs Note, though, that JWT is not the serialization format. JSON and JSON-LD is the data model serialization format. JWTs and LD Proofs are the proof format (e.g., digital signatures). We would have preferred to use COSE for the digital signature expression format but the work and library development wasn't at the point where the group could rely on it. Even to this day there isn't a decent CBOR implementation in isomorphic Javascript (use of node.js Buffers everywhere for no reason) and no Javascript COSE implementation exists for a variety of different languages (and attempts to compile to wasm have been deemed too bleeding edge for the companies deploying Verifiable Credentials today). In the future, it should not be difficult to express the data model in CBOR (we have internal experiments that already do this), and then digitally sign the data using LD Proofs (with a COSE signature... which is where some of us want to go), or CWTs... but for that future to unfold, a good chunk of the developer community is going to have to get the underlying CBOR/COSE library support there.
We are aware of the Signed HTTP Exchanges work (I'm the editor for https://tools.ietf.org/html/draft-cavage-http-signatures-11). Since the data model is designed to be separate from the proof format, someone could "sign" a Verifiable Credential using SXG (in theory). No one in the group felt like SXG was ready to be used in a W3C REC-track spec. I just took a quick look again to try and see if the SXG format was published anywhere, and was having a hard time finding a spec for it. I also took a look in a hex editor at some of the example files in the chromium source repo example and couldn't make heads or tails of the format. Do you have a link to the SXG file format? It would help us determine how easy or difficult it would be to express a Verifiable Credential using an SXG as the proof format.
Yes, thought has been put into that but browser vendors seemed hostile to the idea of anything JSON-LD related going into the browser (this was 4+ years ago). Things may have changed now that Google is including jsonld.js in the browser as a part of their Lighthouse tooling. If the browser vendors want to explore putting JSON-LD + LD Proofs (or JWTs) into the browser, we'd be happy to discuss.... but Almost all of the digital signature and verification for Verifiable Credentials happens on the server or in app and not in the browser. We do have isomorphic Javascript libraries that can use the WebCrypto APIs if they're available, but there has been little desire to work on that as most (maybe all?) of the production implementations sign stuff server side. The WebCrypto APIs also don't expose the digital signature schemes that are most heavily used for Verifiable Credentials either (ed25519 and secp256k1). Does that answer all of your questions, @slightlyoff? |
|
Hi all. We are returning to this at our F2F in Tokyo. We'd like to resolve it ASAP, so it would be good to sort these questions:
What important parts of this are currently out of scope? We are still unclear how this spec fits into the ecosystem you imagine, and how that works with the web architecture. If you can help us understand this, we can close it in the next day or two. If not, we're not sure we can add much value here. |
|
Apologies. I thought I had sent a message months ago (either as email or here) making clear that we are not specifically looking for any particular feedback from TAG. We had offered to schedule a call with TAG members at any point to cover the ecosystem, etc., but did not receive a response to that offer.
The working group continued to affirm its interest in providing as much in the way of non-normative recommendations that it could. No changes to that section have been made. If absolutely necessary, changes such as those suggested by @lknik could be added post-Recommendation in the Credentials Community Group, which is the group the WG explicitly named to handle maintenance.
As I mentioned above, we offered to meet with the group and cover your questions live, as the quantity of work outside the charter but relevant here is quite substantial, more than can be addressed by a few document links. Most relevant to the question by @travisleithead , however, is that production, transport, storage, use, etc. of the data model document was specifically chosen to be out of scope at the explicit request of several companies, including I believe, Microsoft. The charter was thus approved with the narrow scope we have been operating under for the (now complete) lifetime of the group. Feel free to ask the W3C team why the objectors to a broader charter did not wish a more complete set of work to be done at W3C; since some of the objections were private, I am not in a position to speak to that myself. Within the limitations of our charter, the working group members are satisfied as to the interoperability of the data model.
We do not seek particular feedback from the TAG at this point. Many of us, myself included, will be at TPAC next week and would be happy to help you or others understand the broader (and growing) ecosystem in which this now-completed work plays a part. I will be co-chairing the new Decentralized Identifier Working Group on Monday and Tuesday. Please don't hesitate to come find me or @msporny . |
|
Thanks, @burnburn. We appreciate your quick reply. We had this issue open because you requested a TAG review. Apologies if we missed a subsequent "Thanks but never mind" comment! We will close this now. I'd also like to add, because I'm concerned we may have generated some confusion here: the TAG's remit isn't contained to work within W3C working groups. Our charter says "The TAG will coordinate its work with other groups within and outside of W3C whose technologies have an impact on Web architecture." In practice, that means that we offer advice on work from community groups, TC39, the IETF, WHATWG, and others -- as well as work from W3C working groups. Our interest in your complete ecosystem is where we may be able to add value to your work, given that it sounds like that is where verifiable credentials may have architectural implications for the web. This is why we've been asking for information beyond the scope of your W3C working group's charter. Also, one of our tenets for the web is that all of the documents and specs that form the web technologies are fully open and visible -- which is why we haven't taken up your kind offer for a call. We are keen to see this fully documented in the open, ideally in a standards venue in due course -- though initially, we'd be happy to see it in a GitHub repo or otherwise published on the web. Hope that helps, and we do wish you luck with this important work. |
hadleybeeman
added
Resolution: unsatisfied
こんにちはTAG！
I'm requesting a TAG review of:
Further details (optional):
You should also know that...
This specification (and the working group) was specifically restricted, in the charter, to only be about a data model and one or more syntactic representations of that data model. We are not allowed to provide any normative answers to any questions regarding protocols or APIs that may use this data model, although we are happy to informally convey expectations held by the majority of the group.
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: