The W3C Credentials Community Group

Meeting Transcriptions and Audio Recordings (2014-today)

Go Back


W3C CCG Weekly Teleconference

Transcript for 2022-10-04

Our Robot Overlords are scribing.
Harrison_Tang: Hello everyone, so welcome to the W3C CCG meeting. So today our main agenda we are very glad to invite Mike and Nick from Dock.io to present their Dock cert as well as their new Web3 ID products. But before we get to the main agenda, I just want to talk about a couple IP notes as well
Harrison_Tang: as the introductions, reintroductions, and
Harrison_Tang: action items, and work items if needed, if there's any. Alright, so a quick reminder of the code of ethics and professional conduct. You know, I think the key thing is just making sure that we create a psychologically safe environment. This is not to say we cannot have differing opinions. We welcome different opinions and hard questions, but at the same time, let's just make sure that you know we
Harrison_Tang: acknowledge each other's voices and make sure that
Harrison_Tang: we be respectful of each other. Anyone can participate in these calls, however all substantive contributors to any CCG work items must be a member of the CCG with the full IPR agreement signed. So there are links in the emails as well. These minutes and an audio recording of everything said on this call are archived in the meetings. We are actually working on publishing them in a more timely manner right now, so that if there are a couple
Harrison_Tang: of meetings that we
Harrison_Tang: haven’t got the meeting minutes published, just give us a couple of days or weeks and then we'll get them. We use IRC to queue speakers during the call, as well as to take minutes. You can type in Q+ to add yourself to the queue and Q- to remove yourself to the queue. If you are now in the chat, simply asked to put on the queue, and be brief so that the rest of the queue
Harrison_Tang: can have the chance to chime in if there's a lot of questions.
Harrison_Tang: I think now is - are there any new members… like introductions and reintroductions of the new members of the CCG meetings, please introduce yourself.
Harrison_Tang: Rishi, please. Alright, any other one want to take a moment to kind of introduce or reintroduce themselves?
<rishi> Sorry, unable to unmute on the browser.
Harrison_Tang: Alright, any announcements or reminders?
<rishi> I'll introduce myself here.
Harrison_Tang: Sorry, Rishi, you want to take a moment to kind of introduce yourself to the community?
Harrison_Tang: Oh sorry, I think you have some browser technical difficulties.
Harrison_Tang: Right, I think once we figure it out, please feel free to add yourself to the queue, or next - we have this meeting every Tuesday, so feel free to speak up anytime you need it. Alright any announcements or reminders?
<rishi> Yes, I'm rishi, from India. Just started exploring the space and interested in getting to know you all and contributing. :)
<rishi> Hello everyone
Harrison_Tang: Alright, updates on the work items. I think last week we approved a work item. Any other updates on that?
Harrison_Tang: Alright. Oh Dmitri, please.
Dmitri Zagidulin: Sure. So not a formal update but just to say that this past week, The Rebooting Web of Trust conference happened in the Netherlands, the Hague, so expect lots of juicy papers and potential work items to come your way to the CCG. So there was really good credentials-related papers worked on by a number of parties so just a sneak preview.
Harrison_Tang: Thank you. Any other announcements or reminders?
Harrison_Tang: Alright, so let's get to the main agenda and we'll leave the last 5 minutes for any other announcements if people - if it comes up - or introductions and reintroductions. So you know today we have the pleasure to kind of invite Nick, the CEO of Dock Labs, and Mike, to kind of show us about what they're working on at the Dock. io, in particular the dock search and
Harrison_Tang: the Web3 Id products.
Harrison_Tang: The new sign-in with Ethereum and Web3 ID products that they punch. Now I read quite a bit about it on LinkedIn and different parts of the web, and I thought - you know, they could have great experiences to share in regards to implementing Open Standards, maybe trade-offs in designing their solutions, as well as the thoughts on how do we actually find the product market fit, so please welcome them and thank them for taking the time to present
Harrison_Tang: at W3C CG+CG and
Harrison_Tang: doing a demo as well.
Harrison_Tang: So without further ado, I'll pass the Baton to Nick and Mike, thank you.
Mike_Parkhill: Alright, sounds good.
Mike_Parkhill: Alright, so I think you can see my screen now.
Mike_Parkhill: Alright, so I've got two screens up here actually showing. One is my browser, so that’s the Dock search thing and the black thing on the right is actually our wallet app so you'll get a bit of a peek at what that looks like as I do this demo as well. So I thought I’d start with the Web3 ID just because we have it as an entry point into our Dock Certs, so sort of an easy way to sort of work it in, and as Nick said, Web3 ID, it started as sort of a way, you know, how do we make adoption of using your DID as an identifier for you,
Mike_Parkhill: easier to use, easier to share. Everyone's of course used to signing in with Google and signing in with Facebook.
Mike_Parkhill: And we have it right here, sign in with Google and Github.
Mike_Parkhill: There's obviously downsides to doing that, there's a lot of privacy there, you can be tracked a lot more easily, that kind of thing. So like, okay, this decentralization of identity thing. How do you make that easier? How do you make it simpler for people to use that? Well, let's see if we can build the idea of a Web3 ID and of course, Web3 sort of marketing thing, but it's how do we use Web3 ID to allow people to do the same thing, to sign in using a DID in their wallet that they control. And they can have multiple DIDs, so in my wallet here, you can see I've got three different DIDs in here, so
Mike_Parkhill: I could choose any one of them or I could add a new one, create a new one, whatever I wanted to sign in with it and sort of just the idea of you know
Mike_Parkhill: you represent different identities,
Mike_Parkhill: different places, so if you use Google then you've got one Google thing unless you have multiple emails of course, but you kind of get stuck in this thing where Google knows everything you do no matter where you go, they track you everywhere, or Facebook - whoever you're using. So this allows you to compartmentalize little bit more. Like obviously you can have one DID for every site you go to if you want to but that becomes its own nightmare but at least you know you could do something like what I have here where you’ve got buckets - you got like your work bucket, your social bucket your bank's bucket or whatever, that kind of thing. So it's kind of the idea of how do you make -
Mike_Parkhill: now you've got a decentralized identity - how do I use it? So again we went with OAuth 2.0
Mike_Parkhill: Just to sort of
Mike_Parkhill: get into a standard that’s well known and well used by developers so it's not reinventing the wheel, it’s not trying to convince people to change the standards they are to use, which is just a couple of sort of weird things like user lookups and stuff - you get nothing back from us because we don't track anything. And if you're curious about how we doing all this, I will just mention that our off server code is fully open source you can find it on our Dock Network GitHub page so if you want go poke around see we're doing in there, feel free. It's pretty small there's not a lot of code to it and we don't track much
Mike_Parkhill: in there or really anything. There's a little small cache that keeps up briefly but doesn't stick around for very long.
Mike_Parkhill: So to use it, it’s very simple you click on the button. Sign in with Web3 ID, it shows a QR code, and now I just need to get my phone to wake up.
Mike_Parkhill: And I think it's gonna scan.
Mike_Parkhill: So here on the wallet, when you have scanned it, you're presented with the option here. So you want to choose which DID you want to use so I'm just going to use my work one for this, and provide a name you can provide an email. So the email and the name are actually optional, it's up to whoever is integrating with the the Web3 ID authorization to choose what details they want from you. In a very pure decentralized way they could say they don't want anything.
Mike_Parkhill: For us, we were asking for your name and your email address because obviously we are a business
Mike_Parkhill: so we want to know who's using our
Mike_Parkhill: system and signing in to us, so we are asking for that. But if you want [_____] with this, you wouldn't have to, that's not required. And then we just store it locally in the wallet as a convenience so next time you come back you won’t get prompted again to re-type everything, it's just kinda available. So I'll say alright approve that.
Mike_Parkhill: As you can see we're now signed in to Dock Certs, so I didn’t have to enter an email, I didn't have to go find an email link and click or anything like that, it's just done. In the background what we did there was from the wallet we sent a self-signed verifiable credential, so there's actually a VC being sent in the background and it didn't have to be a VC, it could have been any message that we sign in using our keys and using the keys to verify it’s us, but by using a VC it's using stuff we already have, like we already have all the utility functions and all that around
Mike_Parkhill: VCs so why not use what we have right? So it just made sense technically for us to do that solution.
Mike_Parkhill: So that's sort of what is going on
Mike_Parkhill: in the background. So a VC gets sent into the background to the [_____] server. It verifies that, you know, you have the keys, you're the owner of that credential, that DID, and lets you in and now that DID is associated with your user in here. But for existing Dock Certs, so it's next stage. So Dock Certs, [_____] start out as a lot of things in the startup world, and I'm sure a lot of you're familiar with, as kind of a proof concept. So we built our rest APIs with the idea of supporting developer communities to get into VCs and DIDs and
Mike_Parkhill: everything. We're finding we're talking to a lot of customers who didn't have.
Mike_Parkhill: The development teams of their own to sort of work with rest apis or they're having a hard time sort of visualizing what it would look like, so like “Oh let's throw together an issuer portal, so we can give them a demo app to fill you with” and now it's kind of taken on a life of its own is as these things often do. But this is sort of our issuer portal. We now have customers who exclusively use this, we have some who use the API and work with it because it's got some of your dashboard-y sort of things you can control - your API, your keys, and we can support web Hooks and that kind of stuff in here, and links to
Mike_Parkhill: your documentation and all that, so you know it's got the developer pieces to it but is also where you can come in and issue credentials.
Mike_Parkhill: So when you go to issue a credential, the first thing it’s going to ask you is who’s issuing it. We don't generate any profile for you or anything right away to begin with, you have to generate one yourself. So the first thing it is asking me to do here is to create my issuer profiles, this is DID, and you put a name on it so we'll just say Demo Mike. You can choose your key type, we support at these three key types and most people never change it. And so you’ll probably actually be that, you can add a logo if you want to upload a picture, and that kind of thing.
Mike_Parkhill: We won’t bother with that at the moment.
Mike_Parkhill: Alright so we have a DID, and the next thing is to create a schema, so right now we have these two default schemas - basic and university degree - they're very basic, very generic, like Nick was saying. We're very generic on what we've done so far, we haven’t specialized in too many ways. For customers who want it, we can add more custom ones, but we’ll just go to defaults here. I'm just going to take the basic one
Mike_Parkhill: and so this is a new thing we've added here.
Mike_Parkhill: If you want to have a pretty presentation of your credential you can now build one of those. And again I'm not going to spend a lot of time in here. This is a basic wysiwyg editor that allows you to drag around logos and text and that kind of stuff, as you would expect just to [_____] out of it. So let's continue with our design.
Mike_Parkhill: And here is where you enter the details so you can import - if you have a CSV or a spreadsheet, you can import it that way so if you want to do a bulk issuance you can do that pretty easily. I don't so I'm just gonna do a very quick one here. And here in the subject ID, it can be a DID, it can be an email can be just some employee ID sort of up to the issuer whatever they want the subject ID to be so I'm just going to say [_____]...
Mike_Parkhill: details. As you help with the credentials you can choose to expire them.
Mike_Parkhill: So we can do that. You can change the issuance date, so if you want to backdate when it was issued, maybe didn't get around to issuing the credential for a couple days after they pass whatever tester they need to do, you can do that.
Mike_Parkhill: And then there's options that these are apply to everybody that you're issuing to, so if you had multiple people they'd all get these ones. So the persisting the credentials, this is something we we struggled with a little bit when we were first working on this because the idea of persistent credential kind of a runs again some of the ethos of the decentralized world and because we are - so if you persist it, it's on one of our centralized databases. Now we do let you set the password so we can never decrypt it, we can never look at it ourselves but
Mike_Parkhill: the main reason or one thing that drove us to this was the idea of we want to make it scannable with a QR code for sharing easily
Mike_Parkhill: and that kind of stuff. And we didn't have the wallet at the time and not everyone is going to have a wallet, so how do you do that in like a PDF, and we found the JSON was too large to jam it into a QR code. It would fit for very very small credential [_____] or any kind of details or a logo or something that you include, it wouldn't fit. So we end up doing this persist thing. It’s optional. Again if privacy matters to you and you want to go purely decentralized, you don't have to do it and it’s sort of highly recommended for that.
Mike_Parkhill: Now that option is here.
Mike_Parkhill: You can generate a PDF for it which will give you a sort of prettier view of the thing that goes along with the JSON-LD that you get as well. You can make it revocable and you have the option of anchoring it on the blockchain. So all these things can [_____], and if you anchor it on the blockchain, it’s just a hash it's not the full details, right. Ihink it's still hidden away
Mike_Parkhill: and that's it.
Mike_Parkhill: If I had more than one issuer profile because there are some scenarios where people might have more than one, you can totally switch which one you are, but we’ll use the one I've got. We issue the credential
Mike_Parkhill: Sometimes it takes a moment or two.
Mike_Parkhill: There we go. Now I can download it so [_____] zip file where you can view the credential, so here it is in our view here.
Mike_Parkhill: And if I click on this link,
Mike_Parkhill: again it’s password protected.
Mike_Parkhill: There it is. Very basic very simple we didn't choose a fancy design so it's a very ugly design but there you go that is basically your credentials issued that QR code could be scanned and entered into the wallet. We won’tl go through that right now but it's pretty basic again scan it type your password then input in your credentials. You can see multiple credentials in here in your wallet that kind of thing.
Mike_Parkhill: And that's really about it.
Mike_Parkhill: If you want me to go into details about specifics about technology like our Dock searches all JavaScript back-end using Next.js as a framework.
Mike_Parkhill: The wallet is react native and our SDK is react native [_____] SDK. And yeah and if anyone has any questions on that, or Nick you want to jump back in, but that was sort of all I had to show.
Harrison_Tang: So thank you Mike for the demo I have one quick question. So when you’re signing in with the Web3 ID, does it require the Dock app to be installed to use that, and if it does, like you know a lot of users actually don't want to download another app so how do we kind of overcome that obstacle?
Mike_Parkhill: So as of today yes you do need to use our app but that is where the react native SDK comes in. That if another like former clients or anybody else wanted to use it they could as they can put that functionality into their own app and build it at that way so it could get integrated into any number of apps to be able to support it. And that's one of the reasons we're building the react native SDK, so we can share
Mike_Parkhill: that with other people, not just us.
Mike_Parkhill: Like we don't want to have
Mike_Parkhill: that vendor lock-in specifically to us for this. We want more people to use it. We're not charging for Web3 ID. You can also stand up your own back-end for it so again like that open source project for it, you can go stand it up wherever you want so again that could give you the freedom to modify it yourself or do it [_____] with it as well.
Harrison_Tang: And then I also have another question in regards to the blockchain part, like where does the blockchain play into the entire ecosystem. Are you using the blockchain just to anchor the DIDs or like are you doing something else? Like for example earlier you mentioned about you can put in some hash of the verifiable credentials in the blockchain so I'm just wondering where does the Dock blockchain kind of play into this thing?
Mike_Parkhill: Yeah so as you noted if you anchor a credential it is stored to the blockchain. If you don't anchor to the blockchain then the blockchain doesn't know about your credential as the only sort of, other than the DID, that’s the only time it gets tied. And our DID Docks get written to the blockchain as well so it's really those are the two primary use cases for our blockchain - it’s the anchored VCs and the DIDs themselves.
Harrison_Tang: Got it and then a quick follow-up question, I saw that Dock also has a token and I'm wondering how does the kind of token and transactions play into the entire thing, because can someone actually transact DIDs and VC hashes, or how does the transaction work?
Mike_Parkhill: So yeah so with the Dock Certs and with our rest API we kind of hid that away, We manage the tokens for you.
Mike_Parkhill: And we also manage the keys, which again, was a debate we had with ourselves again it's more controlled in the centralized body than you probably want in the real world but then what we were coming across was a lot of our customers again didn't want to have to deal with managing tokens, didn’t want to deal with management keys, so sort of a pragmatic solution to go with what we have. But that being said we do have above the blockchain we have a JavaScript SDK that can do all the blockchain transactions through it and when you're doing that you can
Mike_Parkhill: provide your own keys you provide your own tokens and that sort of detail. So you can still
Mike_Parkhill: build your own solution on top of the Dock blockchain using that SDK without involving us and then you have full control over the tokens and things so you don't see the tokens here and what I've done here if I was to generate my own DID in the wallet app.
Mike_Parkhill: Where’d it go? There we go.
Mike_Parkhill: Then if I choose to create a Dock DID. Right now, we only support DID key and DID Dock, then I'd have to be able to specify some tokens to pay for it which I don't have any in this test account at the moment so I can't go through with this, but that's the only place right now in the wallet as far as DIDs and VCs go, that you would see anything about the tokens, although you can do your own transaction sending/receiving/buying, that kind of stuff, through the app as well. But yeah for most of the Dock stuff and the API stuff you don't actually deal with tokens directly.
Harrison_Tang: Thank you Nick and Mike.
Harrison_Tang: If anyone has any questions please type in q+.
Mike_Parkhill: I think I saw that Keith had a question go by I'm just trying to find it.
Mike_Parkhill: How does the Dock team view interoperability moving forward? So yeah that's a good question we certainly, by sticking with standards, we think, trying to maintain and durability that way. We think it's probably it’s obviously a really good thing if you get wallets to be able to import and export each other's credentials, each other's DIDs, that kind of thing we are very open to the idea obviously right now we've been focused on our own but I think in the future you'll see us start
Mike_Parkhill: bringing other groups and other
Mike_Parkhill: implementations into our wallet, into credentials as well. So I think it's ongoing and I think it just needs everyone kind of working together on it. I don't know, Nick, if you want to say anything more on interoperability, or?
<phil_l_(p1)> Are you participating in the JFF/VC-EDU plugfest2?
<dmitri_zagidulin> @phil - you should hop on the q to ask that :)
Mike_Parkhill: And just one other thing to throw in there is the other standards we’re kind of looking at for sorting interoperability and communication are sort of the DIDComm and the Ares standards we've been playing around with them looking at them because again as you get to [_____] build you have to have you communicate it's good to have a JSON object that represents your VC or whatever we still have to be a way of sharing it so we've been looking at those [_____] of standards and again we want to stay a standards based on how we do that kind of stuff and not go reinventing
Mike_Parkhill: the wheel. There has been a lot of people spend a lot of good time coming up with these ideas and these standards and it's
Mike_Parkhill: in our best interest to make use of them.
Harrison_Tang: So we have three people in the queue. Andrew, do you want to hop on and ask your question?
Andrew_Whitehead: Sure, thanks. I was just curious about the PDF version of the credential. I think you had options to verify the credential using the QR code and maybe to import it into a wallet
Andrew_Whitehead: directly from a QR code. I wasn't sure if that only applies to anchored credentials or -
Mike_Parkhill: It only applies to persisted credentials to do it with a QR code because
Mike_Parkhill: we need to know where to get it from. As I was mentioning the QR code itself unless you make it a massive QR code is too small to house all the data you need for most credentials. So yeah you needed to be persisted in order for that scanning for verification or import to work.
Harrison_Tang: Phil, do you have a question?
Harrison_Tang: Yes we can hear you. Thanks.
Phil_L_(P1): Hello? Okay, just took a second to connect. Two questions actually if I may. The first is you mentioned your interest in interoperability and such and I just wanted to know if you were planning in participating in the upcoming JFF VC EDU interoperability Plugfest, Plugfest 2, as its referred to.
Mike_Parkhill: Pretty sure we did, but no I don't think this one's - hasn't really come across our discussions unfortunately.
Phil_L_(P1): I'm sure there are several people on the call that’d be happy to to send you the contact information about it and such. I believe it's in November and it will be a true interoperability test where issuance of a credential will be expected to go into two different wallets and then rendered properly from those wallets. So that was the first question. The second question, you mentioned
Phil_L_(P1): your back-end network but I don't believe you mentioned
Phil_L_(P1): what it is you're using for that purpose?
Mike_Parkhill: So our backend network is our own we built our own so it's just the Dock Network and is built using Substrate which is the same framework Polkadot uses.
Phil_L_(P1): Yep thank - that's what I was - that's a good answer and thank you very much.
Phil_L_(P1): I'll look for it now and put it in the chat.
<kerri_lemoie> Thanks, @Colin. Unfortunately plugfest registration is closed but please stay in the loop on the vc-edu email list.
Harrison_Tang: Thanks. Rishi, you mind coming off mute. I think you have a question? You have the floor.
Harrison_Tang: Yes we can hear you, yes.
Rishi: Can you hear me? Hey thank you so much and thanks so much Nick and Mike for the time, it's helpful. So I’m new in the space I've been here for about three months and I don't have a especially deep technology background and so I've been going through the sort of education problems and I could resonate with when you were saying you take that to different segments of customers and you’re agnostic right now, so I just wanted to understand from that point of view,
Rishi: when you have these conversations,
Rishi: at what level do you need to have educational conversations that starting from like the technology right up to like the application, and in the places where you you know seen in roads, what has been you know easier, what is something that's already been established as common ground?
Rishi: In terms of the conversations been you've been like looking at different use cases and different partners for this the education could be at very different levels, right? You could have to start with the pipe down to the technology right up to like the application and how it would work in terms of the user journey, so does this involve like multiple levels of conversations across each of these topics?
<phil_l_(p1)> I can't hear rishi's side of the conversation - other's might be having that problem, as well...
<alexander_mühle> yes
Rishi: Yeah, that was helpful. Thank you so much.
<orie> Great presentation and answers
Harrison_Tang: By the way I really love your answer there Nick and I'm just curious other than the education use cases and we know that that is a big use case because we do have a task force with VC Edu, so other than the education use case and reusable KYC - know your customer - use cases like what other markets and use cases that you see has some kind of product
Harrison_Tang: market fit or
Harrison_Tang: market tractions for SSI related technologies?
<orie> Related to food supply chain use case, checkout https://w3c-ccg.github.io/traceability-vocab/#food-and-agriculture
<orie> You can use the credential templates there to meet FSMA reqs :)
<mike_parkhill> thanks for the link
Harrison_Tang: Thanks. Any other questions?
Harrison_Tang: I'll ask one more last question from me. So earlier we do know that you know VCs and SSIs is a multi-sided platform problem right there's the issuers, there's a holder, there is verifiers and earlier you mentioned in the education use case, issuers are the one who pay for the for issuing VCs. And in the market, I'm very familiar with such as identity verification.
Harrison_Tang: KYC, the verifiers will pay.
Harrison_Tang: My question is how do we - what are the biggest challenges in actually creating and connecting this multi-sided platform and how can we overcome these challenges?
Mike_Parkhill: No I think I was going to suggest the that's where the integration the Plugfest, everything comes in a big way, because you do want to get out of the whole silos of five thousand apps on everybody's phone one for each different use case because that's not going to fly so I think getting it getting those integration points and getting you know standardized wraps whether it's you know the university has their own app or maybe we have to go play ball with the Google Wallet or something like that who knows but there's going to be,
Mike_Parkhill: there’s going to have to be a bit of a consolidation into fewer apps that can support multiple.
Mike_Parkhill: VCs and multiple vendors, I think.
Harrison_Tang: Thank you. And Phil, I see you have a question, please -
Phil_L_(P1): Yes thank you very much I think I heard you say earlier you that you do have a wallet is that correct?
Mike_Parkhill: Yeah that's what I'm showing here on the screen the black right part.
Phil_L_(P1): Right okay so the question is does your wallet support the create issuer or the holders creation of a verifiable presentation to be sent to a third party?
Mike_Parkhill: It does I don't have that demo setup for you. It does yeah if you scan a QR code from a presenter and that will take you through.
Phil_L_(P1): Using VC API?
Mike_Parkhill: No
Phil_L_(P1): The transfer of the port protocol transport.
Mike_Parkhill: No it's not
Phil_L_(P1): What are you doing?
<orie> Does it up OIDC4VP ?
<orie> or DIDComm VP flows?
Mike_Parkhill: We're bundling presentation and I think it's the DIDComm definition of a presentation and then we're sending that to an API.
Phil_L_(P1): Okay so using the DIDComm family. Thank you.
<orie> He answered.
Mike_Parkhill: Oh I think it was answered by saying DIDComm. Yep.
Harrison_Tang: Well any last questions?
<orie> If you want to pass trace interop tests
<colin,_lef> This has been a great overview thank you!
Harrison_Tang: Alright thank you, Mike thank you Nick. I just want to thank you guys again for taking the time to present here and answering some tough questions. Nick, like in particular like my last question is actually a very very hard question and I don't have a great answer myself so thank you for taking the time to answer those questions. Actually we do have, oh never mind, Keith do you have any questions? Last questions?
<orie> ^ let me know if I can help.
<nick> Yes pls Orie
Harrison_Tang: Yeah no problem. Yeah so I just want to thank you guys again for taking the time. Lastly any introductions, reintroductions, announcements or reminders that people want to talk about and didn't have the chance to in the beginning?
Harrison_Tang: Alright, thanks a lot have a good one.
Harrison_Tang: Thank you bye.