PROPOSAL: We will strive to assign one primary Editor and one secondary Editor (like peer programming) to the VC HTTP API Use Cases Document with well defined responsibilities associated with the position.
Good catch dlongley, I guess I mashed them together lol ✪
RESOLUTION: We will strive to assign one primary Editor and one secondary Editor (like peer programming) to the VC HTTP API Use Cases Document with well defined responsibilities associated with the position.
<mprorock> can we set a timeline on selection?
<orie> deferred for forvever for now
<michael_herman_(trusted_digital_web)> What assumptions, if any, are there about where VCs are stored?
<dmitriz> @Michael - aren't any. out of scope for this api
<mprorock> @Michael Herman - at this moment that is pretty contentious
<orie> Hopefully the UCR Editor will own upgrading this document.
<juan_caballero> Troy had a diagram of some holder use cases and markus mentioned some.verifier use cases
<michael_herman_(trusted_digital_web)> So the http endpoint could be an "agent" on top of a wallet ...or an EDV ...or whatever ...at least for now
Topic: Scope of VC HTTP API
<michael_herman_(trusted_digital_web)> Suggest a scope document comes after
<kayode_ezike> perhaps the lead(s) could create that template
<michael_herman_(trusted_digital_web)> Use the use case document as the exploratory tool
<michael_herman_(trusted_digital_web)> Link to the statement?
<joe_andrieu> a standard API specification for constructing and verifying objects which conform to the Verifiable Credential Data Model specification, along with documentation, integration and compatability tests, and related assets for the test and integration process.
<adrian_gropper> Can we include the "charter statement" as part of the template?
<markus_sabadello> Original intention of VC HTTP API was internal-only (but this doesn't mean that the scope can't evolve from that)
Can someone explain the pro/con of keeping it internal only vs internal and external? ✪
<orie> Speaking for Transmute, we want interoperable APIs for both internal and external use cases.
<orie> and are will to compromise to get both.
<adrian_gropper> I don't understand internal / external either
<orie> Adrian (cross origin / trust domain)
<mprorock> speaking for mesur.io we need interoperable apis for external usage (if internal, interoperability does not matter)
<orie> no such thing as "interop" built on internal APIs.... alone.
<orie> at least for the strong version of interop.
<joe_andrieu> @mprorock interoperability is important for substitutability of the back end.
<michael_herman_(trusted_digital_web)> Need zcap-style capability authorization over the set of methods associated with different types of VCs, for example ...e.g. lifecycle of a driver's license
<dmitri_zagidulin> @Daniel - ok but like... "internal API" basically means "we don't care about security". which is not what we want to go for here...
<tallted> internal/external feels more like default-trusted/default-untrusted -- which sort-of fits firewall delimiter, not necessarily enterprise delimiter.
<orie> internal api interop is also referred to as usable software.
<tallted> interop can absolutely be a concern within the firewall/enterprise. just think about file-server and file-user.
<orie> yeah, S3 interop is a good example of the value of standards based internal APIs
<orie> yep both forms are valuable.
<mprorock> speaking for mesur.io - we need to issue, verify, exchange, and retrieve VCs with third parties in a testable manner - we hope that that can be a w3c spec, hopefully aligned with the vc-http-api
<bblfish> I hear about APIs, but is this really a question of APIs or about vocabularies/ontologies?
<orie> its just api HTTP OAS 3
<dmitri_zagidulin> @bbl - it's really about the API
<anil_john> When speaking about APIs, we need to separate the pipe and the payload. This is about the pipe and not about the payload.
<identitywoman> we just had a conversation at IIW about how to align different/competing credential and presentation exchange - modalities - we had two good sessions - one yesterday a 2nd one today and a third one just after this to plan next steps - so would be great to see synergistic alignment. I will work to get notes from those sessions done and available next week.
<markus_sabadello> Actually the very first version of the API did have some functionality that could be considered external (e.g. for refreshing a VC), but that functionality got removed in subsequent versions.
<troy_ronda> We need a full credential exchange model that we can use in production systems. An internal API just isn't enough.
<juan_caballero> ^ this was my understanding of scope
<anil_john> I think the IIW Killer Whale discussion is relevant to this discussion, right?
<dmitri_zagidulin> @Anil - very much so
<juan_caballero> But also agree that scope needs r
<orie> emphatic -1 to 3 repsec documents
<identitywoman> yes @anil highly relevent
<michael_herman_(trusted_digital_web)> Need a fully
<adrian_gropper> 3 specs
<juan_caballero> Thank you kaliya for managing that convo, will read those notes before next mtg!
<daniel_hardman> Would the 3 specs be versioned together?
<daniel_hardman> How much redundancy would there be in 3 specs?
<manu> Daniel_Hardman, unknown right now
<dmitri_zagidulin> I do want to point out that there is very much asymmetry between different sections of a spec document. like,that's expected
<orie> I think we agree Adrian, but you can't actually seperate these things... you are making that problem worse, by splitting things up.
PROPOSAL: Create 1 ReSpec specification in addition to separating the existing OAS files into modular components.
<juan_caballero> Joint privacy considerations and joint intro sound good to me
<daniel_hardman> Can we do multiple html files even if it's one spec?