<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.
... expanding user inteaction possibilities, no longer assuming user is in browser
... good fit with GNAP? signifcant overlap seen
... intention to attend further meetings if possible. IATF meeting next week, open invitation to channel to attend
... newest GNAP spec, attention to section 4
<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)
...so we really want to know, does the API fit as an extension of the protocol, and if so, how, what changes are needed etc. Call for feedback, suggestions. we encourage as many people as possible to track both conversations and keep them in line.
Topic: HTTP APIs for CredX
Daniel Buchner: HTTP APIs for Credential exchange ✪
... dovetailing with GNAP dsiscussed previously
... Issue 50 on VC HTTP API
... use cases under discussion include Didcomm, Daniel wrote a Medium article about this
... framing credential exchange as HTTP problem is a false approach, and I would rather we expand the use cases beyond ones where HTTP is a bottleneck
<heathervescent> LOL
... Korean use case using verifiable credentials to monitor clocking in/out
... Mobile device connecting to webserver to authenticate, concentration of operations in narrow time windows
... this lead to a suggestion of having to massively scale server capabilities, prompting rethink of the authentication infrastructure
<juan_caballero> wow direct NFC proofing
Orie Steele: +1 To direct p2p support without the need for an http mediator. ✪
Mike Prorock: +1 To looking at schemas and structures in multiple formats and not limiting to http only ✪
... plot twist: Uber driver has covid-19
<juan_caballero> (asking uber drivers for their medical records is not currently legal or ethical)
... idea = ordinary people as verifiers, horizontal verifications
<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)
... using verifiable identity to negotiate personal exchanges, reciprocity, not such a good fit with HTTP approaches
... use case 3 Italian Visa
... Delayed responses due to time difference, human processes
... HTTP API could be a possible solution, but the Swiss government has no such infrastructure
Orie Steele: Most folks don't run webservers on their phone voluntarily :) ✪
... Swiss gov could sidestep HTTP to solve the issue
... use case 4
... digital cash - FB Libra concerns triggered wave of interest in CBDCs
... current global government projects investigating digital cash infrastructure, esp offline solutions
... Bahamas mention, Sand Dollar, designed to distribute disaster aid relief, to remove internet connection requirement
... VCs for KYC & AML
... Gov requirements indicate that HTTP is not applicable in all cases, they need to be more generic and high level
... Specificites of HTTP will keep edge cases like these on the margins, sucking up all the oxygen, funding, and momentum for institutional cases relying on client/server architectures
<tallted> big +1000
... I want us to broaden the design spec, describe something HTTP specific as one implementation but not the only one
... describe problems as "payloads" without fixing everything to web-based implementation details
<orie> in a world where vc-http-api is just a single endpoint for receiving post messages.
... i also think we need to keep the issue of transport security separate, so that different implementations and use cases can apply security above or below this layer rather than having one security model fixed by assumptions we make now
... 3 alternative paths for standardization
<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
... existing transport security - new standard, existing transport security - coalescing stnadard for credx
... standard for transport-agnostic encryption envelope
Manu Sporny: We don't want to pitch HTTP as the only solution ✪
... can we look at the issue wholistically instead of narrowing the approach
Justin Richer: I understand the desire for a broader more abstracted system that is more widely applicable, but I hold it to be a fiction. The last time we tried for a giant abstract system was SOAP ✪
Orie Steele: I happen to have liked working with SOAP : . ✪
... SOAP was a platform-agnostic solution
<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)
... these don't take advantage of any native aspects of the tech being used, writing to an assume common abstraction layer
<dlongley> +1000 to Justin
... building an abstraction layer on top of HTTP that eventually rely on quirks or structure of the underlying tech, even if unintentional
... note, this is not a request for niche counter-examples
<tobias_looker> Yeap +1 to justin
...´one appraoch that has been seen to work is to take the concepts from a concrete system which depends on a specific set of transpot, security layers etc and translating it, eg. TLS moving to somehting TLS-like, abstraction not being a one-size-fits-all solution
<justin_r> apologies for being longwinded, this is something that I have cared about and talked about a LOT in my career....
Orie Steele: I'm sorry that you have stockholm syndrome from SOAP [scribe assist by Justin Richer] ✪
... Referring back to issue 50, question of scope, internal vs external
Justin Richer: In fairness I only used SOAP over HTTP :) [scribe assist by Orie Steele] ✪
Daniel Buchner: HTTP is ideal for an internal insfrastructure, but there is little pressure to standardize there. I am not even certain the distinction holds very well. ✪
Orie Steele: That's exactly my point! That's all anyone ever did! All the abstraction was smoke and mirrors. [scribe assist by Justin Richer] ✪
... abstraction would enable multiple platforms like bluetooth, and I think we need to be wary of sacrificing privacy of individuals for the conveneince of organizations by favoring their architectures in our design process
Mike Schwartz: Internal use case, thinking about the data structures rather than the protocol, eg GRPC ✪
<orie> there is also DIDComm over grpc
<mprorock> @orie yes, didcomm keeps looking better and better to me
Dmitri Zagidulin: +1 To Daniels points, also Justin, going too far with an abstract approach has been unsuccessful in the past but let's not assume things liek QR code and bluetooth approaches cannot work ✪
... more of a 'design stance'
Orie Steele: All didcomm needs is an abstract data model :) ✪
<orie> /jk
Dave Longley: There are a variety of protocols available, constant uphill battle if we move too far from HTTP approaches, these edge cases may only get addressed if the whole idea moves forwad on an HTTP approach ✪
Orie Steele: Only if it has deterministic normative translation rules ;) [scribe assist by Justin Richer] ✪
... if these use cases are important then they will be adressed in time
Justin Richer: We can use CDDL! [scribe assist by Orie Steele] ✪
Orie Steele: Fine w/me [scribe assist by Justin Richer] ✪
Justin Richer: -1 To TallTed, this isn't what I was saying at all ��♀️ ✪
... significant achievements have been made, the generic design does not need to be a single abstraction layer to fit all use cases
...HTTP and other protocols can play nice, it would be overly simple to narrow the choice to only HTTP
Daniel Buchner: Arguing for two abstractions, security and transport ✪
... payloads also need to be addressed as an individual problem
... concrete use cases have been given as examples
<orie> part of why the universal wallet interop spec calls "issue" / "present" abstract is specifically to allow for optimization at the transport / protocol layer.
... SSI has a goal of helping people who are disenfranchised
<juan_caballero> i see both sides, hopefully there's a middle ground
<juan_caballero> +100 chris is a CHAMP
... these issues should not just be addressed where lucrative on the assumption that the way they are being address will automatically benefit fringe cases collaterally
<orie> I can attest that crying doesn't to nearly as much as you might wish it did.
Juan Caballero: Posted google doc to incorrect repo, oops, now on this repo, 2 volunteers from legendary requirments stepped forward to assist editorially with use-cases and other supporting documentation. ✪
... google doc is getting a lot of chatter, happy to move to markdown/respec in the repo instead of gdoc, will wait for the green light from the current editors to move the work over
Manu Sporny: That may happen in parallel, we don't want to discourage people contributing ✪
... task of the editors is to organise after the fact
... screen share - VC HTTP API Use Cases
... showing a GH issue template for a use case submission, thanks to Ted for work on this
... we probably do need a repo for use cases, feedbakc appreciated on people's ideas for keeping that seperate
<juan_caballero> 3 separate repos or just 3 separate files in the repo to simplify gitflow and merge conflicts?
Heather Vescent: Likes use case template, question who are providing those use cases ✪
<manu_sporny> Agree, that's the downside -- so perhaps just Google Docs.
... Git hub users are people eg familiar with writing documentation
... this may be a barrier to entry / self-selecting out useful examples
Justin Richer: Use cases collected from a number of groups ✪
... best used to guide the beginning phases of work rather than shape output
... suggestion for wiki structure or similar for managing this collection of data
<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
... as opposed to an issue tracker, important to also ensure people are using the same terms of ref
<heathervescent> ROTFL
<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.
Manu Sporny: Google doc appears to be working well for now, does anyone object to continuing using that for now, call for submissions from the group if people have objections/concrete suggestions ✪
Markus Sabadello: Note - if there is support for splitting into 3 files, there are likely shared components acress issuing and verifying, is overlap an issue for the editors ✪
<mprorock> Splitting OAS by functinoality, then merging into a master API doc set is a common best practice
Manu Sporny: Looks like we are moving toward splitting the OAS files ✪
... thank you to all attendees for attention and input. Next week discuss use cases and new APIs in the spec
... specifically the Holder APIs, please bring use cases for next week to discuss