11P/ Credential-based login to a Pico-based application

Credential-Based Login To A Pico-Based Application

Wednesday 11P

Convener: Bruce Conrad

Notes-taker(s): @convener

Tags for the session - technology discussed/ideas considered:

Verifiable credentials, authentication, picos, pico-based application

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Link to slides provided by Bruce Conrad: https://bruceatbyu.com/s/HRDDSiiw32

We presented the slides, and then a discussion ensued. Adrian directed us to his session (10H) and shared with us his experience with GNAP and OAuth. Vic asked many thoughtful questions. Johannes shared some insights on graph databases and a project called ObjecTime.

Before recording started, I stated the title of the talk and gave an introduction: the motivation for the work, that we used picos to create a Domain Data Store proof of concept, which is a “fully-sharded” database. The point of describing it here is the authentication using credentials.

Read slide 3, “Motivation” highlighting BYU’s login page, shown on slide 4.

Rough transcript of recording follows:

So, the motivation for this work was to do something using verifiable credentials. [slide 5] The BYU sign in currently is a typical single sign on page that you saw on the previous slide.

For a long time we wanted something other than Net ID and Password. Vic, I remember you were in a meeting in IIW 29 where we had an Aries agent embedded in the user’s browser so that when the user went to a web site they had visited before, they were just “in.” Then we looked at it in more detail six months later [in IIW 30] and discovered that there was a fatal flaw with that because the browser could throw out the agent and its state, including its private keys and connections and so forth whenever it wanted to basically and so we temporarily abandoned that approach. Although I think it would make a good hybrid with the one I’m showing today. I enjoyed working with Trinsic. I know both of their employees who are with us today. Thank you gentlemen, and their studio login works in the way that I wanted to do. So, imitation being the sincerest form of flattery, I’ve implemented what they did, showing that here and hoping to advance that.

The application that I wanted to demonstrate is what I call a fully-sharded database. BYU wants a community facing Human Resources domain data store, which means that other organizations on campus may wish to access HR data and so far they’ve been doing it by dipping directly into the production transactional database and that's not a good idea. And so, they have a team implementing a proof of concept using Postgres. And, I’m using picos to implement a fully-sharded alternative proof of concept.

[Slide 6] So going back to why use picos to build a web application? Each pico implements an API on the Internet, and it encapsulates its state and synchronizes requests which makes it fairly easy to use for coding. A pico is also extremely cheap to run in the cloud. I have tens of thousands of them running in three different pico engines on one EC2 instance, and without my educator’s discount, that would cost me $8 a month. We also have a thousand picos or so running in our Manifold pico engine on another EC2 instance that I’m not billed for but I imagine it costs a similar amount. The marginal cost of adding another pico is vanishingly small.

Also, new behavior can be added easily to a pico. So any pico can become an Aries agent, for example, just by installing some rulesets in it. And, finally, picos extend the current trend from monolithic applications to micro services, which we’ll look at on the next slide. The next step I’ve sometimes called nano services. Perhaps they could be called “pico services.” They’re much smaller, because instead of one domain of a business becoming a micro service, carved out of the monolith, each entity of that domain, the micro service domain, becomes a pico and contains its data and code.

[Slide 7] So the transition from monolith to micro services… so the idea is that the monolithic application for say a university that handles human resources and student registration and classroom scheduling is split out into micro services. And each micro service contains the business logic for its portion, and this kind of micro service here [indicating one of them] would just contain business logic because it doesn’t directly access data. The data itself will be partitioned vertically so that all of the HR data would go into this database [indicating the leftmost], all of the registration data into this one [indicating the middle disk], and all of the classroom scheduling data could be in a separate database [indicating the one on the right]. So, this transition is in progress in our industry.

[Slide 8] Sharding is a little bit different. Here there is one tracking table in a database and three of the records in that table are on one database [indicating the top one] and two of them are on a different one [indicating the bottom one]. And that’s called “sharding.” It’s used to increase availability. This particular example of sharding also is a hint at fully sharding because everything about tracking number 123456 is in a database by itself.

[Slide 9] If we shard a database completely with one service per entity, then here’s a diagram of that as a graph database. Each one of these lower rectangles represents one employee of Brigham Young University. And then there is this other pico which represents a collection thereof. This is an abbreviated diagram as there would be tens of thousands of picos in this layer [indicating the picos at the bottom] and again each pico contains all of the data about that person and all of the business logic for interacting with them.

[Slide 10] So the way it becomes an application is that we add a ruleset to the “persons” pico so that [bouncing back to previous slide] it becomes besides keeping track of all the people, it also is a web application. Now where I became interested in authentication is that if I want to demonstrate this to my colleagues at BYU I’m going to have to place it on the Internet whereas now it's running on localhost. A pico engine can easily be moved to a docker container in the cloud. That part isn't the hard part. The hard part is that the data it contains shouldn’t be seen by anyone except members of the BYU community. And so to get that authentication, I created a separate application that runs in the BYU single sign on environment, named YCred.byu.edu, and its sole purpose is to certify, using single sign on, that the individual visiting the web site is a BYU community member. And then I partnered with Trinsic and host, with them, an organization also named “YCred” that I can use to create credentials and verify them. And then again added a ruleset to the “persons” pico to handle authentication. So just going back to the diagram [previous slide and indicating the top pico] now the “persons” pico is three things: it is keeping track of all of the people (knowing where they are, being able to produce an address for them); it is a web application; and it is an authentication verifier. [returning to slide 10] Any questions to that point?

[Slide 11] We’ll go into this in more detail, but here’s the overview. The overview at the top level is that when you use a web application, you sign up once and you login many times thereafter. Signing up involves requesting a credential, seeing the offer of a credential as a QR Code, scanning that with a self-sovereign identity wallet app and then you now hold a credential. Logging in is when you go to the application, you’re required to prove who you are. You see that request. You scan that code with the same wallet. The wallet will suggest a way to prove what you need to prove. You press the “present” button, and then you’re in the application.

[Slide 12] So, the sign up process. To request a credential you authenticate using BYU’s current single sign on mechanism, which we saw earlier involves a Net ID and Password or one of the federated IDs, and then the web application, YCread, running in that environment, offers you a credential, by redirecting to a Trinsic page, as we’ll see, and you scan that QR Code with a wallet and you now hold it.

[Slide 13] So, these are the players [indicating items along the top]: you are visiting [circling stick figure]; through your browser; the web application; there’s also the YCred application we spoke of; and the Trinsic API. So the way it work is that you visit the application, the pico responds with the index HTML page, but before it shows you anything, it detects that you’re missing a session cookie, and so it redirects to the login page, which we then see [slides in from right]. It looks like this, and you have the option of either logging in with a password, or with the credential. To Steven’s point about having the application be available to people who don’t even have a smartphone, this option allows you to do that and migrate people towards the credential based method of authenticating. If we saw this login page for the first time, and we’re someone from IIW we would of course want to login with the credential, and not having one yet, we would click on this link [indicating YCred link]. That would make a request to the YCred application and it would show a page [slides in from right] that certifies that you are a member of the community, with a particular Net ID, and you could then request a verifiable credential. That request goes through the YCred application, which on the server-to-server side issues an API call to the Trinsic API to issue the credential and then we redirect you to the Trinsic “You’ve received a credential offer” page [slides in from the right]. I’ve mutilated the QR Code here because for all I know, Michael or Beto you could tell me, for all I know it might still be valid. I was hoping no one on the presentation or watching the recording would grab the credential for themselves. In any case, once you’ve done that, your wallet now has the credential.

[Slides 14-17] So the next few slides are just a repeat of that without animations. You go to the login page. You request a credential; you ask for it to actually be presented to you, and you scan it to accept it.

[Slide 18] Any questions to that point? Logging in, you visit the web application, and you’ll see a proof request, and you’ll scan and present the credential, present the proof, and you’re logged in.

[Slide 19] So, the same players, and the flow is a little longer [mousing along the left line top to bottom]. After logging in, you use the application and then your logout. But I’m going to zoom in

[Slide 20] just up to that point. Notice that YCred plays no further role. It was only used to gain the credential the first time. So when you return to the application, you see the login page [slides in from right] just exactly the same as before, but this time you’re going to click the “Login with credential” button, which will let the application know that you need a verification. That will, server to server, use the Trinsic API to get that, and will return, and here the application generates the QR Code itself rather than redirecting you to the Trinsic page. Notice the “Scan with digital wallet” is displaying “checking in 13 seconds”. That’s because it might take you quite a while to pull out your phone and scan the code, and so the web page, the login page, is polling for the verification. To do that, it asks the application. The application asks Trinsic for the verifications, and it will continue doing that until you actually scan the code. Then it will poll for verification, and redirect you to the app [slides in from right]. With that amount of interaction, you’re now logged in. You’ll see your Net ID up here [indicating blurred area at top right], you’ll have the option of logging out when you’re finished or use the application however you plan to use it.

[Slides 21-24] The next few slides are for the benefit of someone watching this later to see without animations. To see the login page. You choose to login with the credential. You scan the QR Code. And you’re in the application.

[Slide 25] So that is my demonstration. And, I’m open for some questions and discussion now.

Steven, is that the kind of thing you’re looking to do? [Steven] Yeah that is what I’m looking to do. With the exception that I’d like to find a way to do that same approach where you’re verifying a credential, but without relying on a smartphone. Don’t want … and everybody else using traditional username and password. I’d like to have everybody on a SSI digital identity from some vendor. Some of them will have wallets on their phone, some won't have phones. I can have a cloud based solution I guess, but that’s what I’m looking for.

Asking Michael or Beto to jump in with their impression of that requirement? [Michael] I would say, yeah, you can definitely do that with a cloud wallet. We didn’t implement the login flow with one of our customers, but they do have a lot of customers who don’t have smartphones, and they have flip phones and stuff like that and so we did provide cloud wallets for them and they were able to manage all of their transactions by going to just like a public cafe or whatever, get on the computer, login with SMS to their cloud wallet and then they were able to access all their credentials with their cloud wallet. So something similar could definitely be done and you could have some sort of place to host a cloud wallet and could receive and present proofs on that application on that cloud wallet. So that could be a way, but then you run into that problem like to login to their cloud wallet they still have to do some sort of login.

[Steven] I see that as the equivalent of logging into your phone. You still have a login of some sort to get into your wallet. One login for many things. I’m curious what the UI, the experience might be like. I mean this is driven by bar code scanning. What the comparable model would be if I were not using a phone that I would be scanning QR Codes with?

[Michael] Another way could be with a connection, and then you can send a request to verify some credential through the connection. With push notifications on the wallet, you could have a little badge come up, saying hey someone’s asking for this credential and you can prove it that way. Another way, Bruce, with the Manifold picos, they can establish connections just by pasting in a link, so I’m curious as if maybe something similar could be done with a proof. If you could paste in a link to a proof. I’m not entirely positive if that works the same as a connection.

[Bruce] Yes, ideally, there should be something to reify or make manifest the connection that a visitor to a web site has with the application. Your application space is government I think you said, and the citizens of a jurisdiction have a relationship with the government, and it would be nice if that relationship was identified by a connection of some kind. For this particular usage where I just want to share a proof of concept with a few colleagues for an hour I didn’t go with the connection approach, which although that does make more sense. Instead I used Trinsic’s connection-free presentation of a verifiable credential because that’s just a shorter chain of events.

[Michael] And Steve just said in the chat that a QR Code is just a URL which is right so we could just paste whatever the URL is.

[Vic] I think this is similar to what Steven was asking about. For this piece where when I want to login, I have the credential in my wallet, and this QR Code that I’m scanning, that’s proving that I am the controller of that wallet? Or the controller of the credential? I don’t understand that last step quite.

[Bruce] It’s kind of like when you go into a bar or buy a product in a store and you have to prove your age. You would pull your wallet out, pull out your driver's license and show it to them. So what you’re proving is that you have in your possession a wallet which contains a driver’s license, which has a particular birthdate on it and a face that looks like you. So with this kind of verification you’re proving that you have in your control a smartphone that you’ve been able to get into because you know the key code to get into it or you satisfy the biometric to get into the phone and that you have a wallet on that phone that contains a credential that can be used to prove what you need to prove. That’s a pretty long way of saying it.

[Vic] And you’re trying to do that without establishing any sort of permanent connection.

[Bruce] Yes, for this particular application, since it’s a very transitory demo, I didn’t need to establish a connection first. Steve would need a combination of what I showed a year and half ago, I guess two years ago now, of you’re using a browser that has in it a connection to the web application, so that when you use that browser to visit the web application you’re in because the connection is there and, if the browser has thrown the information away, then you would fall back to this approach, and if you didn’t have your mobile phone with you you’d fall back to the user ID and password. That’s where I’m headed anyway.

[Steven] I may be asking the same question that was just asked, but I want to understand. In this model, the verifier is not double checking with any issuer that it is in fact a valid current proof. The fact that the holder has it and not looking for any assurance from the issuer to ensure that it’s valid.

[Bruce] That’s a really good question. It appears to be that way on the surface, but in fact the proof is constructed in such a way that the credential I present was issued by the issuer. So it’s not something I can put together in PhotoShop. That’s built into the triangle that we talk about: the issuer, the holder, and the verifier. The issuer and the verifier don’t need to have a direct connection because the issuer has cryptographically signed the credential, and the verifier can look up their public DID on a ledger and use that to verify that the credential hasn’t been modified and that it was issued to the person who claims to be holding it. Did I get all the detail in that right, Michael?

[Michael] Yes, that is correct.

[Vic] What if the credential has been revoked. Is that also

[Michael] That’s also taken into account. Yeah, it will check if that credential has been revoked. And, if it has then you don’t get logged in.

[Bruce] Yes, the proof would fail. In my particular case, again to streamline this, because my use case is so punctual, I chose to have it be a non-revocable credential. But my understanding is that Trinsic, who we partner with, right, to do the actual issuing and verifying, they say they can handle revocation. And Michael just confirmed that. Adrian, do you have any questions or comments about this process, or Beto?

[Adrian] Yes, I have lots. Unfortunately, I was picking up my granddaughter just as you were doing the demo, but if I can I can ask my questions. If not I can watch the video and contact you separately. I can try to reconstruct what our situation is.

[Bruce] Yes, I would very much like to hear your perspective. What we demonstrated is that you sign up and be given a credential which you would store in your mobile wallet and when you went to login you would be asked to present a proof that you would do using that credential in your wallet.

[Adrian] Right. So we have a much stronger constraint. Self-imposed, which is that we don’t expect patients to have a wallet or even a DID. We only expect the requesting party, the doctors or family members or anybody other than the patient but controls the equivalent of the pico. In our terminology it’s called a trustee -- it doesn’t matter. It’s in the cloud. And so we did not want to -- and there’s a couple of reasons for that. One of them is that we model guardianship, you know for children and elderly. Again so we didn’t want to have a one to one association between wallets and signing, right because that would confuse the guardianship issue. But also because we didn’t want to introduce the equity issue of like was mentioned earlier that wouldn’t have a smartphone or not everybody does. So what we’re planning to do is try and avoid having the patient or the data subject or credential subject have either a wallet or a password, because people have too many passwords. So, one example of being able to do that is to send a “magic link.” The way I sign in to Zoom, for example. Not Zoom, I’m sorry, Slack. I haven’t used a password signing in to Slack. And what we do, then, given that at registration, which is a one time thing, they’ve given us an email address, then we have a place to send them a magic link in order to sign in.

[Bruce] Is that a one time use link, Adrian?

[Adrian] Well then this is why I wanted to talk to you [unintelligible] because ideally we’re doing another thing, which is the patient does have to have the ability to manage policies--to manage the equivalent of a pico. And we model that as a progressive web app so that they can reuse the management interface as they would a web app that is part of the trustee or you know the pico, but the credentials and their policies that they’re managing are actually not available to the trustee or to the pico except by decryption. In other words they can access the storage where we model encrypted data vault using the CouchDB right now and so we want to store real credentials, verifiable credentials included in the email or text message storage of the individual patient and then once they’ve connected to the web app the first time, then they can use the local storage associated with the web app which typically you can have up to fifty megabytes I think. All of this is described in session 10-H and there’s a sequence diagram in there and on GitHub that describes pretty much everything I’m saying so if people aren’t following me or are curious afterwards, they can just look at 10-H and they'll have a link to our GitHub, but anyway I’ve talked enough but this is what we’re hoping to do and we could use a lot of help but this is how we’re trying to basically hand off from the one-time magic link to the local storage which the progressive web app for a real credential the same way you have a real credential in that case. [Bruce: excellent; that’s a fun idea] And we’re also doing two other things than which were part of my talk which is for one we have web key management system in effect that we get for free because we’re asking the guardian to sign in to Stripe and pay for their pico for their you know trustee monthly and so we store things like encryption keys that I mentioned for the data vault in Stripe as metadata and that’s also where their email is -- we don’t need it anywhere else. So that way, we’re avoiding -- we’re reducing the risk let’s put it that way of running a bunch of trustees. So that and then as I mentioned, that we run CouchDB as a form of encrypted storage to where the pico can’t write it. The picos can only read the policies and the credentials. It can decrypt them of course. But that way we reduce the attack surface for the thing which is in the cloud because only the client itself has the unencrypted version of the credentials and the policies. They won’t actually be in the wallet as I said. If the client has a wallet great but we don’t assume that. But this is all laid out in our session notes. So what’s your reaction to all of that?

[Bruce] That’s very interesting. I’m going to go study it. And right now while I give a chance to Tomislav, Cam, Johannes, Steven. I didn’t see you earlier because of the way I was doing my Zoom session--I thought it was just five or six of us. Someone else jump in with some questions or comments while I look up the link.

[Steven] Adrian, can you put the link to your session

[Adrian] No, I’m driving

[Bruce posts link to Adrian’s session in chat]

[Vic] Bruce, I have a question back to the beginning of your presentation where you’re talking about this sort of pico container kind of model and I’m wondering you know since the picos contain state then do you see them getting down to the component level in an app. A typical web app would have a bunch of components inside that app that all have their own state, and a lot of what you’re doing in React or one of these other things is that you’re managing these components, so I’m wondering how granular you think picos could become?

[Bruce] That’s a really good question, Vic. Thank you. And that’s part of the art and craft of using picos in creating an application. That is to decide where the entity boundaries are. And we in our lab over the years have taken several different positions on that with the different experiments we’ve done. But I think we’ve been happiest with the ones where we went very granular, very fine-grained and when you can identify something then you wrap it in a pico and then have it relate to other picos. I interrupted someone

[Adrian] Oh, I just wanted to mention. I’ve been following picos since pretty much the beginning. We’ve done a lot of work in this direction in trustee and [unintelligible] and that’s why I mentioned we needed a progressive web app in order to manage as a policy management UI in order to manage this granularity. Now what we do which nobody else does including Solid and I don’t think picos is we build around GNAP [unintelligible] and that’s why GNAP is moving away from OAuth--it’s unforgiving, but what we do is to model the relationship around what you guys are calling picos as the relationship between resource servers and authorization servers and the critical thing there is that when you look at something like Solid for example they don’t expose the API that goes between the authorization server and the resource server, you know where they store it and that creates a real limitation because you can only [unintelligible for a long time [Vic: must be in a tunnel]] so what I’m saying is we build on this concept that we started out with that there is a separation -- a standards based separation -- between the resource servers and the authorization server and that applies to the individual that is otherwise the controller of the pico or the trustee and to everybody else that wants to interoperate with them. My observation has been that projects such as Solid with their pods and many others maybe picos which I haven’t kept up with recently, don’t expose that interface and thus they make the same mistake that OAuth makes of assuming that the resource server and the authorization server are under the control of the same entity. And a huge amount of complexity and a lack of scalability and you know everything else happens. But as soon as you adopt the UMA model or the GNAP model then the relationship becomes you know understood. Tractable. Then all you’re left with is how do you design the policy management interface that is the thing that drives the authorization server. And how it relates to requests for access to resources, and you no longer have to put in the apps as part of the bundle as well. You can now just treat apps as just another resource server that has access to data in plain text. So to put it another way our world is divided between two different kinds of resource servers: those that have encrypted data and those we call encrypted data vaults and that’s aligned with what we’re doing in W3C and DIF, and those we call resource servers which are like traditional OAuth resource servers except we’ve moved to GNAP.

[Bruce] Thank you very much for that, Adrian, and thanks for the link. I’m going to read that and learn more about it. Tomislav, I believe that you are also involved with Trinsic? [[Tomislav] Yes, I am] So, I just want to take the opportunity to thank you for the API service that you provide which enabled me to do this.

[Tomislav] Absolutely. My pleasure. Bruce, thank you for being constantly with us through the version of the APIs. It really means a lot, having applications in production especially in the APIs because it helps shape us, you know in the future of the services.

[Bruce] Johannes, Steven, Ian? [pause] Okay, so this session has been recorded and it begins with about fifteen or twenty minute slideshow demonstrating what we have done and then the rest of the recording will be us talking about alternatives and asking questions.

[Adrian] Anybody who wants to help us [unintelligible for some time[Vic: I hope that was with the software and not about them driving … call 911, I’m not sure here]] anybody who wants to help us code any of this kind of stuff in the standards domain …

[Bruce] Understood. Thanks for that invitation

[Vic] Bruce, when you were describing how you were setting up the pico architecture, with all those different HR records, you were saying you were creating a graph. Did you actually use a graph database for that piece, instead of a NoSQL, or is it still NoSQL

[Bruce] That’s a good question, Vic. It’s a trick question, because I consider picos to be very natural graph databases. But they don’t have the kind of tooling support that something that calls itself a graph databases would be expected to have

[Vic} And do you, is it typical with a pico to, you might want to have a graph database running alongside it? To get that extra tooling or reporting, because basically they’re throwing a lot of events into an event stream and then you need a lot of times to report on that event stream, and this was a question that came up for us a lot. It’s like do we add the graph database after the fact, or do we build it with a graph database

[Adrian] Can someone explain how a graph database works in picos and in this context? That would be helpful to me.

[Bruce] A graph database models data as nodes and connections between them. And for that reason, I take the middle road of saying what I have developed as a collection of picos is in fact a graph database. Because each pico contains the state for a particular entity and manages the relationships that it has with other picos. So, it is nodes and edges. And if Beto were still here he could describe his use of picos to satisfy a computer science class assignment to do a graph database. And, I see Michael nodding [Michael: I think Beto actually is here; Beto: yeah, I’m here]

[Adrian] You’re saying that what we’re calling policies of an authorization server is actually a graph and when we design a policy management user experience, that would be captured better with a graph database rather than a NoSQL database like what we’re using with CouchDB.

[Bruce] That’s a good question, Adrian. I would have to know more about the details of the policies themselves and how they’re applied to give you a professional answer. I’m stuck in a particularly strange universe where I liken everything I encounter to picos. I eat, sleep, and breathe picos, so that’s basically all I do.

[Vic] It does sort of start looking that way. Everything sort of looks that way after a while. But it is an interesting question because I think in a graph database, in many ways you’re building the database in order to get the reporting that you want, right? And one of the things with a graph database is that if you basically know where you want to enter the graph database then following the connections becomes super fast and so it allows you to report on these huge datasets that there really is no other easy way to report on.

[Johannes] I’ve gotta jump in here because in a previous life I actually wrote a graph database, so I have some opinions on the subject of graph databases. The thing that I just want to mention is that there is one thing that is very strange to me in identity land. Somehow we are representing a lot of the data that we have with very simple structures. Like name values and stuff like that. But the identity data we have is highly structured. There’s much of a graph than anything you can represent flat. Take for example something as simple as a name. I’m a person and have a name, but that’s not actually true. The name by which I’m called is different on the context: in Germany I will use my doctorate in front of my name which I prevent the Americans from doing, you know my son calls me Dad or sometimes calls me other things, you know so it’s highly relationship based and the natural structure for representing these kinds of things is a graph. Right? You have things and relationships between things and you have depending on how you look at it you have different ways of annotating this. You can color your graphs with various kinds of things. You can have properties. You can have the relationships with different types and constraints and all of that and then I just actually yesterday re-read this paper that Kaliya wrote a little while ago about the various data formats that they were fighting over against which one should be used and thinking you know you’re all missing it. I’m coming down on the JSON LD part but this is not really structured enough yet. It needs to be more structured. So it’s a little bit

[Adrian] Well, let me jump in here, because, [he went quiet] Oh, you can’t hear me? [Vic: you keep dropping out] I’m not moving anymore; I’m sitting still. What I’m saying is, we create -- a lot of people do this -- we create a separate DID for every service relationship that they have. And then, people want to relax that constraint, and either adopt a pseudonymous identity or a de-duplicated identity in many cases. So, there needs to be in our world -- I’m not talking as a private individual -- in the SSI world, there needs to be a language, a way to talk about this relationship, this continuum between starting out relationships with you know what some people used to call link secrets or hierarchical deterministic keys in the blockchain context. So, it sounds to me again like how this is about logging in to the picos, right and identity relationships amongst picos. It seems to me if we could use the kind of stuff you’re talking about, these concepts, to help illuminate the relationships as we travel the DID relying parties that would be really really interesting.

[Vic] Bruce, aren’t you dealing -- this whole thing is kind of -- comes down to, how do you interface between pico-land and non-pico-land? Right? Because if I am represented by a pico, then the login is trivial. But if, for whatever reason, I don’t have a pico or the thing I’m connecting to is not a pico, then you gotta go through all this other stuff to make up the difference. Am I getting that, close? We’re talking about a “pico gateway.”

[Bruce] Yeah, it is true that one pico talking to another pico, they’re talking the same tongue as it were and the interface to the outside world is basically the way as we’ve currently implemented it uses HTTP as a transport layer and so the outside world, and so a pico can publish a web hook somewhere and the outside world can visit that URL to cause an effect in the pico and the pico has the full power of HTTP RESTful API that it can use to act on the world outside of it. We’ve also thought about using email gateways so that pico could receive email and send email and other transport mechanisms. Another thing worth mentioning is that the pico can -- we saw in the demo (those who were able to see it) that we had a pico that represented the collection of all the people in the HR system, each one of them represented by a pico, and it was also a web application, and it was also a relying party (in OAuth terminology) for the login, although the login was by verifiable credentials. Any pico can also become a full-blown Aries agent, and it does that without losing any of its other abilities. Speaking just briefly to any programmers in the group -- no most of them have dropped off -- a pico is the kind of object you always wanted when you were introduced to Java or C++ because it has its own thread of execution -- it doesn’t borrow the thread of the application momentarily, and then pass it off.

[Johannes] By the way, did you ever come across -- years ago, a tool out of Canada -- a tool called ObjecTime? [Bruce, no I never did] You may want to look -- I never knew what happened to them -- it was a start up that came out of a telco, was factored out, and they were creating an object-oriented version of Horel (sp?) state charts and there was a nice tool and eventually they got acquired, then they got all spun up it was so many levels into IBM I think -- I don’t know what happened to the tool but I knew the people very well who did this. The basic structure -- it was a telco kind of thing -- so it was all state machines, but an object-oriented version where you could create new objects with state machines that would communicate with messages, sort of CSP-like. And so, the reason why I bring this up is because that is the ultimate graphical way of describing the content of your picos [Bruce very interesting; do you have a link?] Let me look it up [inserts link: https://en.wikipedia.org/wiki/ObjecTime]

[Bruce] And it feels to me like we’re winding down, energetically, so those who have to drop off feel free.

[Adrian] I think we’re just getting started!

[Vic] So, Bruce, once you have the ACA-Pico, you have a pico with an agent in it, a wallet, do you switch all the communications you have happening over DIDComm.

[Bruce] That’s what Phil Windley has planned for the future of picos. Where now they enter into a two-way relationship by exchanging channels [addresses] so each one has a channel to the other, he wants us to morph it so that that connection is a DIDComm connection. [Vic: a peer DID connection] Yeah a peer DID connection based on peer DIDS.

[Vic] Would you find that the overhead then, of having an agent and a wallet, is significant, or does it still make picos very lean?

[Bruce] That’s a good question. I ask that question as well. I’m not sure when it’s going to happen because we’re no longer employing students. We don’t have the wonderful effort of Beto and Michael and their colleagues allowed us to do a lot. We don’t have that kind of manpower any more. So, I don’t know, and I’m going to be doing a stress test soon, and I’m going to be requiring the data for all sixty thousand BYU employees [and students] and we’ll see how well the pico engine holds up to tens of thousands of picos. The last time we did it it seemed to bear up fine. And then the next experiment as you say will be to replace the connections with DIDComm connections and see what that does.

[Adrian] So, the point I could make here is that we spent a year and a half or two as part of the DID standards process as we were getting the standard out trying to figure out for privacy reasons what kind of service endpoints and the reason it’s relevant to this question is because you can build around either service endpoints being messaging endpoints, like DIDComm, or you can build around service endpoints being authorization servers, like GNAP and you don’t really want to build around both because we came to the conclusion that just A) for interoperability reasons, we came to the conclusion that for privacy reasons we only wanted to expose one service endpoint, if any, per DID. And this went on for a long time. This was studied as part of vocabularies and then as part of privacy and a number of other things. So, my religion and I’m not saying I’m right at all -- as with any religion -- my religion is that building around messaging instead of authorization services, is a mistake. It’s not that you can’t do it, but it’s too low level, because the reason for the messages is generally because you gotta pass a request and you’re gonna get back an authorization token of some sort to use somewhere else. You need that level of indirection in order to scale these conversations [Vic: how do you discover?] Probably just another resource server. In the world where I am, where I model the way health records go between clinics, hospitals, insurance companies, and patients’ families, it’s a very diverse universe where people don’t control most of the places that have their health records. You know some of them are controlled by government, you know like MediCare records that we’ve accessed; some of them are controlled by giant corporations where huge, and some of them are individually controlled, like Apple Health or you know individual apps and so in our world, which again is OAuth based, all the resource services are not protected by some identity-based mechanism, they’re protected by OAuth, other than the ones we control where we can use GNAP, but again the world is large out there, and so I’m talking too much, but that’s my conclusion anyway, my religion.

[Bruce] Thank you for sharing that. We’re probably going to go off and learn on our own, and if we come to the same conclusion, then we will regret not becoming one of your adepts.

[Vic] Thank you for your discussion. Always impressed by the creativity of this, and trying to put them into a real world scenario. We’ve got to get you some more students!

[Bruce] Haha! Thank you. Thank you, Johannes, for your suggestions, and Adrian, thank you so much for sharing your wisdom and your religion with us, and thank you Michael and Beto for listening in from Trinsic and for your work there. And thank you Ian and Brent for sitting in