Closed bumblefudge closed 2 years ago
Reminder (as discussed on today's call): Update these use-cases with links if process/non-process distinction (or any other relevant change to the heirarchy or naming of credentials) and/or leave issue open if such changes are pending
This was accomplished
@TallTed can you review the related PR and make proposal for what is remaining to close this issue
@bumblefudge can you propose next steps for closing this issue.
will do
This appears to me to be similar to internal vs external APIs, and along those lines I think there should be no built-in differentiation.
Any differentiation should be deployment-specific, i.e., business logic of the entity using the VCs. That entity might apply different requirements to VCs issued and consumed by internal business processes, which might change over time due to acquisitions or spin-offs, where what was once "internal"/"process" becomes "external"/"non-process" and thenceforth has the latter requirements -- which might be satisfied if the original entity had treated both sets of VCs in the same way.
pending a PR from @mkhraisha
Re-reading, this may be more about static vs variable VCs? More detailed description will likely help with final resolution.
This was referred to on the call as event-credentials. If that what this is(?), I'd recommend looking at this code list: https://service.unece.org/trade/uncefact/vocabulary/rec24/
I believe the vocabulary references is supposed to be EPCIS as outlined in #24
Per call: handle on a per-credential basis
One helpful premise for aligning our use-cases for SC-specific test scenarios and user stories would be distinguishing process VCs (batch-specific, tied to specific import shipments) and non-process VCs (product definitions, legal entity verifications/enrolments, mappings of products to HTS codes, UPC codes, GTINs, etc). This has been very important in our use case, where there is a 1-to-many relationship between non-process VCs to shipments.