Lessons Learned from Projects Using Verifiable Credentials in the Education Industry

Thank you for coming to my session and I have some trouble to connecting question because I invited Professor Suzuki from KE University but he didn't join yet because some travel to join. So anyway, let's get started. Thank you for joining again and I'm now here Fuji I workforce system integrator in Japan called Techno Solutions. And also I'm taking a part of some of standard body such asland foundation and as well foundation Japan. Today I would like to share my experience in verifiable credential related project in educational spaces in Japan. So let's get started. Yes.

Today I'll show you two projects in Japan about in the educational space like university or some institute related to education. The first one is the K university, which is focusing on microcredential like diploma or student card. And the second one is a national institute of informatics. We call it N I I, which is focusing on microcredential such as learning credentials. This is our first one about Kyo University's project.

Like other universities of course Kyo University have existing identity provider to authenticate students and we implemented, we see issue services on the top of the existing identity provider to issue in the left corner. This one. And also we implemented works for students at this project we used Microsoft Authenticator and brother based words to store PCs. In this part for verifiers we had several use cases.

We consider for example, making Loom reservations or log into the cloud based services using bare fiber credentials and I will show some short demo to log into the guru services using verifiable credential. This demo is especially for alumni because K University do not want to manage password or IDs for ize.

Yeah, we implemented some additional capability on existing ENT provider enabled to log in using BCS and users scan the QR code and present the verify credential to log to the Gmail services. Yeah, like that. And my original plan is inviting Professor Suzuki at this moment and get some comment from him but unfortunately he's not here. So go and next case and second case is at the the AI and they're focusing on micro credential and they already have a learning management system using model.

Probably some of you know that the model has capability to issue open batches for learning credentials and the requirement to us is to make easier to use the learning credential to in in other systems. So we implemented the gateway service between model and application, which have a capability to convert bare fiber cred, open batches to bare fiber credentials.

Also I prepare some short movie but demo This is issues gateway users upload the open patch into the site and the gateway converted to the, and the users should receive the verifi fiber credential from the gateway and also users can present verifiable credential. This is including open batch itself in the pcbc so that gateway services verifies BC as well as open batch and this time they want to have capability to grant some additional laws if users have specific open batch credential.

So this is short demo even so from now until now, I chose two use cases from K and others AI and this is my opinion, but I think the largest barrier of this architecture using bare fiber credential is solving call to home problem. What I mean is when you use the federated to architecture as today users have to be related to and identity provider every time they want to use applications. This means we have to have well maintained identity providers because if the identity provider has any problem, users cannot use relying party anymore.

And also reality party have to be configured before they start using identity providers. This might bring scalability problem in some cases I think. And also yeah, on the other hand by using verifiable credential architecture, of course the issue must be well managed but we can lead this its availability requirement because users is not required to federate it every time they accessing to the applications and also the applications are not regret to be pre-configured to be connected to the identity providers and this makes system more flexible and scalable.

But I think there's still more discussing items. I do not have enough time to discuss all of the items so I like to talk about issue den fires.

Yeah, this topics about just identifiers is quite close relationship with decentralized or centralized, I have that everyone likes to use block based DDS combined with verifiable credential right now. But I don't think that all of the use cases are suitable for use the based blockchain based.

The IDs, especially the student card use case requires a certain authority and it does not require blockchain based identifier. For the issuers I think, oh Mr. Professor Suzuki is coming.

So yes, could you please introduce yourself? Insured. Hi.

Hi, I'm Suzuki project Professor K University. I'm a distributed system architect focusing on data security. Thank you. Thank you very much. So actually I already introduced the K o use case and do you have any comments about chaos use case?

It was interesting that of course integrating the newer system into the existing system is a challenge in various way because of course the the IT team need to be coordinated with the, for example with us to work on it and of course the barriers API adjustment to LEO deployment but of course we did sort of the park so that part is not a problem but in, in a real deployment we needed, there are of course there are tons of challenges. That's it. Thank you. Thank you very much here.

So maybe we only have nine minutes so let's get continue to, so this table shows you some of situation the weather, it's regrettable a blockchain based d i D or not. For the first one, if you use a blockchain based d i D for issuers identifier, it is required to have some mechanism to prove that G D I D is actually identify the university itself. Today usually we use well D I D configuration spec to link the D I D to the DNS domain of the university. But you can use the web vessel D I D or J W K U I as identifier. It's much simpler.

I think for the second one it's quite similar to the first one, but from the verifiers perspective they are required to get the public key of the issuer to verify the presented verifi five credentials and the verifiers use the ideal to get the power key using the issue as D I D. But if the issuers uses general case u i, the verifier can directly get the public key from there it's much simpler. And the third one, someone often says that the body proposition of the blockchain based the ID is even if the issue Schutze down verifier can continue to verify verifi credential.

But please conscious that in case of university there's no use case to verify students card from university already shut down And usually some other entity takes over the law of the university even if the university is shut down. So we can consider these things and next page. Yeah and we have to use proper technology for proper use cases. So as I show in the table, I think we can define two, use two dimensions. First one is a weather verifier require issue must be or not. And second one is whether verifiers request online credential, offline credential like this one.

So for example for user authentication like this one party always requires issuer must be authoritative of course and requires credential or tokens just after issues. So I think for user authentication it's better to you consider using openly connect but consider other use case such as student credential or vaccination credential. Usually their payers do require certain authorities as well as authentication but, but they do not require online transactional credential at tokens. So we can use credential with a certain issue for this, for that this use cases.

And on the other hand there's as a case like reputation based credential using usage or so to them it might be acceptable to use blockchain based the ID as assurance issuer credential. So this is one, I'll give you a one example of using J case U I as identifier in BE credential. Now this is a vaccination certificate in Japan. They uses a BE credential as a certificate but they do not use the ID as issuers identifier. Could you please explain a bit about this size? Yes.

Part of the change is consists of the X X five nine certificate and it was look like the, the LUCI certificate is embedded into the boxing certificate application which is provided by the digital, you know, agency and also barriers application, which also able to verify Japanese certificate is it has the certificate into their application. So without using that it is impossible to to to to, to check the chain of trust. But in basically it is possible to use, just rely on the, on the, on this version URL based J W K S link and it is much simpler to use, use that. I think that's it.

Thank you very much. So there's no need to use DDS for such use cases? I think so. We have a few minutes to left. So lastly what I think right now we have to consider use light technologies in light prices. Of course there are several broken items. For example, some university office says that there are a few. Right now I think it's kind of a, a chicken egg problem, but we have to meet the brokers one by one, one step by step. It's a very important thing for us. But I think the most, most important thing is think simple as I explained.

Start considering from the small step like vessels the fire requires a certain authority or not. And of course it's a quite important thing. Simple and just implement using current technology like JW case because not of all use cases requires blockchain based or decentralized. That's from me. Could you please add some comments from you?

Yes, there a few things. Two things I want to point up and the first thing is, is the issuers as, and the requirement for the issuers for, I mean requirement for the issuers are different for the digital identity and certificate, I think. And these are have the different, you know, policy or requirements.

So, so for the certificate we probably do not need to be decentralized because it is, you know, issued by some authority. So it is, we can, we need to rely on that to verify it.

So it is, there is no need to to use a DD in terms of that. So we need to to to carefully distinguish these two use cases. And there are many people who is mixing these two use cases.

I think, and it is a little bit different from the, the, the context now here as I had mentioned. But I wanted to tell that the MultiLing support in the credential is very important without support for the multilinguals credential. It is difficult to cross the border since each of the, the country has a different possibly different data model. So we need to adjust a data model of course.

But beyond that, for example, the vaccine certificate has a problem in in Japan that some of the people who is, is come to long in Japanese Japan from the, for example, the Hawaii island who he has a certificate with his name in Japanese CATA and not in string because due to the fact that there is no way to express multilingual text in L seven, which is used in the certificate certificate standard. So I think that we need to think about how the, we can implement the Martin lingo support in various certificate, especially for the education affairs. That is from me. Thank you.

Yeah, thank very much. We just learned out about our time, so thank you very much for coming. That's it.