... Mike Prorock covered this earlier today, on the main weekly call
... this is version 1.1, fully backwards compatible. There's some substantive changes, but mostly about standardizing the Date Format, loosening some of the restrictions on ZKPs,
... stuff like that
... it's out for the Advisory Committee vote
... to accept, formally object, & everything in between.
... vote is open til Jan 18, 2022
... so if you're a W3C member, and you know who your AC representative is, please ask them to vote
... any questions?
... the only other kind of question (specifically for this group) -- there's a question about using VC API in places that
... could use better test coverage. Such as the VC Data Model spec, the DID Core spec
... for example, there was a demonstration of using the did:key spec for interop of signatures
... and it used VC API, to do DID interop testing
... of course, when we do the VC 2.0 work, we'll also be doing Linked Data Integrity testing
... the 1.0 test suite required you command-line things, to validate the VCs
... the 2.0 test suite, I'm suggesting, should use the VC API
... any objections to going down that path? (~2 years from now)
... any philosophical / principled objection to using the VC API, to test LD & JWT proofs, in the VC 2.0 work?
David Chadwick: Clarification question -- I thought the VC API was intended to be primarily internal, within one trust domain? ✪
... interop testing would necessarily require crossing trust zones, no?
... could we use OpenID Connect instead?
Brent Zundel: The decision will ultimately be up to the VC WG ✪
Manu Sporny: Yes, +1 to that, the decision is in the VC WG's hands. Just wanting to check if this group has objections though ✪
... David, the question you raised -- the way I'd see it potentially working is that the test suite itself is making the call to the Issuer API and the Verifier API.
... so, the test suite IS a single trust zone
... so you can still consider it internal use
... (it would be given the appropriate credentials to invoke the Issuer & Verifier API)
... for example, see Charles's implementation for the did:key interop work
Manu Sporny: And please suggest a concrete change that would address the objection ✪
Adrian Gropper: I'm not sure I can propose spec test ✪
... but these things are foundational, and need to be dealt with up front, in an overview doc
... right now, these things are buried, if there at all
Manu Sporny: It sounds like you'd like the acknowledgement of the importance of delegation ✪
Adrian Gropper: Not only delegation. but specifically the separation of concerns, for "zero trust architecture" designs ✪
Manu Sporny: Adrian, the easiest thing would be to suggest some phrasing. It doesn't have to be super technically accurate, but it's hard to guess what you're looking for ✪
... and ideally, we don't couple that concern to the diagram itself. But it's up to you, if you feel that it's related to the diagram specifically
Manu Sporny: Ok, that's 237. Next up, Juan's global search & replace of VC HTTP API to VC API ✪
... the other question that came up was -- would implementers be willing to move over to Ed25519Signature2020 suite, for the next round of interop testing?
... 2018 is a bit janky, and 2020 is a bit cleaner. I know a couple of implementers can use 2020...
... any thoughts on this?
Charles E. Lehner: I'm prepared to change it to a 2020 test vector (Spruce has a 2020 impl.) ✪
Manu Sporny: We should ask at least 2 other implementers, to see if they're willing to make the jump ✪
... it's a simple change, but we should ensure everyone's cool with that
Charles E. Lehner: Would we still want to keep the 2018 credential example? ✪
Manu Sporny: Good question, let's check with everyone. ✪
... we could demonstrate that you can use 2 crypto suites, that are two years apart, that you can switch between
... maybe the right question to ask in this repo is -- remember, we all made a decision that it's just did:key
... so the other thing we can do is decide on just one crypto suite.
... so, the VC API test suite will only work with did:key, and only one signature suite
... my suggestion would be the ed 2020 suite.
... and we can mention "and then there are these optional suites you can support"
...but the base tests can at least lock it to one did method & one suite
... but if we can't agree, then we can support all the variations people want
... ok, those are the PRs.
... I'm hearing that all but one of them can go in
... Juan, you're going to clean up the meeting info one, and the others will go in immediately
... re 237 - Adrian, you're going to try and propose some text
Manu Sporny: Next up, issue 45, distinguishing cred-issuer relationship in URI namespace ✪
Dmitri Zagidulin: This seems to propose breaking up the issuer endpoint to multiple endpoints to cover various use cases. [scribe assist by Manu Sporny] ✪
David Chadwick: I thought we got this already, in the latest design? ✪
Manu Sporny: Not quite - we don't break it up like this proposes. ✪
... we just say "any server can implement the Issuer and Verifier API all on one server"
Adrian Gropper: I recommend marking this with 'Authorization' tag as well. ✪
... in general, if we adopt the model that GNAP uses (where we acknowledge that the protocol has a request component, and an access token component), then this becomes a lot easier to process
... I'd treat this as an authz issue
Manu Sporny: Looking at the last sentence (about the same party can play multiple roles) ✪
... I think we already have this today
Dmitri Zagidulin: What if we reply that we request use cases -- some day in future we might want x, need concrete use cases. [scribe assist by Manu Sporny] ✪
Juan Caballero: We were already going to (ideally before next Tues) go through the use cases, and mark which app/service is hitting which ✪
... if you look at the usecase doc now, it just lists which endpoints get hit, but not /whose/ endpoints.
... we tried to sort it out, on another call, and it was hard to figure out
Adrian Gropper: This is exactly the problem that GNAP has worked on for a year ✪
... in that, they separate out the requesting party from the role of the requesting party
Manu Sporny: Ok, so, what are we doing with the issue ✪
... leaving comment, requesting concrete usecase related to the issue. also mentioned GNAP relevance to this issue
... also discussed that perhaps the API already supports this viewpoint
David Chadwick: I think I've got a use case for this. The power of attourney ✪
... where the holder wants to get a VC for their parent. and what they present is a PoA credential, to show they're authorized
Adrian Gropper: I'd be happy to also be assigned ✪
Manu Sporny: Will do (I need to add you to the Assignees group), please remind me ✪