Issuing and Verifying JSON-LD Credentials with ACA-Py

[00:00:00]hello and welcome to the indicio identity Community Meetup for November um thank you for joining us uh welcome to anybody who is new here or um has it's been a while um we're really excited to have uh this conversation today and excited that you're here just a couple of um things I wanted to announce first off next month uh before the holidays Tuesday December 13th we will have a conversation about decentralized identity digital transformation and government in this in for in this meeting group as well so we're going to be speaking with the secretary of Commerce from Rhode Island Elizabeth uh Elizabeth Tanner she presented at hyperledger global forum for anybody who attended that event um she's a wonderful speaker and she's going to be speaking um and telling us about her adoption of verifiable credentials um for the State of Rhode Island and then Nancy Norris who I'm sure a lot of folks in the BC gov community that are here she will be here as well and having that conversation about uh the um digital trust in the ministry for energy mines and low carbon Innovation for the government of British Columbia so very excited to have those two we also have uh the Minister of Justice from the government of Aruba joining us as well so we will have three government officials to talk about um their sort of champion championing championing of decentralized identity in their communities um this identity Community Meetup is made possible due to indicio's public benefit Mission uh part of it part of in DC's public benefit Mission so we are really uh excited that we have this opportunity to help drive that mission of expanding the the youth adoption education understanding conversation around decentralized identity all things identity really um so we're really happy that we can do this um so with that said I'll give one more plug and that is on December 14th uh before the holidays we will be having a full webinar demonstration of indicio proven and that is uh in dco's open source um uh complete open source uh issuer verifier holder complete trusted digital ecosystem uh for verifiable credentials so if you're interested in seeing the whole kind of Soup To Nuts I'll put the link in the chat and you can join us there if not no worries uh and with that said I will pass it along to one Daniel Bloom to get us started so thank you all so much enjoy all right thank you Helen um happy to be here today my name is Daniel Bloom I am a software engineer and team lead at indicio I've been in the decentralized identity space for a while uh starting off in the Indie agent working group way back in the day which then turned into the hyperledger Aries project and I've been around ever since um also had the opportunity to contribute to the decentralized identity Foundation uh both in code and as a co-chair of the interop working group um I have my hands on a lot of things but I I spend most of my time working with Aries Cloud agent python um and today we'll be talking about issuing and verifying Json LD credentials with hack Pi I'll also hand it over to uh Peter for a brief introduction of himself before we get started hello everyone uh my name is Peter Strobel I'm I've been associate software engineer at indicio since July of 2021 uh I've after graduating with a Bachelor of Science in physics from Willamette University here in Oregon uh I've been working with and uh with repositories very closely linked to uh hyper-ledgers occupy including the AC by minimal example repository uh the Occupy pickup plugin and the areas toolbox [Music] without further Ado let's get into a presentation cool so uh of course we'll be talking about chasing all the credentials today um we'll start off with the basics just kind of getting into what our Jason Aldi credentials what uh what constitutes the Json LD credential uh we'll go through a brief overview of the verifiable credential data model so you can get an idea of of what these credentials look like then we'll move into issuing and presenting Json LD credentials using acpi followed by a demonstration and then wrapping it up briefly with discussion of the limitations of acupai and Json LD credentials before I get started I do want to give a brief acknowledgment that these are hotly contested topics in the decentralized identity Community um however it's it's in my personal opinion at least part of advocating for principles of decentralization is accepting that some people will choose to do things differently and rather than getting caught up on which credential type is best we do our best to see the advantages and disadvantages of each type and judge which one meets our needs and use cases and that tends to be on a case-by-case basis something that matches one use case will not perfectly match another um many of us are of course invested in the hyperledger areas and in the ecosystems which gives us a very mature credentialing system in the form of an on creds and we do think that a non-credit is great but we also fully acknowledge that it doesn't meet every need and every use case so today we'll be focusing on the technical rather than the wider philosophical debate and on how we can take advantage of both the non-creds and Json LD credentials using Aries Cloud agent python uh feel free to send questions to the zoom chat as we go along uh if there's some really good questions that deserve answers immediately I'll do my best to answer those as we go along uh if not we've got a lot of people from in dco here today that might be able to answer your questions uh we will try to save some time at the end for for questions um so if you've really got a burning question that you want to raise hopefully you'll get an opportunity to I do ask that you please remain muted for the duration of the presentation though okay so what are Json of the credentials um so first from there I'll take another step back and say what even his job that Jason Aldi uh which is a Json I'll get it out eventually JavaScript object notation for link data or uh to put it even simpler it's just a way of encoding the data using Json this makes use of context objects that map terms to Uris that help us to unambiguously link data together so instead of having something that could be ambiguous like something just name um using linked to data context we can turn name into a full URI to something that describes what kind of name it is intended to mean um and so we we have very discrete definitions of what our terms are in the form of these contexts so Json of the credentials then or what we commonly refer to as Json LD credentials is probably more precisely described as an ldpvc or linked data proof verifiable credential which is a credential in wccbc data model format signed using linked data proofs foreign so ldpvc is one of several credential types in the wild today others include an on-creds jwts acbc MDOC jwp DTC all the three and four letter acronyms you could hope for uh and while we're on the subject of these credential types I did want to point something out briefly and that is that the unique combination of format plus cryptographic Primitives whether that's the methods key and signature types or the types of assertions that can be made with those Primitives these are essentially the combination of these are are what makes up one of these types which also means that there can be overlap between the different types in the format or crypto Primitives that are used but it's that unique combination that form these distinct types to kind of give you a little bit more of an example what I mean by that a non-preds has not traditionally been formatted in a way that aligns with the w3cvc data model there are several reasons for this uh with the foremost in my mind at least being that the on credits implementation was first implemented at a time when the BC data model had not yet reached the level of maturity that it set today um however there's not really strictly any technical reasons that a non-cut's credentials could not be expressed using the VC data model and besides simply inertia in the sense that we have a lot of deployments in the wild today already uh this is actually in fact one of the goals of the hyperledger and uncreates project to uh to bring the anacred specification in alignment with the VC data model and I expect that in the not too distant future we'll be able to exchange and on credits credentials in a w3c VC data model compliant format but since the non-credits uses CL signatures and have significantly different requirements for generating and verifying these proofs just being in the same format does not determine interoperability likewise the VC Theta model also explicitly defines formatting for VCS as jwts even though the signatures over the claims of the credential differ significantly from signatures using link data proofs so there's a lot of different credential types out there and ldpc fits in that that scope by being a w3c VC data model with link data proof credential format okay so having established what we mean when we say Json LD credentials uh the next natural question I think is why should we use them especially when we uh when many of us at least are pretty well versed in the non-credits ecosystem I think this is a deeper question than it might seem on the surface uh and the reasons for pursuing other credential formats could be as simple as that's what my client's interested in or as nuanced as I want to take advantage of the ability to present credentials about a subject other than myself so there's a lot of reasons uh but to call out at least a few uh the first that I've got here on the slides is uh the one that I just alluded to uh Json of the credentials can be held and presented by anyone whether they are the subject of the claims made in the credential or not uh so this enables us to present authentic data about a party that is someone other than ourselves and this may seem counter-intuitive from a non-credits perspective where we frequently go out of our way to ensure maximum privacy and control of of the owners of the data um and certainly in the context of individuals where privacy and control are indeed some of the most important guiding principles for our whole world view of an on creds uh there are significantly fewer use cases where this lack of a binding would be a benefit for individuals however if you consider verifiable credentials about public entities where the claims made are also public information I think there's some interesting opportunities that can be found there one such example that comes to mind is delegating authorization you could for example present a credential alongside your own credential where you are the subject that proves to the verifier that the issuer of your credential was authorized to issue that and through that mechanism chaining Trust From A starting point in a decentralized way this does however add a layer of complexity that we generally don't have to worry about in the non-creds if the holders the subject of the credential the holder must provide us an additional proof that they are the subject usually through proof of debt ownership and we'll look at that in a little bit more detail later on if that's unclear um let's see alternatively uh Json all these somewhat simpler cryptography may be appealing to you especially when you compare it to a non-cred seal signatures cl6 require RSA Keys which are large and potentially slow to generate and use in constrained environments like iot and there are of course you know specialized Hardware modules for RSA keys but it's unlikely that these will support CL signatures Json LD ldpvc on the other hand uses signatures that are more commonly supported by Hardware modules and in the iot context were unlikely to really benefit from the additional privacy guarantees of an on creds and so Jason Aldi may be a really good fit for your iot credentialing use case and then finally if you're into the semantic web thing Json LD allows you to express deep semantic structures with unambiguous linking of attributes together though there is some heated debate on the subject of whether it's appropriate for credentials about individuals to have deep semantic connections that's a whole other thing that I won't be touching but regardless of whether of how that debate shakes out these deep semantic structures could be useful in Enterprise contexts where it's a public entity whose data is locatable in a you know the big graph in the sky of semantic linked data so now that we've got some background on Json of the credentials and how we might use them when compared to a non-grads um let's start diving into some of the details of the BCE data model um and get a feel for what these look like um since a lot of us are familiar with the non-crits I will draw some comparisons between the two as appropriate hopefully to help us enhance our understanding uh first of all it is important to understand that the VC data model actually defines two different verifiable objects which are verifiable credentials and verifiable presentations a verifiable credential is a set of one or more claims made by an issuer and what makes it verifiable is that it is packaged in a way that it is tamper evident and the authorship of the credential can be cryptographically verified verified meanwhile a verifiable presentation is data derived from one or more verifiable credentials issued by one or more issuers that is shared with a specific verifier so a verifiable presentation is also a temporary evident encoded value as a presentation which likewise has the same cryptographically verifiable authorship characteristics as verifiable credentials do uh so let's digest that just a little bit further what does it mean to have two separate verifiable objects it means that the value received from the issuer is not the exact same value shown to the verifier it could be um but generally it will be some value that's derived from that or or at least annotated with additional attributes to help the verifier um obtain the proof that it was requesting believe it or not we are actually already used to this split between credential and presentation in the and on credits world uh we receive a credential from the issue and then every presentation made from that credential is actually a derivative and not the actual credential itself so in the non-crits this enables us to do selected disclosure compositing multiple claims from different credentials into a single proof and present predicates on claims rather than revealing the original value the separation between verifiable credential and verifiable presentation in the VC data model allows for the same set of functionality though to my knowledge there are only a few examples of this so far with one of those being the select disclosure with BBs plus credentials that will be demonstrating later uh then Additionally the verifiable presentation allows the holder to present additional proofs to the verifier such as a proof update ownership to help form that holder subject binding in the credential each vce data model whether it or excuse me each BC data model compliant credential whether that be a ldpvc or another type has at least these basic ingredients to it a context which is a Json LD construct that we will look at in a little bit more detail a type which identifies the type of the credential such as passport or driver's license or ice cream truck loyalty card uh an issue which identifies the issue of the credential issue and State again self-explanatory but it defines when the credential becomes valid uh the credential subject which contains the actual claims of the credential the actual interesting uh pieces that make assertions about the the subject of the credential and then we have a proof which contains all the cryptographically verifiable evidence and Associated metadata that the claims made in the credential are from the issuery okay so first of all the context property um so to those learning about Json LD for the first time this is easily the most Arcane aspect of credentials adhering to the VC data model the context of Json LD credential found in the at context property enables the shortening of long unreadable Uris into something that's a little bit more human friendly so as we discussed earlier if we had name the context allows us to map the string name back to a full URI where we can find documentation about exactly what kind of name we're talking about in that context um in my mind I kind of relate the context back to a dictionary of terms and then borrowing further from the analogies made in the BC data model specification in order for two people to have a coherent conversation they need to be speaking the same language where the words mean the same things to both parties that's how you convey meaning and this is what the context essentially defines for a given credential these contexts are ordered sets containing Uris to resolvable contexts or to objects defining a context um and then finally the context property must be present even if the processor does not explicitly use it um and the first item in the ordered set of context must be the core context of w3e.org 2018 credentials V1 so Json LD credentials do not require schemas in the same way that a non-credits credentials do however there are some similarities between Json LD credential context and a non-credit schemas in Json LD creds the context defines the terms used in the credential and this happens to include both the attribute names of the claims as well as the you know type issuer issuance date fields that we're talking about as being core to every credential um on the other hand non-credit schemas only to find the attributes or claims of the credentials they describe context must contain all terms used within a credential and where we have multiple contexts which most credentials will have multiple contexts um but the contexts are merged together you take the union of all the the terms and values used with I think the right most context in the ordered set taking precedence if there's any conflicts collisions um and then if you have a term that's contained in your credential that is not found in that Union of all the contexts the resulting credentials considered invalid or at least invalid Json LD similarly in the non-cred so all attributes found in a credential must be found within schema and however different from Json LD contexts and on credit schemas are of course only possible with the single schema you can't join multiple schemas together finally Json LD credentials need not exhaustively include every term defined in its context in other words the context does not express that a particular term is optional or required it merely defines the terms uh in my mind going back to the dictionary analogy if we have a dictionary of terms not every sentence that we form needs to contain every single word in the dictionary additionally the dictionary doesn't actually Define grammar or contain grammar it just defines the terms that can be arranged according to grammar to form something with meaning a non-credit schemas do completely define the expected attributes of a credential however so in other words if if a credential is missing an attribute that's defined in the schema the credential is considered invalid uh let's see so neither Json LD context nor a non-credit schemas actually Define the data types of the values of the claims contained in the credential this was actually a bit of a revelation to me when I I realized it um I had the incorrect perception that but Json the Json LD contexts went further than they do and described the values associated with the attribute names but that is not the case as it turns out um it merely defines terms and then if you do want to more strictly Define data models or data types of the claim values the VC data model has a separate optional parameter for linking a Json schema object that can then be used as a validator for issuing or receiving credentials according to that schema we won't be looking at that today though the Json schema bit okay so next we have the type property I saw the question in the chat I think it was very apt one actually the type property is is what expresses the kind of verifiable credential that we're considering and this helps the processor determine if the object provided is appropriate for its goals every verifiable credential has at least one element in this type array of verifiable credential and optional you can specify more specific types in practice especially in acupai it is actually required that there be additional types beyond the core verifiable credential um on the other side verifiable presentations require a verifiable presentation type and optionally other more specific types and in the same way as verifiable credentials do off the top of my head I don't remember exactly if that was required in this context but it is definitely required in the context of issuing a verifiable credential it must include an additional type uh this is pretty self-explanatory I think pretty direct we have the issue of property uh this expresses oh actually now that I think about it I just had I remembered something I want to call out here the type property um again drawing analogies to a non-creds uh the type property is in some ways similar to the name of a schema in a non-credits um it doesn't actually Define the attributes associated with it it just names it and gives us a value that we can use to determine uh or to express what sorts of values that we are interested in um okay sorry back to the issue property uh this expresses the issuer of the verifiable credential this must be present and it must be either a URI or an object containing an ID property which is a URI uh generally this will be the did of the issuer which subsequently enables resolving the machine readable information that is used to verify the credential like a did document which contains verification material uh this property is analogous in some ways at least two including a credential definition ID in credentials issued using anoncreds ishman State pretty straightforward at the time at which the credential becomes valid and this must be expressed as an XML date time string and then the credential subjects this contains the actual claims about one or more subjects so you can have multiple sets of credential subjects which can each have their own independent IDs identifying different subjects and different sets of claims the credential subject property must be present and it will generally include that ID to help with you know actually verifying that the holder of the credential is the subjective potential as we've hit on a number of times already in non-credits terms we would generally call these credential attributes um but yeah same difference here I guess uh then finally the proof property this enables the verification of claims expressed in the verifiable credential at least one proof mechanism and the details necessary to evaluate the proof must be present a minimal proof will at least make it possible to detect tampering and verify the authorship of the credential representation it could do more such as allowing you to selectively disclose or or provide other proofs perhaps proof of non-reducation those sorts of things but each proof object must contain a type property specifying which method was used to generate the proof which then of course helps us to verify it later on without having to guess about types or anything like that the properties included alongside the proof will vary according to the type of the proof so in a hypothetical world where we already had a non-creds expressed SVC data model objects the proof for non-creds would look quite different from a proof of type 82 55 19 signature Suite 2020 or whatever it is okay so to wrap up our exploration of the VC data model just wanted to show a couple of quick examples of these verifiable credential values we'll look at more examples as we go through our demonstration of course uh but just wanted to give a general feel for what these look like we see our context we see an optional ID the type that we discussed issuer issue and state credential subject with ID and then claims made about the credential subject one thing that is a little unique about um ldpvc Json LD verifiable credentials is that the claims made in the credential can be more complex objects than simple string values as is kind of a limitation that we have in the inocrats world so we can express trees of data as opposed to just um flat normalized data like we generally have to do within and on credits um and we'll see later on as we look at presentation definitions that we have to be able to address these credential values by walking through those paths as well and and down each limb of the tree we'll get into more details on that um and then it will and of course include a proof I've omitted the values here we'll look at uh concrete examples in our demo and then to contrast with the verifiable credential this is what a verifiable presentation looks like uh again that has a type and ID and a context and then a set of verifiable credential objects and a set of proofs and with that I will hand it off to Peter to take us through some of the details of issuing Json LD credentials with acupai specifically thank you very much I'm gonna steal screen share here and perfect okay uh so wrapping up uh the VC format discussion let's get to actually talking about how we use Json Json LD credentials uh with acupai uh double checking uh you can all see pretty much the exact same slides right yep excellent okay so turning our attention to the implementation of Json LD credentials in acupai it's important to keep in mind that the original V1 protocol for credential issuance and present proof are not compatible with Json LD fortunately for those who are using a non-creds and issue Prudential version one though uh you can present credentials issued using V1 with either B1 or V2 of the present of the yeah excuse me of the present proof protocol unfortunately that means that in order to use Json LD credentials in your agents on top of adding support for the Json LD credential type itself you'll also need to add support for the version 2 versions of both protocols occupy does support both protocols but you will have to adjust your own controllers to use the new V2 endpoints to take advantage of them um we will discuss some of the differences and protocols in the admin API of act by in just a moment um so with uh compatibility constraints in mind let's take a look at how to actually issue Json LD credential with acupai uh now the Israel Prudential version 2 protocol should look pretty familiar if you know V1 protocol Works through a message exchange between two parties the issuer and the holder which in a real life scenario could be a government and someone applying to get a passport for example uh the overall message flow has not changed from V1 but there are some sort short circuit paths that are not possible when using non-creds that are reducing Json LD credentials that are worth briefly calling out here um the holder can initiate like credential exchange by directly sending a request credential message instead of starting from a proposal now if there is no cost to make the holder aware of when issuing a Json LD credential we can entirely skip the proposal offer cycle and proceed straight through the requesting credential uh now in a non-creds the issuer must inform the holder of some crucial cryptographic information before the holder can send a credential request this meant that if the holder wanted to initiate a credential issuance it must do so with a proposed credential message triggering the required exchange of cryptographic information in the offer credential message from the issuer uh this is not the case with Jason LD however um if negotiations yeah excuse me if negotiations are required then this must be done with proposal and offer messages still moving on uh aside from aside from the short circuiting differences possible with Json LD there are some notable message specific differences um first to summarize all the changes made in a few words uh the issue credential V2 protocol uh correct the values and structures in V1 that were strongly influenced by Indian non-creds now there were efforts in the V1 protocol to accommodate other credential formats But ultimately there were shortcomings that made doing so in feasible without making major modifications hence we now have V2 uh like for example in V1 the credential preview object contains several filters like schema name uh schema id credif id Etc that generally only applied to non-creds uh in V2 the credential preview object has been further generalized and are considered attachments with separately defined formats uh now there are multiple filter formats linked to a link from the rfc's registry of such formats including uh dif credential manifests in the credential abstracts and linked data proof VC detail uh link data proof VC detail is the is the format that we'll be using uh during our demonstration later uh now finally uh that's trying to figure out where to position all the cameras excuse me uh finally uh issue credential V1 of the protocol did make credentials attachments which were intended to allow for the flexibility in credential formats but sadly and fatally this did not include any indication of the format of the credential included in the attachment uh now V2 defines formats in a similar fashion to the filters used in credential previews uh for the final credential values as well uh the registry of formats linked to the RFC include the link data proof VC and hiver Ledger into credential um now there are some notable differences between V1 and V2 versions of the issue credential API uh for acupai for example uh like here's a side by side of the comparison of the issue of credential send endpoint of issue credential V1 on the left and V2 on the right on the left we see that the Indie specific attributes of schema ID schema issuer schema name uh schema version credif ID are included at uh the root level of the request body whereas on the right we see these values have been nicely organized into the filter Indie object uh looking a little bit closer we can also find uh that the credential proposal object on the left has now been renamed to credential preview on the right finally we see that the addition of the LD proof we see the addition of the ldproof filter object which contains a credential and options properties the ldproof object is defined by uh by Aries rfc0593 uh you can find that the format of these values is very similar to the VC HTTP API uh however it does differ in a few key ways uh now we'll be looking into V2 uh we'll be looking to V2 uh API in a little bit more during our actual demonstration uh moving on let's take a look at how we actually present Json LD credentials in acupai so the percent proof protocol uh V2 is a general purpose verifiable presentation exchange protocol meaning that it can be used to present credentials in any format I mean granted that your agent supports these formats now as with issue credential protocols if you're familiar with version one of resent proof then version two should look very familiar uh as a quick review most presentation exchanges are initiated by the verifier by sending a request presentation message but the proofer may also start the exchange with a proposed presentation message uh the protocol then supports a negotiations phase where the verifier and prover can repeatedly exchange counter proposals and requests until the prover is willing to present proof of the requested attributes it's kind of like trading properties in Monopoly until everyone gets a very beneficial Exchange uh now to do so the proverb sends a presentation message and the verifier finishes exchange uh with an acknowledgment message which you can see at the very uh bottom of the flow on the right uh now as with the issue credential protocol uh the present proof protocol required changes to better enable exchanging presentations in various formats uh the original V1 protocol was again heavily influenced by Indian non-creds which resulted in some indie Centric values and structures in messages of the protocol uh now even though presentations were delivered as attachments this gave the one protocol a very distinct Indie flavor uh version two of the protocol was changed in very similar ways to V2 of the Azure redention protocol so in each message that used attachments for delivering presentation objects specific to a given format an explicit formats field uh was added to help identify the type and versions of the attached objects now each message also has an Associated registry of objects for Exchange in the attachments for example the presentation message the registry contains definitions for dif presentation exchange submissions and hyperledger Indie proofs as a natural result of now supporting V2 of the percent proof protocol and with the addition of support for link data proof VCS the admin API for requesting and fulfilling presentations has also been changed from V1 to V2 in occupy uh the most notable change as shown here is that uh the Indie specific attributes uh that we see on uh the right are now nested under an object called Indy alongside this object we also find a new object for a specifying presentation uh for specifying presentation requests in the if format which is called presentation definitions uh we'll also go over the differences in more detail in just a moment yeah there are a few other minor changes to take into account uh such as proof requests object from V1 is now in a presentation request in V2 uh going into just a little bit of the Json LD presentation definitions we won't be going over this super in-depth because we will be going we will be seeing these again in our demonstration um but the presentation definitions of Json LD are just objects that help articulate what proofs verifier is requesting from the holder and they help the holder decide how and whether to interact with the verifier uh it is composed of inputs that describe forms and details of required proofs like for instance you see um in the constraint check section uh there's a field subsection which requires some kind of date of birth which means that whatever uh whatever credential is being presented from the holder to a verifier it does need to include a date of birth um now this of course this is not going to allow the holder to uh to specify to just to selectively disclose this information about I don't want to give them my exact birth dates but I might want to do like I'm above this age um this does not do that but there are we do have uh Signature suites that do do that for us um going over just a few of the uh components broadly we see the necessary components that were seen in the previous slide on the left such as the ID and the input descriptors um and there are a couple optional components on the right such as the name what you want to name the presentation uh what is the purpose of this presentation why are you sending it over to uh the verifier uh format the presentation should be in um and there are many this is not a comprehensive list there are many many many other uh optional things you could add into your presentation and I believe also some custom definition that you can add into sure there'd be something that is not that you would want to include uh yourself that's not specified anywhere else um a couple of things about uh some of those items uh we saw previously one of the necessary components was in is holder uh object for uh for your input scriptures which just specifies that the holder must prove that they are the subject of the claim associated with the constraint and which is also necessary for link data proof VCS because it uh the lack of holder binding um there's also a limited disclosure option which specifies that the holder will selectively disclose flames and won't include claims that were explicitly requested that were not explicitly requested by the verifier now in order to use selective disclosure with Jason LD credentials and occupy uh both the issuer and the holder do are required to have BLS keys um and that is an overview of Jason LD credentials in ACMI now let's get over to the incredibly fancy demonstration I will give back screen share thanks Peter yeah okay so I shared back here for a minute okay so before we jumped into the demo I did want to give a little bit of Preamble a little bit of uh orientation uh to what we'll be seeing within the demo um so uh we are going to be using a project that is maintained by indicio called the acpi minimal reproducible example it's a template repo so you can not only clone it but you can also generate other uh projects from it which is quite handy um and we use this to reproduce scenarios with the minimum set of requirements and while clearly showing the admin request being sent to the agents and the web hooks being received from the agent so it's basically a way of doing a a very quick demonstration of a feature or problem and that's how we tend to use it at mtco you can find a link oops uh to the branch that I'll be using so if you clone this make sure you check out the demo Json LD branch and then if you'd like to run the example yourself you can do so with a simple Docker compose run example don't forget to down the containers after the fact they will be left running in the background after this program exits so if you're like me and you get a little uh compulsive about those sorts of things make sure you do a Docker compose that so there will be three services that are started up by the docker compose script that we'll be using in the example uh one is the example service which acts as a controller the Alice service which will be acting and fulfilling the role of issuer and verifier and then a bob service which acts as holder and prover the controller will send admin API requests to either of the agents in order to orchestrate a scenario between the two agents controller then receives web hooks over websocket back from the agents this helps the controller to um take the correct action at the correct time and helps us know when asynchronous exchange is occurring between Alice and Bob have completed so we can trigger The Next Step In The Exchange and then finally Alice and Bob are exchanging VidCon messages um and that's the the only interaction taking place between these two Services is over did come okay and now I will switch over to My Demo do a little bit of screen juggling here uh there's my window okay I'll do a quick double check on font size is that legible I can increase it I'll go ahead and increase it um okay so I am in the minimal example project uh where I have it locally on my machine I am in the demo Json LD branch and I will now run the Run example right here so there's going to be a lot of output uh in just a second um and I will pause throughout point out a few highlights along the way uh and then proceed which with each of the examples that we've prepared for you thank you okay so for this first section here uh the issuer and recipients are preparing for a credential exchange um so if I go all the way back up to the top um we see that it started off a little further it started off by establishing a connection between the two agents this is what it's done with a box standard exchange without a band invitations exchange between two agents um if you're interested in viewing each of the steps along the way each of the admin API requests as well as the web hooks that are sent back to acpai um in this process those are all visible in the output from this example script um we'll skip past that though for now and then we prepare for issuance by first having the issuer prepare the dids that it will use to issue the credentials um for uh we will be issuing three different credentials two with ed25519 signatures um using didsov dids as the issuing did and then we will do one that is a BBS plus credential using a did key with the BLS key represented in it so in order to get that did SOB method on The Ledger we need to go through a bit of a process of transaction author agreement onboarding onto the network which I've all automated here since we're using the dco I believe demonet is the one we're connected to right now um we do some transaction author agreement stuff again this isn't the interesting part really of of this demonstration so I'll skip past it a little bit but we've created a public bid we've set it as public and it is now ready for issuing credentials from uh that did we will also create a BLS key and this will be used as the issuing key for PBS plus credential on the other side the recipient will also prepared dids that will be included in the subject of the credentials issued by Alice or our issuer um the ed25519 keys could be the same keys that are associated with a connection um could be other values usually it'll need to be something that you can prove ownership over and if that's a perioded you'll have to provide you know proof of ownership over that period which gives multiple verifiers uh correlating Vector so it's it might not be ideal in your use cases this is actually one of the limitations of Jason aldeed holder binding presentations um but yeah just to keep that in mind we also need to create a BLS key specifically for the holder to receive a BBS plus credential um uh and that is actually because in order to prove ownership over a credential where we're selectively disclosing information and then also um providing proof of ownership over that credential we have to be able to do BLS signatures so we'll jump on to the next step now here uh again a lot of output I won't go through all of this but I'll go to let's see um a few interesting points this is a credential exchange taking place between Alice and Bob uh where this is the request that um Bob is sending to Alice had to think that one through for a second there um so the credential that Bob is ultimately requesting here um looks like this from this point to that point so we see the context as we normally do with Jason Aldi credentials we see our credential subject uh which in this case includes the birth country birth date family name gender given name of Bob uh this context is using uh the core context and an example context that's included alongside the DC data model just for demonstration purposes we see our type which specifies that this is a permanent resident credential uh let's see what other key points here the ID is also included in the credential subject which identifies the key that Bob owns so he can prove that he is the subject of this credential later on and we also see our didsov issue we did in here this can be resolved later for verification purposes and then we also have specified that the proof type of the resulting issued credentials should be a 80 to 55 19 signature uh let's see let's find the final credential value to take a look at here which will include a proof that's our after requests credit issue must have missed it there we are so after signing our credential turned into a verifiable credential and now includes a proof which has a jws signature in the data proof style that includes headers the signed payload which would normally exist between those two dots in a jws is considered an external value that is uh uh reproduced in a specified manner for link data proofs and then the actual signature value included there we see that it specifies verification method which points to did solve and then the verification method identified by t-1 as the ID and the type specifies that it's in 825519 signature okay I'm going to go a little faster through some of these other bits here um that was next a presentation exchange occurring between Alice and Bob and we have a summary of that presentation uh after it took place we see that it verified is true so the verification of the credential was successful we were able to see the values were cryptographically verifiable as being from that original issue we can look at our presentation definition here so this was what was sent from Alice acting as the verifier to Bob who was acting as the prover we see options which include a challenge this makes it so the presentation is not able to be replayed if I understand correctly at least domain can't say what that is off the top of my head sorry um then we see the presentation definition that Peter was just describing a moment ago so we see that we specify that we want a presentation with a credential with a proof type of ed25519 we also specify the format type of the credential that we're requesting which in this case was an ldp verifiable presentation then we specify input descriptors and a set of constraints for those input descriptors so in this presentation definition we are explicitly saying that I is the verifier and looking for a credential where uh the given or the family name rather is builder in the credential that's kind of an odd constraint to place but you can in this particular context we can specify a purpose and then we specify the path to the attribute within the credential which in this case is credential subject family name we can do the same with other values of course so we've got another one here saying that I'm looking for a credential that contains given name and then is holder uh specifies that we are requiring that they prove that they own the did that was included in the subject and then we see the proof as given here so this is a verifiable presentation contained a set of verifiable credentials in this case just the one obviously the original proof from the issuer inside and then alongside that we have a presentation submission which helps the verifier map the presentation definition to this specific presentation that is being submitted to the verifier and then we see the proof which is assigned by the ID of the credential subject and this is our our holder subject binding proof here okay I need to move a little faster um so we've just done another ed25519 credential issuance let's go ahead and move on to the presentation and then I'll go back and take a closer look at the credential that was presented which had a couple of custom values so in this case we're using custom uh context objects and in in this particular one it's embedded directly within the credential as far as I know this is actually a discouraged practice it's not recommended that you directly embed contexts into your credentials they should be published somewhere where there's at least some level of permanence to them um but for the sake of demonstration I've included the context here and this is a pretty minimal context which defines just two things the table tennis tournament win uh and the date one claim we use that table tennis tournament win as the type of the credential that was issued where's that there it is and the date one as one of our claims in the credential subject um yeah let's go on from there and then finally we'll do a BBS plus issuance which just took place and then we'll move on to the presentation and then I'll briefly call out what our presentation looks like when we have selected disclosure so here's our verifiable presentation we we add in employment credential we only wanted them to disclose their clearance level uh so that's what is being expressed in this presentation definition here we also included the as holy directive which or constraint I should say which requires that the holder proved that they are the subject again and we explicitly required them to limit disclosure so we don't want to see any of the other values contained within that credential just the clearance level uh so this credential included some other values date of employment I think um a date of higher whatever it was but we only see the final clearance value included here and then a proof um that uh it was derived from the signature over that credential value um oh my goodness we're out of 10. okay so there's a lot more detail that you can look at there in the demo um if you want to run that yourself uh I need to go back and wrap it up with some final thoughts on um some of the limitations that we are currently experiencing with enact by and within Json LD credential ecosystem so first only ed25519 and BBs plus signatures are supported which is a bummer um also there's only strictly support for issuing from ditsub and dip key however you can verify from a wider range of did methods if you plug in something like a universal resolver into your act by instance there's also no built-in support for credential status or revocation unless there's no built-in support for validating a credential against a credential schema as we talked about a little bit earlier uh and then finally there's not really right now a very clean way of exchanging those BLS keys that we identified as being required for both parties um in order to issue BBS plus credentials when we eventually end up in a world where we have things like did Indy um or support for other did methods within acupai where there's more flexibility in what values can be written to the did document we will have the ability to specify DLS keys inside of those bid documents which should help us solve this problem and then finally the the integration in aquify could be cleaner not to throw shade on anybody who's contributed to this implementation in acupai but could be better Library support could be a little bit more flexibility and did method in signature Suite support finally finally but um some limitations to Jason LD in general um complexity I think is one if you're unfamiliar with Jason LD uh wrapping your mind around contexts can be a bit of a jump uh it certainly was for me um and uh this is kind of a again hot button topics here um these are highly contested as recently as iow and other forums I'm pretty sure uh but then in addition to the complexity of just understanding Json LD itself we also need to worry about the immutability uh and availability of those contexts if you have a context that's been published somewhere and then suddenly it's unavailable uh you now have a much harder time verifying that the credential is what you expect it to be and it effectively voids the credentials associated with that context in fact as I was going through preparing the demonstration for uh this presentation the w3.org credentials Court context actually became temporarily unavailable and my issuance and presentation failed as a result um granted the spec explicitly states that you should statically store those and cache those locally it's still a problem if you need to dynamically retrieve any context at any time uh zero knowledge proof predicates are not possible with current Signature suites and the holder binding which can be a benefit is not directly um and included as part of it we have workarounds of course in the form of proving dat ownership but yeah okay thank you um that was a lot of information I appreciate those who participated and followed along um I apologize we didn't have enough time for questions at the end here but if you want to reach out to us at indicio we are more than happy to answer questions and help you do what you want to do with that guy