Closed OR13 closed 2 years ago
David-Chadwick
commented
3 years ago @OR13 wrote "An enterprise grade API for multivendor http based verifiable credential interoperability" This is what I have been working on in the eSSIF project. When you do this, you cannot evade the fact that policies are essential, and that any request to the holder to create a VP must be to satisfy the SP's policy. Otherwise the VP is not fit for purpose.
Therecanbeonlyone1969
commented
3 years ago @OR13 ... Spherity is strngly supporting your statements. Our focus is squarely on Nr. 3. The APIs need to follow a widely adopted standard such as OpenAPI 3.0 etc., needs documented and testable support for common authentication and authorization frameworks, and relevant tests that are readily reproducible by implementers ...
One more thing. IMHO, it is perfectly acceptable that not everyone supports every implementation option if it does not align with their business priority. It is also crucial that adding alternate communication protocols for the API is not held up as long as they are supported somewhere by someone and a test suite is contributed.
mprorock
commented
3 years ago mesur.io shares all 4 of the concerns and goals outlined by @OR13
msporny
commented
3 years ago
- It must not invent or use custom authentication or authorization schemes
- It must scale horizontally
- It must be exquisitely documented
- It must have the features that developers need.
Those are "Motherhood and apple pie" requirements. You're not identifying the points of contention, so all you're gong to get is a whole bunch of "+1's, we love it!" (as evidenced by the responses so far). That's not going to get us very far (other than feeling good about ourselves). I get that you're frustrated with the rate of progress. I think all of us are frustrated, for different reasons.
many folks who contributed to this work item do not agree on its scope, and consider enterprise grade http APIs for verifiable credentials to be "secret sauce"...
Can you name names? I'd be shocked if anyone here was against "Enterprise Grade HTTP APIs". Again, identify the points of contention, raise them as issues... don't raise vague issues with vague requirements. You kinda sorta start getting to the actual issues in each one of your explanations... but things need to get far more concrete, faster, so that we can actually have a focused discussion around a feature.
I think we may be reaching a point where the work item needs to be split up.
All that's going to achieve is enable a subset of us to go off into a corner and work on something, only to return to the larger group and find that what you created might not resonate with the larger cohort (and will therefore be at risk for being standardized). Do the hard work up front... it'll save all of us a lot of headache.
I'm sure everyone is frustrated with the pace and type of work on the VC HTTP API -- some of us have higher priorities being pushed by customer needs... but taking your ball and going off into a corner is not going to speed things up... it's just going to delay the important discussions that need to happen.
I suggest breaking down the new API endpoints you want, prioritizing them, and then asking the rest of the group where their priorities are. If the rest of the group disagrees with your priorities, you can go off into a corner and work on your thing until the group realizes that you were right... and then you'll have something ready to go (that may still get rejected by the larger group).
This is how JSON-LD, VCs, EDVs, and zcaps came to be -- all of those things were initially failed attempts at convincing a community, and were proprietary secret-sauce, until the community got to the point where they understood each technologies usefulness... It took 4 years for JSON-LD, 4 years for VCs, 3 years for EDVs, and 4 years for zcaps. However, we never stopped engaging the community. The jury is still out on CBOR-LD and WebKMS -- people tend to not pay attention until the problem hits them in the face and then they desperately look around for a solution. We built stuff out, spent years arguing, and eventually compromised with the larger community to make sure everyone's perspective was being taken into account... so that when the time came, we had something ready that already had some modicum of community buy-in.
So instead of proposing "motherhood and apple pie" requirements, or suggesting that a small subset of us should go off into a corner and work w/o engaging the broader community... do the hard work up front. Make a concrete proposal, drive consensus around it, achieve difficult compromises to make the feature mandatory... it's one of the best paths to true interoperability.
I suggest you close this issue and open new ones:
Keep the issues specific and concrete... you'll get better engagement. Also, don't be surprised if some of us don't have the same priorities that you do -- we're all very busy, and not all of our contracts had adding new features to the VC HTTP API as a deliverable this time around.
mprorock
commented
3 years ago Some great points raised by @msporny. In relation to the following
2. Suggest a very specific design for a batch issuing API or a batch verifying API -- expect strong push back until you provide numbers you want to achieve. Don't be surprised if a vendor claims that they can hit those numbers because they've figured out how to horizontally scale their architecture.
I don't at least, think of this as related to horizontal scaling per say (we are huge advocates of horizontal scaling), e.g. in terms of compute and the number of requests that can be handled in parallel, but in terms of number of network requests for certain use cases and the other impacts from scaling horizontally that higher numbers of requests can lead to, especially on a cost perspective.
Let's take a look at one segment of this, as exemplary of other services and cost impacts through the chain with different approaches to volume of requests. In this case, I am going to isolate out costs at the API gateway layer.
Scenario 1: 100m requests per month, with an average request size of 10KB Per the latest AWS cost calculator, this implies a cost of $100 / month just for the API gateway 10 KB per request / 512 KB request increment = 0.01953125 request(s) RoundUp (0.01953125) = 1 billable request(s) 100 requests per month x 1,000,000 unit multiplier x 1 billable request(s) = 100,000,000 total billable request(s) Tiered price for: 100000000 requests 100000000 requests x 0.0000010000 USD = 100.00 USD Total tier cost = 100.0000 USD (HTTP API requests) HTTP API request cost (monthly): 100.00 USD
Scenario 2: 10m requests per month, with an average request size of 100KB Per the lastest AWS cost calculator, this implies a cost of $10 / month at the API gateway 100 KB per request / 512 KB request increment = 0.1953125 request(s) RoundUp (0.1953125) = 1 billable request(s) 10 requests per month x 1,000,000 unit multiplier x 1 billable request(s) = 10,000,000 total billable request(s) Tiered price for: 10000000 requests 10000000 requests x 0.0000010000 USD = 10.00 USD Total tier cost = 10.0000 USD (HTTP API requests) HTTP API request cost (monthly): 10.00 USD
That is a 10x cost difference, that stacks when you look at transactions across other aspects where the number of network connections themselves incur cost, which is certainly the case for most cloud hosted architectures we are dealing with, and this is compounded by cross region / cross zone costs when we look at replication and geographic fault tolerance. For instance, we, even as a relatively small startup, still have customers that need full data replication between US / Southeast Asia / Europe for the data we deal with, and bulking that replication (with a certain amount of acceptable lag) has significant cost impacts for us.
Some of the situations we, and I believe @OR13 have in mind, also think in terms of minimizing total network overhead on requests, etc. and there are areas where compression on network requests (especially in the case of items like JSON that have large amounts or easily compressed elements) can have significant volume and cost impact when looking at a many (where appropriate) vs one scenario that deals with the same amount of data transfer (informationally) over the network.
@msporny Does that help bring some light onto things that are at least in my frame of reference when looking at the overall API design, both here, and in other aspects of our platform?
msporny
commented
3 years ago @msporny Does that help bring some light onto things that are at least in my frame of reference when looking at the overall API design, both here, and in other aspects of our platform?
Yes, and thank you for taking the time to do the cost breakdown. We deal with and have similar concerns. I get the 10x cost difference, but the scale matters here.
Let's assume Scenario 1 -- that you're issuing 100m VCs/month -- and that costs you... $100 vs $10. You're worried about $90/month in costs for 100M VCs issued? Your business model doesn't enable you to recoup $90 from your customers? What am I missing?
mprorock
commented
3 years ago Let's assume Scenario 1 -- that you're issuing 100m VCs/month -- and that costs you... $100 vs $10. You're worried about $90/month in costs for 100M VCs issued? Your business model doesn't enable you to recoup $90 from your customers? What am I missing?
Thinking from "investor/evil capitalist/business" hat, I am going to try and charge (if the market will bear it) that extra $90 and still have only $10 of cost, and reinvest that back into the company.
edit to note: and bc it is a "free market" if i can't go down in price for certain customers who require lowest possible cost, e.g. govt, etc. some one else will offer something that does exactly that, but then does this one thing more that eases that cost burden. then we wind up with folks breaking out into their own specs etc and we are back where we started with no unified spec end edit note here
That however, is just looking at "our" cost as a provider though, there is also the IT pushback from the customer side on the cost and network overhead from the additional volume and frequency of network calls in and out of their data centers (less considered on actual volume of data, thought that can factor in). Then they look at "oh great, one more service" to deal with high frequency and rate of net requests on top of all the others on top of the SOC audits and pen tests to mange, etc etc. Anything that lowers friction by letting them deal with big chunks (maybe just at onboarding, maybe at periodic expected points throughout their business calendar, maybe every day) of data the same way they do with smaller more normal scenarios without resorting to ad hoc s3 bucket imports and file exchanges to keep track of is way way preferable.
Look to the success of folks like twilio and snowflake for examples of how allowing this kindof thing on the technical side has greatly lessened friction in the sales process, and enabled rapid enterprise expansion without IT getting too much "in the way" because it meets their needs as well as the business side.
OR13
commented
3 years ago @mprorock has accurately captured my concern with this API... it feels like an attempt to make a standard that demonstrates interoperability while not being efficient enough to implement at scale....
sort of akin to a reference implementation that is written for readability / comprehension, but that does not cover all the required features and is not suitable for production use.
building great APIs is hard work.
we can get "there" from "here" but not without consensus that its "in scope" and if its not, we should agree to do that work elsewhere.
msporny
commented
2 years ago We discussed this on the 2022-01-18 telecon. @mprorock provided an update -- part of issue was addressing lots of VCs over the wire in a way that is efficient. Workflows address some of the issues here. Breaking API out into microservices also helped. Headed in the right direction. We need to continue to be mindful of all of the workflows, but might be able to close this. We need to be mindful of scalable systems, follow best practices, avoid reinventing the wheel, etc.
We would need to know if @OR13 would be ok with closing this issue, or could he raise more specific issues for anything that's remaining.
When this work item was first proposed, the goal was to support a VC API over HTTP... that could handle things like:
We soon learned that its pretty hard to verify a presentation if you don't have an easy way of creating one, so we added:
Now we have proposals to add support for
deriveProoffor BBS+ ZKPs.. which is akin to "create verifiable presentation" in that it's a "holder" api.There are open discussions regarding the best way to "scale the http api"... should we support batch issuance and verification.... No substantive progress has been made on this front.
There are open discussions regarding authorization, and thanks to @tplooker for his PR #89 which showed how to support OAuth.
However, other than #89 and #92 we have seen essentially no progress on this spec since the last plugfest.
We still don't have tests that show support for multiple suites or demonstrate revocation.
We've been reviewing enterprise APIs like:
As we consider the next steps for the VC HTTP API, and I think we may be reaching a point where the work item needs to be split up....
There are a couple competing interests which appear to be mutually undermining and harming progress.
I think some folks have in their mind that this repo is just for 1, maybe 2... and that 3 is out of scope... yet 3 is what I want to work on in the CCG, and what our customers need...
Take a look at: https://app.swaggerhub.com/apis-docs/Trinsic/Credentials/v1
^ this is what we need to be doing... an HTTP API for working with verifiable credentials that implements the VC Data Model, and that works with credential formats other than AnonCreds....
There are some requirements for building an enterprise grade http api which I assert are non negotiable.
1. It must not invent or use custom authentication or authorization schemes
In this regard hyperledger fails miserably, by inventing and relying on non standard, poorly documented concepts like "didcomm v1 and connections"... I am not against these technologies... but they are thinly veiled vendor lock in... and most importantly... they are non standard ... until they have a published spec that is developed under IPR protection.... we are still waiting for a stable version of didcomm v2 ....
2. It must scale horizontally
@msporny and others have argued against batching APIs, and its true... that batching operations can cause issues... however... https://www.twilio.com/blog/2017/12/send-bulk-sms-twilio-node-js.html see also: https://www.twilio.com/docs/sms/api
The user experience of calling such APIs MUST account for horizontal scaling AND meet the needs of customers who start with 100,000 credentials and need to get them issued or verified at scale.
See also https://github.com/gentlespoon/USCIS-Case-Status-Checker#uscis-case-status-checker
Obviously asking a remote server to do 10,000 or 100,000 operations needs to be done nicely....
3. It must be exquisitely documented
All inputs and outputs must be fully defined such that vendors can easily implement conformant support.
4. It must have the features that developers need.
Notice that most APIs that allow you to create resources, also allow you to get them?
Where is
GET /credentials?issuanceStartDate&issuanceEndDate?What about all credentials issued by the subject of an OIDC
access_token?Conclusion
I think it's possible that many folks who contributed to this work item do not agree on its scope, and consider enterprise grade http APIs for verifiable credentials to be "secret sauce"...
I don't want to feel like I am forcing them to undermine what they consider to be competitive advantage, while I try and meet my interpretation of customer obligations with respect to open APIs....
I see 2 paths forward: