- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Wed, 14 Dec 2022 14:01:09 +0000
Thanks to Our Robot Overlords and ben_(transmute) for scribing this week!
The transcript for the call is now available here:
https://w3c-ccg.github.io/meetings/2022-12-13-traceability/
Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:
https://w3c-ccg.github.io/meetings/2022-12-13-traceability/audio.ogg
----------------------------------------------------------------
Verifiable Traceability Task Force Transcript for 2022-12-13
Agenda:
https://lists.w3.org/Archives/Public/public-credentials/2022Dec/0058.html
Action Items:
1. Chris to resolve conflict in PR #480 and merge offline
2. Mahmoud to create issue to relax text requirements for error
responses
Organizer:
Orie Steele, Mike Prorock, Mahmoud Alkhraishi
Scribe:
Our Robot Overlords and ben_(transmute)
Present:
Nis Jespersen , Russell Hofvendahl, Ben (Transmute), TallTed //
Ted Thibodeau (he/him) (OpenLinkSw.com), Mahmoud Alkhraishi,
Yinghui (Vivien) Fan, Chris Abernethy, Ted Thibodeau, Orie Steele
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 :
https://github.com/w3c-ccg/traceability-interop/pulls
Nis Jespersen : We'll start with the trace-interop pull requests
first
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/pull/476
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/pull/478
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/pull/476
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/pull/477
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/pull/480
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pulls
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 :
https://github.com/w3c-ccg/traceability-vocab/pull/647
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/656
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 :
https://github.com/w3c-ccg/traceability-vocab/pull/657
Nis Jespersen : Merging
Yinghui (Vivien) Fan: In the case of an event, we added a
recipient location
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/658
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/659
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 :
https://github.com/w3c-ccg/traceability-vocab/pull/661
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/664
Russell Hofvendahl: This is an error with PPQ 429 that was an
issue caused from copy and pasting
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/665
Russell Hofvendahl: This creates a form PPQ 449 for fumigation
record with/without tarpaulin.
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/666
Russell Hofvendahl: In my notes I had a bunch of tiny fixes that
built up, so this is a PR addressing them
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/667
Russell Hofvendahl: This renames organic certificate to organic
certification which was suggested in an issue a while back.
https://github.com/w3c-ccg/traceability-vocab/issues/616
Nis Jespersen :
https://github.com/w3c-ccg/traceability-vocab/pull/647 again
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
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/issues/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 :
https://github.com/w3c-ccg/traceability-interop/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/issues/405
Nis Jespersen : First is 405. Which is addressing SD-JWT. Looks
like the last person to comment on this was Ben.
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/issues/427
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.
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/issues/402
Nis Jespersen :
https://github.com/w3c-ccg/traceability-interop/issues/359
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.
Received on Wednesday, 14 December 2022 14:01:09 UTC