Issue Credential and Present Proof v3 - RFC and URI resolution - Githubissues

decentralized-identity / waci-didcomm

Wallet And Credential Interactions for DIDComm

https://identity.foundation/waci-didcomm

Apache License 2.0

12 stars 12 forks source link

Issue Credential and Present Proof v3 - RFC and URI resolution #4

Open rolsonquadras opened 2 years ago

rolsonquadras commented 2 years ago

Currently, the issue_credential v3 and present_proof v3 live in DIF WACI repo https://github.com/decentralized-identity/waci-presentation-exchange. What's the right place to host these ? Based on https://github.com/hyperledger/aries-agent-test-harness/pull/447#issuecomment-1066890682

Also, we need to consider URI resolution

OR13 commented 2 years ago

I suggest porting the proposed language back to aries RFCs, and then cross linking.

OR13 commented 2 years ago

Blocked until there is a stable perma url for DIDComm v2... then Aries RFCs should be updated.

brianorwhatever commented 2 years ago

wherever it does end up living it should also be cross referenced in didcomm.org

OR13 commented 2 years ago

Still waiting for a perma URL for DIDComm v2

OR13 commented 2 years ago

In order to close this, we need:

[ ] issue credential didcomm flow at a stable perma url
[ ] present proof v3 at a stable perma url
[ ] references updated to use the appropriate links

rodolfomiranda commented 2 years ago

DIDComm v2 has now a DIF Ratified Status; can it count as a perma url to move forward?

OR13 commented 2 years ago

It can when its been PR'ed into the spec... my experience with DIF is that its better to use an internet archive link, than to trust DIF to maintain perma-urls.

bumblefudge commented 2 years ago

@rodolfomiranda - let's get a permanent URL going on DIDComm, shall we?

I threw this together, but it's more "exemplary" than "ready to merge" because I didn't know what exact commit to target for the snapshot: https://github.com/decentralized-identity/didcomm-messaging/pull/409 If you can help me with that I'm glad to re-do it. Or, if nothing normative has changed since v2 was ratified, we're good to go. I really should've asked as the meeting!

Like Orie, I would prefer a native/turnkey way of versioning specs that creates permalinks, but this is what we currently have for specs published in spec-up. If anyone knows a way to "lock" or future-proof the .../vX.X/ versions of specs in github/gitpages that would be great, because as-is, overwriting the vX.X sourcefiles can alter the static versions at those addresses.