Closed aljones15 closed 9 months ago
@aljones15 is the test code which already requiring those id
's on the main
branch? Same question for the vcHolder
stuff?
i.e. is this just documenting what's there now? or documenting what's coming?
Also, if it's documenting what's there now, do existing implementers need to come back to make a change?
@aljones15 is the test code which already requiring those
id
's on themain
branch? Same question for thevcHolder
stuff?i.e. is this just documenting what's there now? or documenting what's coming?
Also, if it's documenting what's there now, do existing implementers need to come back to make a change?
Code that uses the id as the issuer has been in all of the test projects for awhile now:
I'm not sure on how the working group resolved the issuer id problem. I know that one proposal was that the issuer endpoint added that endpoint's own issuer id to each VC issued, but I don't know if that proposal was finalized (I'm assuming it did not).
The vcHolder logic is in the sd-interopability suite, it really should probably be its own suite and if you have a derive endpoint we throws some tests at it with say invalid selectivePointers and stuff like that. The code for the vcHolder logic is here (with no further tests of derive beyond a single call):
Which is another place where a DB endpoint is the default instead of a local library doing the disclosure stuff but it is in interop so a remote endpoint does make sense there.
Expands the implementation instructions:
derive
endpoint to implementations