The W3C Credentials Community Group

Meeting Transcriptions and Audio Recordings (2014-today)

Go Back


Verifiable Traceability Task Force

Transcript for 2022-12-13

Our Robot Overlords are scribing.
Mahmoud Alkhraishi: Had a couple of pairs on all of the stuff that was really nice so it could be a good thing to start with.
Mahmoud Alkhraishi: Ted had a bunch of I think to really good PR is to update the reading and it might be a good dry run to test those up right because I think they also have instructions on what to say as a host.
ben_(transmute) is scribing.
<chris_abernethy> having audio issues, fyi
Nis Jespersen : Thanks for joining the last trace call of 2022
Nis Jespersen : Let's make this meeting count, this is interop day
Nis Jespersen : Remember to sign the contributor agreement to make contributors
Nis Jespersen : We'll start with the trace-interop pull requests first
Ted Thibodeau: This is pull requests for updating the readme's to make vocab and interop to be in sync
Nis Jespersen : There are three approvals on that and a huge thank you
Ted Thibodeau: Hopefully those approvals came after reading the PR
Chris, can you hear us?
Nis Jespersen : It looks like Chris is having technical issues, let's go over Chirs' pull requests on interop
Mahmoud Alkhraishi: Because trace-interop has a test in it that says the context must have trace-vocab context, this checks to see if the context url is in the array
Nis Jespersen : Looks good, merging
Chris Abernethy: Currently in the VC-data model, the normative language makes id required. So this is to align the profile with the spec
Nis Jespersen : I think it sounds aggressive as we discuss on another issue, but i do agree with aligning with normative requirements
Chris Abernethy: Looks like there is a conflict, but I can address that offline
ACTION: Chris to resolve conflict in PR #480 and merge offline
Chris Abernethy: This comes out of a discussion for making the verification array required in the results of a verification request
Nis Jespersen : Any objection to merging 480?
Nis Jespersen : That's it for trace-interop, let's switch over to vocab
Mahmoud Alkhraishi: This is a little of a meta question, what are we looking to get out of trace-interop? I think we might care less about an exact error response. As much as focusing on getting the right error codes.
Mahmoud Alkhraishi: To me, I think companies should have more freedom with how they show their errors, and we focus more on having the right error codes. And wanted to check what the general feel of the group is
Nis Jespersen : Basically getting carried away with standardizing everything
Orie Steele: I agree, when there is an error we look at the shape of the error, and then ignore the strings. And we don't care about the strings. As long as we ignore the strings and still understand the output.
Orie Steele: I agree, I think we should ignore the strings if we can use codes as all of the information that's required
Nis Jespersen : Do you mean the `good`, `bad`?
Mahmoud Alkhraishi: Yes, that and when I was doing the tests, our error responses were more detailed, but we failed the tests.
Mahmoud Alkhraishi: In the case of issuing a credential, we want to tell them what exactly they are missing, and that information should be up to the provider.
Mahmoud Alkhraishi: With respect to trace-interop, all we want to know is there is a code and that means it's failing and that's what we're looking for.
ACTION: Mahmoud to create issue to relax text requirements for error responses
Mahmoud Alkhraishi: A specific example was missing the credential subject, and the test was saying that we were failing. I'll make an issue so that we can address it.
Nis Jespersen : My suggestion on this would to be merge last and then fix any CI errors that might occur from merging after that
Nis Jespersen : I agree it makes us look friendly, and we'll come back to it
Yinghui (Vivien) Fan: This PR adds scheduled date and scheduled volumne
Nis Jespersen : Merging
Yinghui (Vivien) Fan: In the case of an event, we added a recipient location
Nis Jespersen : We have three approvals, merging
Ted Thibodeau: This is the other side of the trace-interop PR to sync the readme's
Nis Jespersen : Merging 658
Yinghui (Vivien) Fan: This adds a single delivery statement and an array of delivery statements
Nis Jespersen : Sounds good to me, we have three approvals. Merging.
Nis Jespersen : Next is 661
Nis Jespersen : This is a mistake on a title, we have one approval. Can we get another approval to get it merged?
Nis Jespersen : Merging 661
Russell Hofvendahl: This is an error with PPQ 429 that was an issue caused from copy and pasting
Russell Hofvendahl: This creates a form PPQ 449 for fumigation record with/without tarpaulin.
Russell Hofvendahl: In my notes I had a bunch of tiny fixes that built up, so this is a PR addressing them
Russell Hofvendahl: This renames organic certificate to organic certification which was suggested in an issue a while back.
Nis Jespersen : Back to PR 647.
Nis Jespersen : Ben's suggestion is to merge this.
Nis Jespersen : Ben's what's your suggestion?
Nis Jespersen : I think there are a few minor issues on this. I think we can merge it and then make an issue to address any CI errors that might arrise from this out of call.
<mahmoud> Thanks all, need to drop now.
Nis Jespersen : We can come back to trace-interop issues
Chirs: I want to get to 472.
<nis> ues/472
Chris Abernethy: This is to enable branch protection so that we can't merge without two approvals
Nis Jespersen : I completely agree with that. I enabled branch protection on trace-vocab, but we have a commit to update the version. So that might cause issues.
Chris Abernethy: Okay, i'll look into it and if there are errors I'll see about addressing that.
Nis Jespersen : First is 405. Which is addressing SD-JWT. Looks like the last person to comment on this was Ben.
Nis Jespersen : I think I wrote this when I hosted it last, I don't think there is any action to take on it now.
Nis Jespersen : In this issue we are suggesting did:web and nothing else.
Nis Jespersen : I think we might want to consider did:jwk as it might be a requirement for CBP later.
Nis Jespersen : Do we want to continue with requiring did:web?
Chris Abernethy: I don't think I understand the context.
Nis Jespersen : To take this to an extreme, say we required something like did:elem or did:ion. It would require everyone in the cohort to implement those did methods.
Nis Jespersen : The question being posed here is do we want to add did:jwk as a required method in the profile?
Nis Jespersen : I think that this might depend on the requirements from CBP.
Nis Jespersen : I made a comment, we can formalize once we get to it.
Chris Abernethy: I'm blocked on this issue, as we are blocked by 468 to be able to identity credentials by a specific id.
Nis Jespersen : Switching over to 468, this is how to identify a credential
Chris Abernethy: The first is who is responsible for creating an id for a credential, and how is this signaled to the server
Chris Abernethy: There are a number of proposals I made, I'm personally leaning towards suggestions from David Longley that it is up to the issuer to provide a unique id every time.
Chris Abernethy: And the use-case here is that if there is a network error and the client does not get a response, they can send a request with the same id, and then see an error to know if the credential was issued
Chirs: The other part is that it doesn't make sense for the server and client to keep track of id's for two different purposes
Chris Abernethy: The server will need to do a query to make sure it's unique, but otherwise it looks good to me.
Nis Jespersen : I"m thinking of the trade-off here it makes it harder to be a client. I'm worried if it makes it harder for our clients.
Chris Abernethy: I think it makes it harder to be a client. But compared to doing nothing at all, and I don't thank that's an option.
Chris Abernethy: If the client cares about doing status list, then they need to keep track of these id's anyways.
Nis Jespersen : What happened to the reference id, but also issue a credential id on the server-side
Chris Abernethy: That's possible, but it increases complexity as you have an id issued by the client and on the server, and you also lose the ability to check for issuing again to get an error.
Nis Jespersen : To quickly jump in, I think that having two id's adds complexity, so either if the server provides the id, or the client provides the id. We should have only one id.
Chris Abernethy: Where the client is always responsible is proposal 6. And the server responsible is proposal 1. I am in favor of proposal 6.
Nis Jespersen : Which is where the client is always responsible.
Chris Abernethy: Yes.
Nis Jespersen : Is it okay to say we are generally agreeing on proposal 6?
Nis Jespersen : Is this a case where we expect opposition to this?
Chris Abernethy: We had a response back from David Chadwick where a University wanted to re-issue a credential with the same id.
Chris Abernethy: Otherwise I don't think there was anything specific. And if we want to make this ready for PR. I'm happy to jump on this as it unblocks a lot for me.
Nis Jespersen : Let's mark it ready for PR.
Nis Jespersen : What tangible actions to we want to take?
Chris Abernethy: I think that the PR we just merged markes id required, I think this paves the way for conformance testing. Otherwise I think a lot of this might already be in place.