Minutes for 2021-09-28
https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0124.html Topics New Data Flow Diagrams Pull Request Review ReSpec OAS Autogenerator Plugin Organizer Manu Sporny
Scribe Brian Richter
Mike Prorock, Michael Herman, Manu Sporny, Dmitri Zagidulin, Markus Sabadello, TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), David Chadwick, Ted Thibodeau, Brian Richter, Adrian Gropper, Orie Steele, Juan (Spherity GmbH), Eric Schuh, Joe Andrieu, Justin Richer, Brent Zundel, Mike Varley, Bob Wyman Audio Log
Warning: Your browser does not support the HTML5 audio element, please upgrade.
Brian Richter is scribing.
<mprorock> Codeowners List: @peacekeeper @msporny @mavarley @OR13 @mkhraisha
<orie> its issue processing
<orie> its amazing how hard elections have gotten since twitter was invented...
Mike prorock: vote was not on timezone, was informational poll that timezone was not announced with
<davidc> What is wrong with UTC?
<markus_sabadello> Let's have a poll about which timezone to use :)
Topic: New Data Flow Diagrams
<mprorock> big thanks to Eric and Joe on this
<michael_herman_(trusted_digital_web)> role -> Actor
<michael_herman_(trusted_digital_web)> Roles are not actors in most formal modeling metamodels
<manu_sporny> I like this direction...
<michael_herman_(trusted_digital_web)> Actors are assigned to Roles but Actors are the only entities that perform actions.
<dmitri_zagidulin> it seems like the Verifier Storage Service doesn't add much to the diagram. (plus, many verifiers won't be storing the VC, etc)
<orie> > holder
<michael_herman_(trusted_digital_web)> These are personas
David chadwick: in the model we've got we differentiate between application layer and VC layer. when we talk about app that could be browser on mobile phone or 3rd party banking app which talks to holder app. on relying party side we have service provider which will talk to the service
<michael_herman_(trusted_digital_web)> But role is not an appropriate use in this diagraam
<orie> I would happy to be on a call with you David!
<juan_(spherity_gmbh)> might be a good topic for the VC-GUIDE :D
<juan_(spherity_gmbh)> (and/or for issues for VC spec v2)
<brent> so, the "holder role" label should be understood to mean "an actor in a holder role?"
<orie> this picture does not include Issuer... it assumes that the holder already has a VC... we don't care how that happened.
<mprorock> I would love for Joe to be able to walk through his and Eric's work on this use case, then have a discussion about it honestly
<manu_sporny> ok, we can do that mprorock
<mprorock> with a big caveat that we are talking system to system use cases here
<orie> i'm not sure why we are allowing the unrelated conversations to persist in this work...its confusing and harmful.
<orie> Imagine a CRON Job that shares data between 2 web servers...
5. Constructs a data package (domain and challenge)
Holder gets VC
(From storage service)
<orie> not sure why we are talking about other CCG work items like web KMS... that work item is not required.
<mprorock> @orie - agreed, basically some key management - not a specific one or protocol
<orie> I like to model this as 2 network requests between 2 web servers, where they are started by a cron job.
<orie> revocation status is not relevant or needed.
<manu_sporny> @orie @mprorock -- I believe JoeA was just using WebKMS as an example of key management, not a requirement.
<orie> yes he was, its not required... nor is revocation.
<orie> link to use cases.
<orie> this is the chapi flow.
<orie> we designed it to be like CHAPI flows...
<orie> 6 months later...
<orie> literally shaking..
<orie> thats because all VP flows require domain and challenge to be exchange prior to VP construction and communication.
<orie> all the VP flows are similar
<orie> since they all require getting a domain and challenge from the verifier.
<manu_sporny> /me ghost queue
<orie> No, its 2 apps talking to eachother... they are apps... not people.
<orie> it turns out that APIs exchange data... without people being detected as being alive, or involved.
Mpro: that is the individual flow
<dmitri_zagidulin> I think it might be worth clarifying that VPs only need challenge & domain when used for authentication. But not really for other purposes.
<orie> here is the flow with lots of abstraction:
<mprorock> traditional enterprise API use cases for VCs is basically what we are dealing with to expand on Orie's comment
Topic: Pull Request Review
<orie> Nobody SHOULD be required to implement something that is not possible to implement in their chosen programming language.
<tallted> orie - that would be a justification to NOT do the thing!
<orie> MAY does nothing... exactly... better to do nothing... than to do something harmful.
<orie> it is impossible to render GNAP RAR in OAS3.0... its not supported.
<justin_richer> Orie then you have bad tools ♀️
<mprorock> that is fine, but let's take that to the mailing list, not this work item for now
<justin_richer> Also, I adapted it to do just that, since it's open source. It just doesn't allow plugins because of the software design.
<orie> I have tools that enterprises are using... i think you might have a spec that nobody has adopted yet.
<justin_richer> Orie you mean VC-HTTP-API? :)
<orie> : )
<tallted> "very difficult, very expensive" are sufficient arguments against doing a SHOULD. it need not be "impossible"
<orie> ZCAPs are also not a standard and also not supported by OAS3.0.
<tallted> also, SHOULD is the historical compromise between MAY and MUST
<orie> I'm a -1 to doing things that OAS3.0 does not support.
<justin_richer> I'm -1 to pegging an emerging standard to OAS3.0's capability set
<orie> if GNAP gets added to OAS3.0 we are good to use it.
<justin_richer> like, any emerging standard
<orie> we agreed to use OAS3.0... if we want to take that back I am happy to start from scratch again :)
Topic: ReSpec OAS Autogenerator Plugin
<davidc> I wanted to say that we may have different authz delegation rules for the different APIs (verifier, issuer and holder) and the current text does not differentiate
<justin_richer> OAS3 is a tool -- treating it like a requirement is putting shadow dependencies into the spec, and that's just bad design
<orie> thanks for your opinion justin, but we agreed to use OAS3.0, that point was already resolved.
<justin_richer> Using it and depending on it are different things and you're hiding behind that to support your argument.
<orie> Justin, i'm not hiding behind OAS3.0... i am using adopted industry standards to strengthen our work item, and its potential for adoption.
<mprorock> @manu - this is great
<orie> @manu looks great!
<mike_varley> very cool @manu !
<orie> Justin, rendering a standard format is not the same as extending it too support new schemes... you should read the OAS3.0 spec.
<justin_richer> @manu I wrote a renderer for OAS that handles RAR data structures and I'm happy to share it
<mprorock> thanks all!
.. Reminder i won't be here next week markus will be doing issue processing