Manu Sporny: Welcome everyone to the March 1st 2022 VC API call our agenda is here on the agenda today we've got just a quick review introductions relevant Community updates then a discussion on the issue. ✪
Manu Sporny: Cryptid sweet configurations on that end point so this is Paul 263 and then after that we have a discussion on Exchange Discovery through Mike Farley's Pole to 68 hold on one second. ✪
Manu Sporny: Well let's see if the transcription is going still yeah the transcriber still going so we'll keep going and then after that we've got issue processing any updates or changes to the agenda anything else that we want to cover today. ✪
Manu Sporny: Okay if not let's go ahead and get started the first topic is the let's see introductions in reintroductions is there anyone knew that would like to introduce themselves or anyone that's been here for a while that would like to reintroduce themselves. ✪
Dave Longley: Yeah so I'm not new I've I just haven't been to many of these calls lately my name is David Longley I'm with digital Bazaar and I've worked on implementations for VC API and various other things over a number of years and worked on a number of Standards over the last decade or so. ✪
Manu Sporny: Great great to have you here Dave let's see well John Henderson have you introduced yourself before. ✪
Manu Sporny: Feel you need to but we always like. ✪
<john_henderson> Sorry, I'm in a bit of a loud location
Manu Sporny: Okay in a lab location well welcome and hopefully we'll be able to hear from you in the coming weeks any other introduction to reintroductions. ✪
<john_henderson> But I'm a software engineer with EnergyWeb working on SSI. Thanks for the welcome
Manu Sporny: And I see John introduced himself by typing something out software engineer with energy web working on SSI great to have you here. ✪
Manu Sporny: The only Community updates I have our we're already stated on the call earlier today the weekly call that is verifiable credentials Charter looks to be on a pretty good trajectory now where I think hoping the close close that up close that Charter work up in the next couple of weeks get that in for a formal vote so please take a look at the VC w. ✪
Manu Sporny: If you have not had a chance to already that is. ✪
Manu Sporny: Available as soon as DNS response here we go. ✪
Manu Sporny: And look at the poll request there a number of outstanding pull requests there and then you know the did formal objections have been handed back over to the w3c director so we're hoping that that will be published the did Cora specification will be published as a w3c standard sooner than later. ✪
Manu Sporny: Okay moving on to our primary topic then this is let's see topic issue or in point crypto sweet configurations I tried to create a succinct title to it but if you look at pole 263 there is a much more kind of involved discussion going on there. ✪
Manu Sporny: So we should just open up Dave you're the one that raised the pr maybe you can do like a quick intro to thoughts on it. ✪
Dave Longley: Sure so I raise this PR in response to sort of looking at our initial design that we had for the VC API going back a couple of years now and it seems like we might have had some of the sort of authority model flipped in the configuration model flipped for how I think the API should work effectively we have a situation where we've created an API where the client. ✪
Dave Longley: Attempt to build some set of parameterised configuration variables they get in they can pick a number of different variables and hope that those work as a valid combination on the issuer Without Really knowing what the issuer can do. ✪
Orie Steele: +1 The API is mostly an http 400 service :) ✪
Dave Longley: Additionally the issuer may not even be able to combine those those those selected parameters in to produce something valid in response so that the the issue itself details some of those gets into some of the details and give some examples of that the other problem with this is the authority model is kind of flipped where instead of having a party that setting up the issuer create a set of valid configurations and then saying client applications you can use these. ✪
Dave Longley: The the model that we have with the API key. ✪
Dave Longley: There's that party to just to just say I've made all my keys and all of my everything available to anyone who has access to this API you combine things however you want to use it and I don't think that that's the right way to approach the problem and I think some of that has come out of trying to optimize the API for building a test Suite that allows us to mix and match a bunch of different features to prove interoperability but that doesn't optimize for real you real world use case and for parties that. ✪
Dave Longley: Clients are able to have access to different keys to issue so that it can limit blast damage and for a variety of other security and privacy reasons and so on so that proposal that PR kind of my original approach was I'm going to start chipping away at the parameters that are available to this API to explain that the client can't really just pick and choose these parameters its problematic and or a responded to that. ✪
<orie> yes, and thank you for that very thoughtful proposal
<orie> I am still digesting it
Dave Longley: Create a larger issue that sort of says instead of chipping away at these one at a time why don't you make a proposal that in a more unified way talks about how we might readjust the API to address the concerns that I put in that PR and that's in I think number 267 is where that proposal is so that's kind of the whole issue that's on the table its kind of re looking at the be Capi trying to understand what we optimized it for with our design originally and whether or not. ✪
Dave Longley: Not that really makes it make sense for real world use case for. ✪
Manu Sporny: All right thanks Dave folks go ahead and throw yourself on the Queue if you've got comments I know that or you've engaged in that discussion I think mood has engaged in that discussion so has Marcus but I don't think he's here today so yeah if you've got thoughts concerns. ✪
Mike Varley: Okay thanks folks can hear me awesome just wanted to also mention that security has already implemented a similar approach on our implementation of the VC API was more geared towards multi-tenancy but when you register an endpoint you do provide some of the parameters that you would want to support as. ✪
Mike Varley: When the API is called those parameters are applied so I think this is approach an approach that secure key would be interested in in fleshing out as described in the issue 267 and we think I think we're aligned but you know we need to explore further but it's something we're already looking at in that entrust blog platform. ✪
Dave Longley: Yeah this this new approach was also designed with multi-tenancy in mind and it also shows some of these concerns also came out of noticing that the existing approach does not work very well for multi-tenancy you've got to try and mount what the the existing API on to the end of some kind of other configuration that allows for multi-tenancy and then you immediately start running into these problems where clients are. ✪
Dave Longley: Four things that they can't actually have or that the issuer can actually do or that if the issuer did do could create privacy problems just as one example that is listed in that PR. ✪
<orie> pretty sure clients can always ask for things that are not supported... thats what http 400 is for.
<dave_longley> not a great client experience though :)
Manu Sporny: All right thanks Dave um I'm gonna go ahead and share my screen because the pr itself that we're looking at is actually quite tiny but again I mean it opened up a huge kind of discussion I think Dave with this PR you're just like remove the verification method you shouldn't be able to set that it should be kind of configured on the endpoint. ✪
<orie> well its pretty good when the API documentation makes it clear.
Manu Sporny: And I think what Mike and Dave are saying is that this is kind of the URL structure that they're expecting in this did come up very early in the BC API discussions I think we said hey look let's not say that this is hard coded that it has to be at the root of your the root of viewer kind of URL path so the root of your domain you should be able to tack the VC API onto the end of stuff. ✪
Manu Sporny: And I think the use case that was brought. ✪
<dave_longley> more comprehensive proposal ^ (but still rough)
Manu Sporny: So I guess what conversation do we want to actually have here do we want to just talk specifically about the pr or do we want to talk about the issue that was created in talk about it more broadly noting that like we should probably try to get to like some kind of concrete action at the end of the discussion. ✪
Orie Steele: So I think the a couple things and then first we support versions of this API with multi-tenancy already and I agree with Dave that the current API definitions make that little awkward and encourage clients to request things that might not be supported so you'll have no I have no objection to the idea that the API should be. ✪
Orie Steele: Refined to support multi-tenancy in a way that's a little bit better than what it is today but I do think in this particular poll request the primary concern is actually did method and crypto sweet agility so I wanted to ask you know in a multi-tenant sort of environment is the idea that an issue or is only ever represented by one did method and one crypto sweet or is it that. ✪
Orie Steele: Presented by one did method but multiple crypto sweets just love to hear more thoughts around did method and crypto sweet agility as they relate to the pull request thanks. ✪
Dave Longley: So I haven't seen a lot of I'm open to from my perspective I'm open to doing a number of ways but my proposal would be to keep it as simple as possible which would be if we're going if we're going to accept that the the party that's configuring this issue or configuring these issuer instances in a multi-tenancy scenario you would have many of these instances that would be configured and in a non multi-tenant scenario you might. ✪
Dave Longley: You might still configure more than one configuration. ✪
<orie> Hearing that issuer would support only 1 did method and only 1 suite.
Dave Longley: Fixed for an on-site install but the the idea that we would have any one configuration support multiple sweets I don't know what the advantage necessarily is there if we're going to go to this model that allows multiple configurations to be created so the idea here is that each configuration would be well thought through only the authority needed to use the configuration would be granted to to that particular instance so the. ✪
Dave Longley: Software would only have access to the keys that it needs to have access to for example to issue VCS there's there's an additional consideration in The Proposal added about json-ld contexts because we didn't really cover anything with that with previous VC API I think in the test in the test Suite in the previous interop work we allowed any context to be loaded off the web at any time and I don't think that's a very good security model and we've talked about that at length. ✪
Dave Longley: Within the various w3c working groups so the. ✪
Dave Longley: Proposal I offered also included the ability to into upload static contexts to these configurations that are created so that you can only issue BCS from any one of these configurations using well-known contexts that are static copies so you don't have to worry about different versions of those changing or you know any sort of attacks and related to that so I think really the model. ✪
Dave Longley: Changing from let the client application do try to pick any configuration some set of parameters instead of things that I think might work and send that and see and hope for the best hope that they get a thumbs up and on the other end have the issuer sort of. ✪
Dave Longley: Decide that it did they make a number of decisions around you know if the client has requested an ed to 5519 signature but the previous status revocation list was using RSA what and I'm issuing a new credential what do I issue the new status list under you know the issuer now has to make these bizarre decisions around that and they might create problems for the client applications that are using those issuers and so there. ✪
Dave Longley: There are a bunch of these these these issues that come up when. ✪
Dave Longley: Start saying well let's let's let the issuer instances have lots of optionality and let the clients pick I think it would be better to be deliberative and say this configuration of this issue will do exactly this it will sign with this did it will use any any did key that matches the sweet because that's usually a requirement of a client application that's a responsibility and requirement of a client application to know these are the sweets I'm going to issue with because that's acceptable for whatever the use cases but it doesn't need to know the specific key that's. ✪
Dave Longley: The issuer instance to be configured and updated and have those keys be rotated as needed but maintain the signature sweet that's expected and required by the client I don't think having the client parameterize that is helpful and I think it makes it a more complicated thing to implement it and creates decisions that where there's not always a great answer in during run time. ✪
<bumblefudge> but i think you're cute and on the queue.
<dave_longley> yeah, terminology isn't great here :)
Orie Steele: Yeah I agree with everything you said Dave I guess just to clarify you know what I'm hearing you say is you could tell the server to create a new issuer and I think there's problems with using the word issue or there because of the conflation with the VC data model concept of this year but let's say looking at your pull request here I asked for a new issue or to be created and. ✪
Orie Steele: And when I asked for the issuer to be created I asked for it to support date web and E2 5519 that's that issuers life from that point on and it if I wanted to use a new sweet I would have to create a new issue or if I wanted to use a new did I would have to create a new issuer is that consistent with what you're saying. ✪
Dave Longley: Yeah that's the model that I think is easier to understand and eliminates a lot of these decisions that are fraught with problems it pushes decisions up front that can be made at the time that you create the issuer so you can make some saying decisions around what configurations make sense how to make sure that the Privacy model makes sense for your revocation lists and so on so yes to what you said. ✪
<bumblefudge> maybe issuer SERVICE?
Manu Sporny: All right I put myself on the Queue I'm wondering I'm wondering if the word is sure this is just a tiny nitpick on language but I think issuer might be misleading people it might be better as instance we're talking about setting up instances you know here with very specific configurations I think maybe when people see issuer here they think like of a single subject or a single entity. ✪
<dave_longley> "issuer instance" and "verifier instance" terminology was used in the proposal i linked to
<bumblefudge> paging Joe
Manu Sporny: City in that's probably not the right mental model here I don't know how we make it better but I just wanted to make sure that folks weren't getting wrapped around that particular axle. ✪
Orie Steele: So one of the I think potential sort of problems that related to this is the scheme is for requesting a credential be issued so we're looking at the URL for the issuance and point here but the post body has a schema and that schema is a verifiable Prudential without a proof and some options and one of the things that's difficult there is like does your post body contain an. ✪
Orie Steele: As I you know I want you to issue a credential and I want it to have an issuer block that's an object with type organization corporate website blah blah blah then the issuer endpoint needs to inject the issue or ID into that object or it needs to throw an error and say sorry 400 error but the issuer has to be a string and can't be an object so I think one of the sort of key. ✪
Orie Steele: If an issue or instance or an instance of the issue or API is configured for just one did and just one key associated with it potentially when you're asking for a credential to be issued what are the constraints on the schema that you're submitting for that credential so like for example if you were to include a status list in that credential object right then and there you're going to already have a. ✪
Orie Steele: Point two is under a different Suite so you need to throw a 400 error if somebody asks for a credential to be issued under any status list you probably need to throw a 400 error if the client asked for any issuer to be present in that payload so I was wondering Dave if you could just sort of speak to some of the schema changes that would have to go along with this URL change that you're proposing thanks. ✪
Manu Sporny: Mahmood you're on the Queue and then Dave. ✪
Mahmoud Alkhraishi: I think Dave answering first and then I should go after. ✪
Dave Longley: Yeah I agree that there might need to be schema changes this to some extent this is not that different from what we were doing before if if there are if there was an issue or that you could not issue from before and you put that into the VC and the payload and sent that to an issuer it would also still need to be flagged and checked so I agree that there are schema things that need to be changed and they might be more specifically tailored to a particular. ✪
<orie> yes, we throw a lot of 400 errors today.
Dave Longley: To some extent that's not that different from what's Happening Now but there would potentially be some some differences certainly if you had posted a credential status to the existing API today and that was not supported by the issue on the other side you would still be in the same situation you that would have to be dealt with so I see that it is an issue that needs to be addressed but I don't I see it as somewhat orthogonal to the to the issue of sort of doing configuration first. ✪
Manu Sporny: All right thanks in Mahmood you're next. ✪
Manu Sporny: Yep you are here and you want to go to the bottom your comment. ✪
Mahmoud Alkhraishi: Would you mind going back to the pr the there were three points that they have you made it sort of your argument right the first one basically is if you need to rotate Keys then under the current model you to notify everybody that originally was rotated the second model is if you have a credential of one sweet type. ✪
Mahmoud Alkhraishi: And their vacation is have a different Suite. ✪
Mahmoud Alkhraishi: Then you will run into problems with issuing the revocation list and every time your new one will be an issue and the last one is the key the fact that this whole idea should have been done by the shore in the first place around the client having to figure that out right is that really what you're saying. ✪
Mahmoud Alkhraishi: So my first question is can't this have just been solved by extracting out the requirement for including a key in the current request additional credentials so if we remove if we instead say if so sorry man you can go all the way down to the to my comment. ✪
<orie> yes, verificationMethod is optional today.
Mahmoud Alkhraishi: So in the existing one that we have right now which is the first liquid that we have we say the verification method is this D ID and then it has this key behind right and that is an optional request if we remove that instead we say we would like you to issue a potential of this type from this D ID and then the idea that you're using would be resolved. ✪
Mahmoud Alkhraishi: And you'd find out which key and here's that type of. ✪
<orie> this removing an optional field, and implying that the key will be set by the server.
Mahmoud Alkhraishi: Just issue it that way you would solve the rotate kids problem completely is that an accurate statement or. ✪
Dave Longley: Yeah I do have more to say in responsive when you're ready. ✪
Mahmoud Alkhraishi: So my question is I think your biggest response to this on from what I've seen from what you've written is basically we don't even need to go there in the first place instead of just if we do it by the config it would be better I just don't I don't know where or why is it better than than what is currently here that's basically right. ✪
Dave Longley: Sure and that makes a lot of sense so some of this sort of speaks to two or he's complaint with my with my original approach here which was my original approach was to point out you know if we just remove verification method we can solve some of these problems and I think Corey was responding and thinking well if you're going to start there there might be other problems and if we go down the path of trying to pick the solving each one of these one at a time and take the shotgun approach its it could be problematic. ✪
Dave Longley: And you know we're going to spin our Wheels a lot trying to solve. ✪
Dave Longley: And either we would end up with even more problems with the solve eventually or will just wind up somewhere where we could have started from and the main point is we've got some kind of design flow here where we're going in the wrong direction where hat where we have the responsibilities mixed up we're having the client be responsible for things that the client shouldn't be responsible for and if we turn that on its head and say the parties that are setting up and configuring these issues with the parties that know. ✪
Dave Longley: What configurations are wholesome and sort of work together then they can make those configurations available that doesn't mean that you know they wouldn't be working in concert with particular Client app providers so you know or whoever depending on the use case to say you know we want to make sure we have a configuration that has this signature sweet for example but the authority is is flows from the party that has access to the Keys and then has access to. ✪
Dave Longley: That they can provide for revocation and so on and so forth and those configuration should be determined by those parties and made available to client applications and if we if we flip it on its head and go in that direction we will avoid the problems that are raised in this PR and additional problems that have not necessarily been raised directly in any other PR but stem from the same sort of inversion of responsibilities issue that we have. ✪
Dave Longley: Where the client does not have the knowledge that. ✪
Dave Longley: Able to make these decisions around what configurations are available because the authority doesn't flow from the client it's the party that has access to the Keys and can say this is what I can issue these are the sweets I can issue from and so on it flows in the other direction. ✪
Manu Sporny: All right thanks Dave Mahmoud I think that might be an old Q is that right. ✪
Mahmoud Alkhraishi: Yeah check that out think I'm okay. ✪
<orie> if we are gonna cut, we should try and cut holistically towards a shared vision.
Manu Sporny: So I guess the I mean I understand the concept right I guess the question is where does where's the line where does it how do you reconcile things that the client asked for and things that are kind of hard configurations on the server so for example let's say revocation list right so when you ask for a credential to be issued. ✪
Manu Sporny: You're like no no I'm managing the revocation stuff over somewhere else and I'm going to I'm going to specifically State you know the that I want to use revocation list 2020 or you know 2021 I guess what we're saying is that if that is configured server side there's an option there that says allow the client to override or never allow the client to override and always use like status. ✪
Manu Sporny: Is is that what we're saying because they're all these different options that could potentially be mix-ins and I think what we're saying is like know that issuers got to set a whole bunch of defaults and then the issuer the person configuring the issuer instance has to set a whole bunch of defaults in they may allow those defaults to be overwritten or they may not. ✪
Orie Steele: So I'm going to try and answer the question I think for this to be successful the schema for the payload the post body becomes much more strict it says you know hey you know credential status it can't be present because that's going to be set by the server so like don't you could you might say hey if you are like sometimes I ask for credentials with revocation and sometimes they don't so credential status as an option I think it's fine. ✪
Orie Steele: Actual post body credential status would be forbidden because the server is going to provide that value like their server is going to provide the issuance date and the server is going to provide the issuer should the client be able to ask for a backdated issue and state maybe but I think the point being that if you take this approach the schema for the post body becomes much more restrictive you throw a lot of a lot more 400 errors saying hey. ✪
Orie Steele: Client you know servers already going to handle. ✪
Orie Steele: Parameter like you're not allowed to specify it and that's everything becomes a lot clearer so I think it it is a. ✪
Orie Steele: Valid direction to take the API but it does sort of change the world view a little bit to the server sort of being the authority and the client not being able to really ask for anything other than what the server is going to going to accept and I think it's a valid path forward but we should make sure that we're communicating Our intention to implement that shared Vision very explicitly and we're taking. ✪
Orie Steele: It take us that direction at once if we can just so that we get there a little bit faster and so everyone knows like this is a fork in the road and design principles like we're now going the direction of the server is going to be responsible for this configuration the client is not going to be allowed to ask for any form of optionality the clients going to accept what the server will give. ✪
Manu Sporny: Okay that's helpful at least it was helpful to me Mahmoud Europe. ✪
Mike Varley: +1 To Orie's comments on making the input schema more strict. ✪
Mahmoud Alkhraishi: I think what I got from reading the issue is that when I think there's a missing endpoint which is a get on trying to find out what are all the issue where's that are available somewhere here so that I can know if I want to issue a credential of a specific the ID which endpoint on my calling in the first place but I feel like that's you know that's a very straightforward fix right but what I'm trying to understand is. ✪
Mahmoud Alkhraishi: Server says there are four possible valid configurations and only four possible about configurations if you want a credential issued by me these configurations are for example eat 519 2018 with a revocation of 2020 or a is 509 2020 with a revocation list 2020 and that's it we don't support other stuff right and the and then obviously there's a way for you to ask the issuer from what I'm seeing in your proposal to add in. ✪
Mahmoud Alkhraishi: Another configuration object that's the rough. ✪
Mahmoud Alkhraishi: Only hope is internalizing that correct first of all. ✪
Mahmoud Alkhraishi: Okay so I'm failing to see how. ✪
Mahmoud Alkhraishi: How a client is able to find out that it's supposed to call this and point to get that credential that like I'm trying to for example I want to issue a revocable credential with a with a specific key type with a specific from a specific the ID if I had if I support like for did methods doing it a different issue or end point for each one and then do I need a different revocation list. ✪
Mahmoud Alkhraishi: For you like it feels like now. ✪
Mahmoud Alkhraishi: I've gotten more issue and points than I had in the beginning. ✪
Mahmoud Alkhraishi: That's really where my confusions. ✪
<orie> you can't ask for a specific did or quite... you can only as a specific endpoint for a credential.
<orie> suite*
Dave Longley: Yeah so the quick answer is yes you do have more configuration and points than you did in the beginning you have one for each type of configuration that the client applicate that the issuer wants to support in that the client application needs to use and and this some of your questions seem to to remind me of the just some of the discussions we've had around Discovery very often we said you know how our clients going to discover these things that they need to do it's actually and what we found in a lot of those scenarios is. ✪
Dave Longley: Action so a lot of these use cases are you're going to go through some setup bootstrapping process where you can configure an issuer URL is going to pop out and you going to take that URL and put it in your client and that's going to be end of the story as opposed to a client that rent is randomly showing up at some issuing and point and is asking some questions about what it can issue and what it can that doesn't make sense because the problem I'm going to have the authority to do that the clients going to be specifically provisioned and given Authority through either. ✪
Dave Longley: Are you off to or Z Caps or whatever authorization mechanism is being handed to that client to be able to. ✪
<orie> hmm -1 to most of this attempt to avoid discovery
<orie> you still need to address it
Dave Longley: Civic issuing endpoint so it's going to have that knowledge through the process of being on boarded and so I don't know that we even need to have any sort of Discovery mechanism because I think the use cases are such that you need to get that Authority and then you going to be told where to go use it and I think that answers your question so I'll let other people in the cute. ✪
Manu Sporny: All right I put myself on the Queue to try and get us to drive towards a concrete kind of outcome here one thing that I think could potentially work is a PR explaining this new philosophy and a bit more depth so not necessarily changing a mean it could change API endpoints but as as we saw you know this tiny little change has kicked off a pretty big kind of philosophical Direction. ✪
<mahmoud_alkhraishi> the issue has really in-depth stuff i just didnt go through it before this call
<orie> pretty sure I am the only person who reviewed the PR... so I don't know that we need to ask for anything but more reviews.
Manu Sporny: And so I think we probably need some text in here to explain that these endpoints do have configurations associated with them and they do X and Y and you know the Dynamics between the client and the server needs to be written down so I'm suggesting that as a next next concrete Next Step here or you're on the queue. ✪
Orie Steele: So I think it's fine to to continue to iterate on this PR and like Dave has given answers in issues I think you know folks should review the pull request and we could can make incremental progress or we can make you know we could push a design document and then try and change the apis I'm fine incrementally changing things as long as I know where they're headed. ✪
Orie Steele: Modifying my change request to more specific issues that I think aligned with Dave's Vision the point I'd like to make about the discovery thing is you can't get away from discovering the features an issue or supports so if a client wants to ask the server hey issue or one two three what did method is that going to use what sweet is it going to use it shouldn't have to ask for a credential to learn the answer you. ✪
Dave Longley: +1 To Orie, that's discovery at a different layer (i think) ✪
Orie Steele: From asking the API what did method does issuer 123 support and what sweet might it support does it support revocation does it not so this idea that like somehow will avoid Discovery by configuring clients it's it's definitely not going to work like we will have to make get and points and add them to these apis we can't just have it be a collection of post and points that's not a good API design but. ✪
Orie Steele: You know that maybe Discovery is sort of more resource oriented like which fig configuration does this particular instance resource support and and that that makes like a lot of sense and that's why I like I think it's really helpful at Davis done you know he's explained yes you know I want to take you know I want to chip away at these issues but I also have kind of a boring grander vision for major structural changes to the API and. ✪
Orie Steele: And you know with that being said I think folks. ✪
Orie Steele: All requests and they can request changes or approve 8 based on what it's got and what Dave has communicated. ✪
Manu Sporny: Thanks Horry I'm gonna let's timebox this at my mood and then move on to the next issue just so we can get this other idea in people's heads as well Joe you're up. ✪
Joe Andrieu: Yeah I think you can hear me okay couple things I think I think we're sometimes talking past each other because we're we stopped using the language of apps relative to the services often when I hear people talk about clients and the need for discovery that to me speaks to the end user who is trying to get the credentials issued they don't have any appropriate role. ✪
Joe Andrieu: An app controller who is trying to integrate their app with a service wanting to know for a particular configured and point what's the configuration of that so when Orie reframe Discovery in that context that that made sense to me but for that end user in the clients I just keep getting wrapped up in Discovery language when you talk about the client and the way that we haven't. ✪
Mahmoud Alkhraishi: I think my question was basically one I agree with the big picture vision of we absolutely need to agree on a lot of the things here and I'm happy to like have that discussion as we go but there is a question of a very very quick win when it comes to the key rotations and it's just removed the requirement in the my Venture for textual hard requirement right now if the revocation method has a requirement on the key. ✪
Mahmoud Alkhraishi: But I feel like it shouldn't specify which kid. ✪
Mahmoud Alkhraishi: First place if you would just ask issue something from this D ID instead that we have the you know very straightforward and I don't think would be big like will see a lot of objections when that we can have keeping in mind that there's a much bigger picture here about you know all the rest of it needs to be. ✪
<manu_sporny> Feel like it's a stop-gap and still "wrong" in some way.
<orie> agreed
Dave Longley: II do agree that we could one-by-one start shipping these options out and start with the one that was mentioned but it you know there are other approaches people have mentioned I do I got on the cute though to respond to Horry and Joe I agree that we're there's some miscommunication around what the meaning of Discovery is and once or he started talking about finding out the configuration information from a particular. ✪
Dave Longley: URL you already know about I completely agree with Oreo. ✪
Dave Longley: That is not what I meant by Discovery I meant having to discover these URLs that you were supposed to have access to in the first place but being able to find out from a URL that from a particular configuration what is your configuration tell me you know tell me the information about this URL I completely agree that you should be able to do that. ✪
<orie> OIDC does discovery very well :)
Manu Sporny: All right um noting that we only have 15 minutes left in the coal go ahead Mahmud I'm going to move us on to the next issue my my assumption here is that someone Dave you're going to write up some thoughts on that we can add to the spec on this. ✪
<orie> dave just implement my change suggestions and I will approve your PR :)
Dave Longley: I'm just a jump cue real quick maybe I don't I don't know I don't know where to add that or what would be that part I was a little confused about going in the direction of chipping away or changing the API to some making some statement somewhere. ✪
<orie> don't bother writing anything other than PRs or issues :0
<orie> ; )
Mahmoud Alkhraishi: I think I'm going to jump back in here I think the issue that you made had a very very like I didn't have a hose on it but it was a pretty clear proposal where we want to go and I think what we need next is reactions to that issue right where people respond to it because I think there's a Clear Vision there. ✪
Dave Longley: Okay I'm also seeing a chat or he just wants his change I'll look at his change suggestion and we'll work through it there. ✪
Manu Sporny: Okay all right moving on to the next topic so. ✪
Manu Sporny: Let's see so at a minimum we'll see if Dave you can address or ease concerns and if so then we can modify the pr Mahmud I'd be interested in seeing you know what you think of the modification and then we may want to further document kind of some of the design philosophy around configuration for endpoints and Discovery there was some good stuff said on the call today all right. ✪
Manu Sporny: Is about Discovery exchange Discovery Mike Varley wrote up PR 268 so that's in chat here and I'll bring it up here Mike would you like to give us kind of a quick intro to this PR. ✪
Mike Varley: Sure so this PR was requested based on the exchanges Discovery where the VC API supports workflows or exchanges and there was some language in that proposal around exchanges that. ✪
Mike Varley: Did that exchanges could accept a wide variety of input parameters and and output VPR responses which could lead to other protocols and I was concerned that that kind of approach might make it difficult for software clients trying to. ✪
Mike Varley: And you know what what protocol am I supposed to speak to this exchange with there's input parameters expected how do I know what those are and so on so this PR is a get on the exchanges and point which returns a map of the pathnames essentially and and then a. ✪
Mike Varley: The Kate's you know a spec that that endpoint is going to utilize its deliberately probably over simplified it's it's very direct and sort of its intention that's to sort of spurn spurned discussion and see where we want to put guard rails on this or or maybe if we even need it the. ✪
Mike Varley: Point is also that I was not constrained to just VPR related protocols but also you know is there room to indicate that this endpoint uses something like presentation exchange or is there an open ID connect relationship or or you know just an open the spec lives in in a custom defined yambol file and you're expected to go and. ✪
Mike Varley: Already sort of understand what that protocol is so this discovery and point is for the client to call understand for this exchange endpoint what is the protocol that I will be using and do I recognize that string in order to fulfill that communication if it if the client does not recognize that string then it can handle that with with the end user saying okay I'm sorry you know this issue actually I'm not compatible with in some way. ✪
Mike Varley: And and to Joe's point from a developer point of view it can also be useful for you know if I'm going to be building a client and I want to interact with an issuer system that's using this API well I can call the exchanges and point see what the protocol specification is and then code against it and then there's less maybe fewer touch points with the actual owner of the issuer service API on on how their exchanges work. ✪
Joe Andrieu: Yeah my question for you might is is this exchanges family of routes which component is it on is this on the issuer app or the issue or service or my misunderstanding something. ✪
Manu Sporny: I can I can answer that so it's it can be on anything so you and exchanges can be on an issue or app a verifier app or a holder app it just is a general way to kick off you know presentation exchange like exchanges or just you know presentation exchanging. ✪
Manu Sporny: Presentation back the sides of things did that answer your question Joe or were you asking a different question. ✪
Joe Andrieu: I'm if I maybe it was it's one of the apps but not the services. ✪
Manu Sporny: Correct I believe yeah I believe that's correct Joe. ✪
Mike Varley: Man I would agree yeah I think it's on the app side. ✪
Joe Andrieu: Okay cool I think part of my is just figuring out how we start to integrate that terminology into our docks because I don't think we've fully gotten that language in. ✪
Manu Sporny: Let's seize on the Queue keeps debut on the Queue go ahead. ✪
Dave Longley: Yeah I was going to say there's there's there's more analogies here to draw with the previous conversation we had and we might want to start talking some of that previous conversation was about there's just going to be State associated with these issuers and verifier instances you know we need to figure out our naming terminal to terminology are but there's some State you know like you need to store contexts we need to store act the capability to use certain keys and we might have the same thing going on here with exchangers or. ✪
Dave Longley: We need some term here where you would create one of these configurations this exchanger thing and upload a set of steps with combinations of vpr's or whatever and in the in the expected in some kind of expected schemas for what gets posted back in response to these things and so we might want to be able to create these instances in the same way that we're talking about creating instances of verifiers and an issuer's so the same. ✪
Dave Longley: And we could we could potentially reuse that. ✪
<orie> how restful...everything is a resource.
Manu Sporny: What's the wonder that I did have a couple of comments on this Mike I don't know I don't know how relevant they are because I can't remember what I said. ✪
Manu Sporny: Um some of this stuff look like it kind of mapped so there's some part of this that maps to VPR right so VPR tells you here ways that you can interact so verifiable presentation the VP requests back has this interact. ✪
Manu Sporny: Part right to the map inspired interact thing where it says here's the protocol that you talk to and here's the endpoint right in these are typically exchange endpoints or they can be viewed as exchange and points but this is just in the BP R-Spec I think Mike what you're saying is bring it a layer up to the BC API spec and put that directly on exchanges and Dave saying well maybe we can you know Express this configuration. ✪
Manu Sporny: Duration information in the same way across. ✪
Manu Sporny: Issuer instances and exchanger instances and verifier instances and in that kind of thing so I think there's the other the other thing of course is that the did spec has this service you know container thing that we could that we should also think about so they so this is this kind of thing is happening in at least three different specs already and we should just be aware of that. ✪
<bumblefudge> service block wildly divergent across specs tho :(
Manu Sporny: You think that's it the other the other question I had Mike was that when I started trying to think about the use case. ✪
<bumblefudge> sometimes a string, sometimes a huge object, sometimes an exactly-two-prop object...
<orie> yeah, many did methods do not support service blocks
<bumblefudge> also
<orie> a major reason to use did:web !
Manu Sporny: I couldn't think about where this fits in like I don't understand and I'm not trying to be like you note right here the I don't understand the use case my expectation was that at least with the VP are sorry with let's let's look at credential refresh the discovery for the endpoint that you go and do a credential Refresh on at least in the VC refresh 2021 Speck that is in the VC itself so you do Discovery through the Visa. ✪
Manu Sporny: I'm wondering what the use case here is do people just randomly hit the exchanges endpoint and then they're then then they get to see like information about credentials that they could get is that the use case here. ✪
<bumblefudge> sounds like a credential manifest use-case ��
<bumblefudge> (ducks)
Mike Varley: Yeah okay so for to your first question around structure I think that there are options on structure I'm not married to to the current you know proposal so if you wanted to add in some json-ld context or whatever and and create a structure instead of string you know we'd be open to that the intention though is not to have the specification as part of the discovery it is it is meant to say on this. ✪
Mike Varley: End point I am going you know this. ✪
<dave_longley> (these service blocks, for example ... are not in DID docs, so +1)
Mike Varley: Used it to string you should recognize that and and then that's how you know that your communication with this endpoint is is going to is going to be successful other other other you know if we put I'm worried that if we try to put too much of this spec into the discovery then your client has to become very clever in parsing all of that and deciding what to do so anyway like I said it's kind of deliberately simple and like try and keep. ✪
Mike Varley: As for the use case what really I guess inspired me to to address the discovery issue was on the pr for exchanges there's this disrespect allows for any Json object to be provided as input parameters and then that results in a thinking of epr and and it was digital as ours. ✪
Mike Varley: That you know they may have or they will you do have use cases where input parameters are required just in order to kick off the flow and men and maybe you can talk about that that use case my concern is that as a client if I'm going to you know whatever the name of that end point is if it has a generic name if I'm if I'm expected to add additional parameters to this exchange and point which I thought was for credential refresh but now says I can't deal with you because you actually. ✪
Mike Varley: Some input parameters before we started credential refresh then you can have clients in the wild which which think they're going to be able to work and they and they and they contact a credential refresh in point and then suddenly they don't so you know what the client supposed to do in that in that scenario so that's that's the area in front of address if the we want to have some flexibility in terms of how exchanges get kicked off or. ✪
Mike Varley: Or how or the protocols used on those. ✪
Mike Varley: I think I feel strongly that the client should be able to at least find out what is necessary for that communication to be successful before actually kicking it off and so that's that's the use case. ✪
<orie> no free lunch clients should be able to discover how to make valid requests and avoid needing to trigger 400's to learn
Manu Sporny: Okay great thanks Mike and with that we are at the top of the hour thank you everyone that was a great discussion today I think the next step on this one I think is more discussion Mike on the on the pr in maybe if someone could take a cut at a unified way of expressing these configuration on these end points like we are you know instance configuration for issue. ✪
Manu Sporny: That might help us think through this you know in a more kind of unified way okay that's it for the call today thanks to turn everyone see you in PRS and issues have a good one bye. ✪