<orie> I would say GNAP is a great fit for holder interactions, but does not match map cleanly to "issuer" or "verifier" functionality in the current vc http api... though I could see the whole thing getting replaced by GNAP with enough effort.
<mike_varley> GNAP is a re-engineering of patterns in OAuth and OIDC to enable dynamic and flexible user-to-server interactions and authorizations (enabling bring your own wallet and mobile interactions etc...) and overlaps on some of the objectives of this HTTP API in a broader sense (but focused on authorization)
Topic: HTTP APIs for CredX
<juan_caballero> wow direct NFC proofing
<juan_caballero> (asking uber drivers for their medical records is not currently legal or ethical)
<juan_caballero> (but maybe "prove you work for uber" or "prove you can legally drive a car" would be simpler examples of the same use cases sidestepping health record privacy and ethics)
<tallted> big +1000
<orie> in a world where vc-http-api is just a single endpoint for receiving post messages.
<juan_caballero> red is plan A, yellow and green are two acceptable plans B?
<orie> Thanks Daniel!
<mprorock> thank you!
<evan_tedesco> I think green is plan a
<juan_caballero> ^Some of my best friends are SOAP
<anil_john> Me too! WSDLs, Schemas' Oh My!
<mprorock> sshhhh orie, don't tell people that (seriously, why would you want type safety and tooling)
<dlongley> +1000 to Justin
<tobias_looker> Yeap +1 to justin
<justin_r> apologies for being longwinded, this is something that I have cared about and talked about a LOT in my career....
<orie> there is also DIDComm over grpc
<mprorock> @orie yes, didcomm keeps looking better and better to me
<orie> part of why the universal wallet interop spec calls "issue" / "present" abstract is specifically to allow for optimization at the transport / protocol layer.
<juan_caballero> i see both sides, hopefully there's a middle ground
<juan_caballero> +100 chris is a CHAMP
<orie> I can attest that crying doesn't to nearly as much as you might wish it did.
Topic: Use Case Updates
<juan_caballero> 3 separate repos or just 3 separate files in the repo to simplify gitflow and merge conflicts?
<manu_sporny> Agree, that's the downside -- so perhaps just Google Docs.
<charles_edebiri> I agree with Heather. I don't find Github user friendly.
<justin_r> FWIW I disagree with Heather, I don't find Google Docs friendly
<orie> well, as long as the people doing the work can use the tool.
<justin_r> there is no perfect tool, the winning move is to have a dedicated curator that collects them from people "outside" the tool
<orie> like an "editor" ?
<justin_r> it's more important that everything is readable, since writing can be overcome with help
PROPOSAL: Use the use case template in Juan's Google Doc and Google Docs to collect use cases.
RESOLUTION: Use the use case template in Juan's Google Doc and Google Docs to collect use cases.
<dmitriz> er wait
<juan_caballero> dmitri get it together man
<orie> but its not 100% .... does that mean we can't resolve it?
<tobias_looker> if we add dmitrizs votes up -1 +1 -1 there isnt a double vote :)
<orie> I am a fan of file splitting for OAS
<manu> yes, +1 for splitting OAS files
<manu> maybe we just split all of these things into pieces.
<mprorock> Splitting OAS by functinoality, then merging into a master API doc set is a common best practice