- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Wed, 21 Aug 2024 13:34:17 +0000
- To: public-credentials@w3.org
Thanks to Our Robot Overlords and Our Robot Overlords for scribing this week! The transcript for the call is now available here: https://w3c-ccg.github.io/meetings/2024-08-20/ Full text of the discussion follows for W3C archival purposes. Audio of the meeting is available at the following location: https://w3c-ccg.github.io/meetings/2024-08-20/audio.ogg A video recording is also available at: https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2024-08-20.mp4 ---------------------------------------------------------------- W3C CCG Weekly Teleconference Transcript for 2024-08-20 Agenda: https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Aug&period_year=2024&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date Organizer: Harrison Tang, Kimberly Linson, Will Abramson Scribe: Our Robot Overlords and Our Robot Overlords Present: Harrison Tang, Rashmi Siravara, MG (GoPlausible), Gregory Natran, Alex Tweeddale, Will Abramson, Phil Long, Sam Smith, Joe Andrieu, TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Simone Ravaoli, Geun-Hyung, Mike Xu, Jennie M, Leo, Anil John, Przemek Praszczalek, Kaliya Young, Hiroyuki Sano, julien fraichot, Dmitri Zagidulin, Tim Bloomfield, Jeff O - HumanOS, Lucy Yang, Ankur Banerjee, David I. Lehn, Stephan Baur Our Robot Overlords are scribing. Harrison_Tang: Welcome welcome everyone for uh for attending this week so that we meeting uh today we're very pleased to have Alex and the Encore from check uh to provide an update on did link resources 1 of our w3c ccg work items but before we start I just want to quickly run through the administrative uh items. Harrison_Tang: First of all just a quick reminder on the code of ethics and professional conduct I just want to make sure we have constructed uh constructive and respectful conversations here. Harrison_Tang: Uh next a quick note on the intellectual property um anyone can participate in these calls however all substantive contributions to any ccg work items must be member of the ccg with full IPR agreement signed uh if you have any questions in regards to uh that or the or having a w3c account uh please uh contact any of the cultures. Harrison_Tang: Um these meetings are being automatically recorded and the transcribed uh so we use GT chat to cue the speakers during the call so type in the queue plus to add yourself to the queue or cue minus to remove uh you can type in Q question mark uh to see who is in the queue. Harrison_Tang: we will. Harrison_Tang: Published uh meeting minutes audio and video recordings uh in the next uh 24 to 48 hours. Harrison_Tang: All right I think I just want to take a quick moment for the introductions and introductions so if you're new to the community what you haven't been active and want to re-engage uh please feel free to just unmute you don't have to type in Q Plus or anything. Harrison_Tang: Announcements and reminders any announcements or reminders. Harrison_Tang: A quick preview of what's coming so today we're we're going to talk about the did link resources and uh next week uh we'll have Gregory uh and Joanie uh from the IAC from Canada to talk about paying Canadian trust framework. Harrison_Tang: and then. Harrison_Tang: Greg to uh do a follow-up on the anonymous holder binding a great session that we had. Harrison_Tang: Uh about uh 2 months ago. Harrison_Tang: And then I'll try to I think there's a great email thread around the proof of personhood so I'll try to schedule that conversation uh in the next 2 months uh as well as the proof of uh Humanity uh 1 of the projects in dif. Harrison_Tang: By any other announcements and. Harrison_Tang: And or reminders. Harrison_Tang: Write 1 more announcement and uh is that on september 24th. Harrison_Tang: There's a w3c pack uh week and a lot of people won't be there uh here today so on that day sorry so we'll cancel the ccg meeting on september 24th and then the October 29th is the internet identity Workshop IBEW so we'll cancel that session as well on the October 29th. Harrison_Tang: All right Clea. Kaliya Young: Hi uh hear about we have Internet identity Workshop coming up I think early bird pricing is still around for another we're so. Kaliya Young: Um the damn conference Africa is the same week as TPAC if you know folks in the region please let them know about it it looks like it's going to be fun apparently our local hosts have been on television and everything uh sharing about it coming to tan. Kaliya Young: So that's all I have thanks. Harrison_Tang: Any other announcements or reminders. Kaliya Young: https://internetidentityworkshop.com/ Harrison_Tang: Right next uh work items uh a quick update on the work items so Isaiah uh who's actually leaving the verifiable issuers and verifiers uh wasn't able to attend last week but uh he actually sent out an update so they're working on a data model for issuers list and claim to publish the first version by the end of October so I'll try to work with him and uh have him come to speak about that version the first version of verifiable issuers and verifiers sometime in November or December. Harrison_Tang: Other uh work item updates. https://docs.google.com/presentation/d/1usTxVbq1LmtvVIP1ixK0FB9R4S1Fhq4kgpA0W25W4HQ/edit#slide=id.g2f0a12c6cca_3_110 Harrison_Tang: Uh and by the way I updated the. Harrison_Tang: The work guidance deck uh with that update uh in the link that I just shared. Harrison_Tang: Cool so uh let's get to the main agenda so again we're very very happy to have Alex and Anker here to uh talk about the did link resources so Alex the floor is yours. Alex_Tweeddale: Great I think it's just me at the moment um anchors anchor will jump in in about 5 minutes or so um but yeah let's let's kick off uh I'll put this into slideshow mode as well um so I'll give a bit of context on what did linked resources are I think that some people on the call will have a broad understanding of what they can do others will be completely new to the space so I think we'll start from Basics and then we can get into some of the complexity later on um for a bit of context we've we've been working on this did linked resource standard for about 2 years now. Alex_Tweeddale: Last year we started writing the draft spec. Alex_Tweeddale: W3c and that's got to a sort of v0.1 state now where we'd love to have some contributions but I'll I'll get into that later in the in the presentation so I'm going to run through what did looked resources are uh what applications there are at the moment in in sort of in yeah in the real world um how what problems did Lincoln resources solve um and their applications. Alex_Tweeddale: So uh I guess the first question that I want to ask as a sort of rhetorical question is why are resources needed in digital identity and this kind of leads on to what resources are in this context. Alex_Tweeddale: And sort of in a nutshell a resource can be any structured file um stored on Ledger uh or off Ledger this actually I should certainly update that to say off Ledger as well within a specific syntax um so in decentralized identity specifically we often use things like schemas status lists trust Registries as sort of files that we associate with. Alex_Tweeddale: Decentralized identifiers and verifiable credentials but the actual ways that these files are stored is often quite varied so for example schemas are a really good example of a resource uh they're used to describe the attributes within a verifiable credential in a machine readable format and you know prominent examples of where schemas are stored are schema.org uh which is probably the most common 1 uh then there's other sort of Alternatives such as you know the hyperledger Indy Community which uses on Ledger schemas. Alex_Tweeddale: Um and schemas are naturally used in identity documents and VCS uh and it they become increasingly important um when we're talking about verifying a credential because you need to be able to match that the actual credential you're being presented uh sort of conforms to the schema that is referenced in the credential. Alex_Tweeddale: Um so you know in an example uh so 1 example is you know here on the left hand side we have a schema shoot or a driver's license uh issued in 2012 and on the right hand side we have 1 in 2015 and what you can see is some of the attributes within the 1 in 2015 of being updated um but because both of these drivers licenses are still you know valid uh you know there's an overlap in terms of when they are both valid uh verifying applications will need to be able to discern uh or be able to verify both of these schemas at the same time so we need a way to be able to update these types of resources without 1 being sort of deprecated or 1 sort of uh resulting in an error. Alex_Tweeddale: Um so here you can see just a like a quick a quick glance that some of these attributes um on the right have been updated so this 1 includes height weight and eyes whereas the 1 on the left does not include white hypnosis um and we need to make sure that the 1 on issued in 2015 doesn't invalidate the 1 issued in 2012 um so both of these should still be higher level of assurance schemas. Alex_Tweeddale: And this is a problem for apps in the real world specifically with regards to verifying credentials um and we've all encountered you know computer says no. Alex_Tweeddale: Is in this context. Alex_Tweeddale: If we don't learn from sort of the mistakes of the past where you know we we've run into these issues then I think we're we're falling into a bit of trap with in this new sort of identity paradigm. Alex_Tweeddale: Similarly uh you know I think with regards to resources like schemas and Status lists. Alex_Tweeddale: Points of failure is also a really big potential issue in the space I think we've seen a lot of convergence around the methods like did web did did tvw which I'll get on to it a bit later in the presentation um but you know we've seen large Global outages recently with regards to Microsoft we've seen previous ones with Facebook and I think if we're going to build an identity system around um these types of resources we should try and mitigate as much as possible uh single points of failure. Alex_Tweeddale: Um thirdly uh a lot of resources that are currently stored um are on kind of centralized Cloud infrastructure so this graph on the left here shows that you know most of what is stored on servers around the world is actually narrowly around 3 or 4 Cloud infrastructure providers um which makes Global outages or systemic outages um a lot more common uh if say a big provider like AWS goes down it could take down a lot of potential system. Alex_Tweeddale: Um and then finally there's this concept of Link rot uh which we talked about a lot which is and I if I go back to the example of the schema analogy which I showed previously we need to make sure that you know if we have a driver's license which potentially has a lifespan of you know 30 40 years we need to make sure that a schema that was issued 30 40 years ago. Alex_Tweeddale: That the link for that schema doesn't break you know. Alex_Tweeddale: Lot a long way down the track um this diagram on the left here shows that um I can't remember the date I think it was since the late 90s 47.7% of all links on the internet have now died um and if we don't look at that as a issue when we're building these sort of. Alex_Tweeddale: Identity credentials with longevity then um we'll run into similar sort of. Alex_Tweeddale: Issues with resolving to these resources going forward. Alex_Tweeddale: Another issue I think that I touched on slightly earlier is. Alex_Tweeddale: We are converging around some I would say more centralized methods I don't have a problem with this at all but I think we should be mindful of some of the potential implications of this um so with did web specifically you know I think we all most many of us on the call are aware of the challenges of it um but it is also a very simplistic and easy to use div method but yes if if a hosting provider is hacked or goes down um that could potentially affect the system and did TDW you know go some of the way to solve those problems but you know if you can't access the did log file and you know the historic sort of records of the did itself then you might run into similar challenges as well um but I don't want to go into detail on the TDW or did web in this call that's not the point of it um so yeah resources did linked resources uh just to summarize are. Alex_Tweeddale: Are a way of mitigating some of the risks of this sort of downtime on these critical components of the uh credential and identity ecosystems that we are currently all sort of rapidly uh getting ourselves involved in um. Alex_Tweeddale: Actually going to skip this do this section after. Alex_Tweeddale: I should know. Alex_Tweeddale: I I'll go I'll go straight into it now. Alex_Tweeddale: So how are resources being used in the world so I touched on some uh examples of where resources could be used so schemas status list trust Registries um since we actually launched the specification or started writing the specification 2 years ago we've been working on a couple of initiatives and you know we've had a lot of community members working on initiatives for resources so recently uh diff and Dan ubtech um have well Daniel Tech has been commissioned to build did linked resources into both the universal registar and the universal resolver. Alex_Tweeddale: And what that actually means is that um anyone who is using some of these common interfaces to create decentralized identifiers or did should equally be able to create did linked resources um and resolve to did linked resources. Alex_Tweeddale: This is not this is in zero way linked to checks um this is something that we worked on but the whole point of doing this in w3c and with diff is to make sure that any did method is able to use the linked resources and you know any verifier application should be able to resolve different resources not withstanding the actual Ledger or did method being used under the hood um and we want to create a sort of common syntax for these types of resources uh which yeah can be used with did web could be used with did epsi did indeed did check whatever um and we hope that some of this work on the delivery sources as well will be considered as part of the new did traits work. Alex_Tweeddale: So yeah 0.1 is where working to get this into the universal resolve and registrar. Alex_Tweeddale: Do is there's been a lot of really interesting work on did linked resources for trust Registries lately we've been working with the guys uh epsi and we've been working at the guys at fraunhofer Institute to create um. Alex_Tweeddale: Very much a. Alex_Tweeddale: End-to-end Journey for writing sort of trust Registries and verifying trust registry is in a very modular way. Alex_Tweeddale: Um where we use trust registry where we use the linked resources in the trust registry piece is in this uh this purple blob that's on the screen here so um each trust registry entry or each uh so so actually I'll contextualize this a little bit so checked um what we've been doing at checked is working with the EPC model of trust Registries and what that means is a did can a credit another dip with a specific set of permissions so uh there could be a root of trust governance Authority did which says Okay I want to accredit these you know. Alex_Tweeddale: Accreditation organizations to issue uh either more accreditations or to issue credentials um and those accreditations themselves are stored as digital resources. Alex_Tweeddale: Basically the parents did or the root of trust did issues their accreditations as did linked resources to the accreditors and then they can issue accreditations to issuers and those are stored as particular resources as well. Alex_Tweeddale: Go into more detail further in the presentation on how this actually works to build a bit of a to paint a bit of a clearer picture on what I mean when I say uh linked linked resources to these DS but in essence this is 1 of the use cases that we're looking at and it's really cool because what we can actually do is have trusted accreditations um which uh secure and use the same key material that are in the. Alex_Tweeddale: dids that. Alex_Tweeddale: That they're being linked to to write trust Registries which is excellent and the guys at the fraunhofer Institute have built this trust check train trust validator that's a bit of a mouthful where basically um they're building a modular way to resolve to different trust registry implementation so they're looking at doing uh x509 and more centralized trust registry models as well as open ID Federation and also did base trust registry resolution so they kind of want to build this is almost like the universal resolver for trust Registries which I think is really interesting piece of work. Alex_Tweeddale: This as well but um we we made an EPC Improvement proposal. Alex_Tweeddale: So they are uh now looking to support the linked resources for their schemas status lists and Trust registry is on the Epi Ledger. Alex_Tweeddale: So for example they have this concept of trust chains at Epsy whereby as I kind of alluded to earlier an organization can accredit another organization below it with a set of permissions um and if you write those accreditations as did linked resources then it becomes much easier to resolve to that accreditation in a standardized and sort of um clearly defined data model. Alex_Tweeddale: uh so. Alex_Tweeddale: On the right. Alex_Tweeddale: Sort of what we intend to sort of a a longer time goal that we intend to reach with EPC or or perhaps what becomes and European down the line whereby we can have dids and did linked trust Registries or did link status lists written on EPC and then other trust infrastructure such as ourselves at checked and then we use the universal registar and resolver to be able to like. Alex_Tweeddale: With with complete interoperability take those inputs and for verify our applications to be able to verify those trusts Registries equally um which I think would be a really really nice sort of uh demo to do with them at EPC. Alex_Tweeddale: Another use that we've we've seen pop up in the last couple of years is um did link resources for an on credit so. Alex_Tweeddale: Rats have been tied at the hip to hyperledger Indy and that's obviously caused a lot of friction in the space it's caused a lot of challenges with people building in the animal creds World um and 1 of the things we were able to do with lint resources was actually um enable uh the Anon Crest community to decouple uh the Alan creds credential BH format from hyperledger Indie now I'm not advocating that we all moved around on credits in any capacity I actually love you know the all converging around St John and the other EU sort of credential formats but it's a really cool uh. Alex_Tweeddale: sort of. Alex_Tweeddale: Were able to replicate a lot of the specific Indie sort of uh schemas credential definitions revocation status lists using this kind of extensible uh did linked resource format. Alex_Tweeddale: And then finally um 1 of the things that we've been working on on checked is supporting status lists as did linked resources so um we currently support Ledger based uh status list 21 bit string status list token status lists. Alex_Tweeddale: Essentially it's any file um can be stored as a linked resource and it it appears in this common syntax which I'll go into a bit more detail on um a bit further in the presentation but what's really cool is resolvers can. Alex_Tweeddale: Essentially resolved to the status lists using a dig URL um. Alex_Tweeddale: And and fetch the credential status from the from the um service list themselves. Alex_Tweeddale: Um awesome so yeah just quick summary of dids in the wild oh sorry dlrs in the wild which is the acronym for delink resources so um there's W3 3C draft spec and process uh the universal registar and resolver is in progress. Alex_Tweeddale: Democrats has been done which is awesome epsi is in progress status lists have been done and Trust Registries have been done so lots of really really good work in terms of standardizing how these different types of resources are stored and retrieved. Alex_Tweeddale: I'm actually going because I because I think it's quite important to explain like how these resources work. Alex_Tweeddale: I think. Alex_Tweeddale: Probably uh a really good next sort of step to sort of explain just checking in the background of an because joined as well uh yes I can see him on the call uh hello anchor. Alex_Tweeddale: Awesome um so just to give a bit of context of linked resources and how they work it all starts with a dit so. Alex_Tweeddale: Uh you create your did like you would usually um I'm using a check did as an example but it could be any any dit um and with that did you have a set of uh keys that are used to control the deer to update the deer to authenticate the did Etc. Alex_Tweeddale: So you start. Alex_Tweeddale: With a really basic did. Alex_Tweeddale: And these bits that are highlighted in. Alex_Tweeddale: Orange and in green are important for the next slide so I'll I'll reference I'll show you how these these pieces work in the next slides. Alex_Tweeddale: Unique identifier of the did essentially becomes what we call a collection ID so I like to think of the datas the parent. Alex_Tweeddale: and then the. Alex_Tweeddale: Are basically children within a collection that's associated with the parent did. Alex_Tweeddale: Each of the resources has its own unique resource ID and it can have its own resource name resource type um which sort of is metadata that defines what the resource is. Alex_Tweeddale: And then you can pass an actual file with the transaction um. Alex_Tweeddale: That is your actual resource so this could be a schema this could be a status list Etc um and then the metadata here is essentially giving context um and and identifiers to that resource itself. Alex_Tweeddale: Now importantly when you create the resource you sign the transaction with the same verification method keys that are in your did document so you know all of the. Alex_Tweeddale: You know the benefits of having DS and multiple controllers and multiple and you know keys for different purposes in the in the D document you can use the you can use those same Concepts when you're using digital resources so you could have a. Alex_Tweeddale: Habits so all controllers of the did need to sign the transaction to create digit resource so that this did linked resources now essentially cryptographically. Alex_Tweeddale: Secure because it's being created using the same Keys as the did or at least you can prove that the resource has you know is controlled by the digital is at least you know related to the did. Alex_Tweeddale: And then once once you've created that resource. Alex_Tweeddale: In the did document metadata um we populate essentially resource metadata. Alex_Tweeddale: Or linked resource metadata whereby you can see the resource name you can see the resource type you can see the unique identifier for the resource. Alex_Tweeddale: and just. Alex_Tweeddale: Just as a quick sort of uh kind of like diagram of how this works in completion you have your did you have your keys and then you know the the unique ID of the the did identifies the collection and you can have 1 Resource within the collection or you can have you know multiple resources within the collection and what's nice with the design of did linked resources is you can have versions of resources sequentially ordered and you know fully indexable um and we we've proposed that we do this using the same resource name and resource type so if you create a new resource and you give it the same name and type that will become essentially a new version of the same resource um it will all resources have their own unique identifier but they are grouped into collections of the same resource name and resource type. Alex_Tweeddale: And what's great is once you've created your resources um in the same way that it did is discoverable through did resolution your resources discoverable through did URL uh dereferencing or essentially did resolution as well. Alex_Tweeddale: There is path-based D referencing so you can have slash resources so you have your did then slash resources and then the unique sort of specific resource ID for that resource and that will fetch the actual file. Alex_Tweeddale: You can create. Alex_Tweeddale: Query syntax so you can say I want to query uh this collection and I want to ask for the resource name that is University degree and the resource type which is Json schema and you can add extra queries to this and we've defined all the particular queries within the draft spec so you can say I want to query the resource that a particular version time um so you can say I want to get this particular resource of this name and this type at this particular point in time um which is really really cool because going back to the beginning of the presentation when I was explaining that you need to be able to persist um historical uh resources such as schemas which you know might have a very long lifespan using uh you did URLs like this especially when coupled with Ledger based uh did methods or more persistently stored uh did methods you can actually. Alex_Tweeddale: fetch that. Alex_Tweeddale: And persistence going forward. Alex_Tweeddale: Um and what's neat about resources is. Alex_Tweeddale: The syntax if you use the common syntax it doesn't actually matter where the resources stored so you know obviously checked is a blockchain uh it's 1 way of storing resources and there are benefits of that in terms of immutability and persistence but equally you could store did linked resources uh on a web server attached to a did web did and it's just a common way of referencing things like you know your status lists and your schemas um and your trust registry is related to that did equally you know you could use ipfs you could use things like carry um the the actual places you store them are uh very broad well you know potentially Limitless. Alex_Tweeddale: Um and then before I wrap up as well um I think it's probably just worth touching finally on some of the other applications of resources that we've not seen be used yet but I think could be really really cool um 1 is visual representations of credentials so in the same way that uh you know you have schemas for the essentially the attributes of a credential or the composition of a credential you could also have a resource did linked resource which um. Alex_Tweeddale: you know. Alex_Tweeddale: Actual visual schema of a credential you know you could store OCA bundles as the delivery sources so you know any verifier application had a common way of actually finding the OCA bundle and then presenting the visual credential in uh the format that was intended by the issuer. Alex_Tweeddale: I also. Alex_Tweeddale: Say interesting angle around Supply chains here you know if you have um. Alex_Tweeddale: If you have dids for reach organization along a supply chain then you can associate files with that did for you know particular parts of that supply chain as it goes through whether it's for schemas whether even if it's for things like um storing little bits of information about okay yes this this part of the supply chain has been certified and I can store that as a did linked resource so that I know that that file has been signed uh by the keys of the control of that did so yeah the we're really excited by the standard because we're now seeing a lot of innovation in the space around it and to everyone in the community who I'm speaking to now it would be great to get you all to read the the draft spec and get your comments on it um. Alex_Tweeddale: Obviously I'm going to pause here for questions and I might pass over to Anchor as well um if you've got anything to add to this anchor um probably a good time for you to come in now as well. Harrison_Tang: Well thank you thanks Alex for a great presentation uh dimitry you're in the queue. Dmitri Zagidulin: Um this first of all uh thank you for the presentation I had a quick question what does checked Ledger use on the back end is it hyperledger Basel based. Dmitri Zagidulin: Cosmos thank you. MG_(GoPlausible): Hello everyone it's so here I'm so glad to be with you today I'm mg from go plausible very happy to meet you all online and I have just 1 question I uh mentioned my comments as a uh Curious here as an issue over GitHub but very rapidly I just wanted you if you if possibly uh uh share some light on what are the plans to you know expand a little bit more or extend the uh proposal draft and also if there is uh some possible room for collaborations and uh suggest some new stuff as I mentioned over uh my issue on GitHub and if you guys see fit I can yeah some elaborate on that a little bit more thank you. Harrison_Tang: Sorry onkar I think we lost you for the. <harrison_tang> link to DID Linked Resources Github: MG_(GoPlausible): Thank you so much thank you so much for your time and response. MG_(GoPlausible): Surely and I will make sure to implement as soon as possible to implement the uh uh linked resources right into the implementation of the ID number private credentials on algorithm blockchain as go plausible is the entity who implements these on algor and blockchain thank you so. Harrison_Tang: No your next NICU. Harrison_Tang: Oh sorry I I think I accidentally muted you sorry fill up please. Phil Long: Thank you okay thank you to Philly um most of you don't know me hello for those of you who don't know I'm with gs1 I wanted to listen to this presentation today because it picked interest so thank you to Alex and Anka um uh I'm I'm new to this so I'm I'm struggling to understand the difference between uh deadlink resources service endpoints in a did Doc um which I guess this must be a difference otherwise you wouldn't be doing this and but I'm intrigued at the idea of a root of trust did that then links did the flow beneath that that's very relevant to trust anchors in Supply chains which is what we do with the bank of people um so um we're a federation we have 118 bits of gs1 around the world that issue our identifiers I know you hate issued identifiers but it pays my mortgage sorry um uh so I'm I'm looking at a way that we Global office would give those identifiers to Our member organizations and then they then Cascade them. Phil Long: Down to the. Our Robot Overlords are scribing. Harrison_Tang: Yes sorry we have a little service disruption um I think it's probably because the the the sharing of the document is too big so. Phil Long: So it's it's a subsidiary of just 1 Germany which is you know this is the thing we're we're 119 different legal entities and we're all different and we're all called gs1 it's really annoying I know sorry. Phil Long: Oh my God. Alex_Tweeddale: Yeah just 1 more point on that as well 1 of the things that we've been working on as well is is to say yes gs1 could have like a did which is their route of trust. Alex_Tweeddale: but they could. Alex_Tweeddale: Also store that did or associate it with an x509 certificate or DNS records for gs1 for the root of trust um and then once that root of trust did has been sort of established that has a a higher level of assurance and then you could create the Cascade of regular DS below that all sort of wrapping up back into that higher level of assurance did I think that's a really interesting hybrid model because you have a lot more flexibility when you create dits um you can make them to make specific you can make them you know you can tweak what the permissions are within the accreditations they have a lot more flexibility than you do with just X5 or 9 certificates so I think yeah it's uh it's an interesting approach that we're we're currently building with the guise of Farah Hoffer. Phil Long: So thank you both that's really interesting and definitely something we need to look at and I'm glad I joined the gold today thank you. Dmitri Zagidulin: My question is to sort of follow up on the trust registry angle is I'm wondering why the decision to oh to overload the just the storage spec with also issue a registry section right like there's a number of issuer registry specifications like train like ccgs known issues and verifiers like open ID uh Federation all that stuff uh why connected to a fairly narrowly scoped uh did relative resources that. Dmitri Zagidulin: Uh it does partly um the the bit uh that I'm not super clear about is I understand why versioning of any resources is useful in general and I understand why versioning um issuer Registries is useful. Dmitri Zagidulin: A bit I'm not clear on is is why have a um why combine it in the did linked resources specification right if I want to use did link resources to version my word document for example right I wouldn't put that in the spec. Dmitri Zagidulin: Got it got it. Alex_Tweeddale: Before so it's it's worth noting that in the spec itself um it doesn't go into detail on trust Registries at all it's very generic uh the draft registry stuck with very much just for this presentation and for contextualizing what you could do with it. Harrison_Tang: Yeah thanks Dmitry for the questions because I have the same questions and thanks Anker for a great explanation. Harrison_Tang: Uh Lucy please. Lucy Yang: Thank you Harrison I just want to quickly respond to the to the versioning um. Lucy Yang: Part of the the conversation I I'm not technical any way but then but my projects have been using training for some time so 1 of the um the the functionalities we are working with um was Ron Hoffer is on on having versioning um so that I I I can't do it I'm just I just might want to make a comment here I'm happy to go back to our technical team and learn more and see also like if they can share a little bit something of how you know they're you know we're approaching versioning but I just want to make a note that we are using untrained and and also our based on our conversation with um with fraunhofer is definitely possible to use trainers to have the versioning functionality which is very important so. Lucy Yang: Okay great I'm not saying like you know a multiple approach it's not good I just want to make a comment there there is there we are also working on that so good that you know there are. Alex_Tweeddale: And multiple approaches is good like there's never going to be 1 approach that pulls them all and that's not what we're trying to get to I think we want to have interoperable architecture that can result to different ways of doing things whether it's something like open ID Federation or you know did linked resources or potentially the way that you're doing things I think all will have merits or will be useful in their own particular context so yeah I I think we're like there's probably is a way they could overlap but you know if there's not then there's probably still merit in both. Harrison_Tang: Any other question. Alex_Tweeddale: Um cool sorry um anyone have got their hand up next yeah. Harrison_Tang: I got a quick question so uh I think uh again great presentations and then uh thank you for uh. Harrison_Tang: Having a concrete examples on kind of the root of trust and chain of trust uh example I'm just curious like what about the schema uh use cases do you have examples on how different companies uh use the schema uh like think resource uh the idea link resources for schemas. Alex_Tweeddale: Um we've put together a few like examples of schemas I mean it's basically the actual file being stored as a linked resource and then in the credential itself you just either include a did URL or you can even include the resolver link if you want to as well um. Alex_Tweeddale: Where we haven't had a big project yet where we're we're using lots of schemas um you know I still think there's obviously I don't think we're going to you know stop schema.org doing their stuff anytime soon but I think it's a good option for those that want to have you know ensure that that that a particular schema is stored persistently and then you can cross-link it as well with something on schema.org so you could have in our did link resource spec we also have an also known as property so you could have uh a d linked resource and then have an also known as linked to a schema.org schema um and cross sort of link between the 2 of them and anchor anything else to add on that. Harrison_Tang: Thank you Dimitri. Dmitri Zagidulin: Got it uh this is last of the question and more it might be interesting uh for for the linked data folks uh sorry the did relative um resources folks. Dmitri Zagidulin: Uh so. Dmitri Zagidulin: The the topic of uh account relative resources uh is becoming really important in. Dmitri Zagidulin: Area of decentralized social uh decentralized social media so Mastadon uh and and the rest of the fediverse for those of you who are familiar with that and so 1 of the things that 1 of the uh main topics of interest there is account portability how do you when um when switching service providers not break the links and so 1 of uh 1 of the proposals that I and some other people have worked on was specifically to use did relative. Dmitri Zagidulin: Or storing posts right like uh storing method on posts. Dmitri Zagidulin: https://codeberg.org/fediverse/fep/src/branch/main/fep/e3e9/fep-e3e9.md Dmitri Zagidulin: Uh except uh we we were using the did core relative ref mechanism here I'll post the the speck in the chat uh because that you know that that was already in the in the did core spec but I think it would be interesting to take a look at uh your specification to see. Dmitri Zagidulin: Uh if that if that's a better fit for the decentralized social media model thanks all. Harrison_Tang: Yeah Demetria has the Social Web group so. Harrison_Tang: Only the best person. Harrison_Tang: All right um any last questions we have 1 minute left. Harrison_Tang: Great thank you thanks Anker thanks Alex uh for jumping on and uh host a great presentation and great Q&A session so thanks a lot. Alex_Tweeddale: Yeah thanks all. Alex_Tweeddale: yeah thank you. Harrison_Tang: Right this concludes this week's ccg meeting thanks a lot.
Received on Wednesday, 21 August 2024 13:34:25 UTC