review DIDComm requirements

[bluesteens]

Steering: Proposal Summary

The implementation detail of DIDComm has not been specified yet. OCI needs to address this either through amendments to the conformance criteria or conformance program to enable feasible wallet provider audits.

Phase 1: address auditors in Conformance Program
Phase 2: address the DIDComm content

Steering: Publication Summary

Used to present completed work to Steering for approval to publish.
Discuss the work that was completed in reference to the above proposal. Include any differences from the proposal and why.
use [GitHub Preview](https://htmlpreview.github.io/) to show final state of documents along with pull requests (if needed).

---

Detailed Description:
see PR, incl. comments

• see Conformance Prgrm PR: limitation of audit scope re DIDComm added Conformance-Program#7

We need to remember to check if the Issuer Criteria are affected, too.

---

Triage:

• Is Issue appropriate for OCI Architecture
• Assign Size
• Assign Priority
• Assign Label (if needed)
• OCI affected Artifacts Identified
• Assign Triage - Artifact Version Target (v x.x.x Milestone)
• Assign Triage - Interop Profile Version Target (v x.x.x Milestone)
• Create sub-project (if needed)

Affected Parties (help determine Sunrise/Sunset):

• Trading Partners
• Issuers
• Wallet Solutions
• PI Verification Solutions

Affected OCI Artifact

• Schema Document
• Identity Schema
• ATP Schema
• Issuer Conformance Criteria
• Wallet Conformance Criteria
• VRS Solution Conformance Criteria
• Wallet API Specification
• Governance Document
• Conformance Program
• OCI Website
• Internal Process

Change Category (Guides Steering Review)

- Steering/Industry Review

• Business-Level (May affect business operations)
• OCI Governance, Policy or website feature

- Steering/Industry Notification

• Technical-Level (Does not affect business operations)
• OCI Internal Process or Infrastructure

Communication

• Website
• Newsletter
• email:
• Other:

[strumswell]

I would also like to add that the current DIDComm sections don't add anything meaningful to the specification at all. It is a mere "We like this tech and we want to work with it!" without actually going into detail on how wallets are supposed to use this tech. I understand that removing this now might not hit the mark which is why I opted for marking a lot of it as optional and/ or added a hatch for alternative technologies we are currently using (see credential issuance). Those points still stand even without the upcoming audit.

[bluesteens]

P&A call, Aug 10:
DIDComm is to stay the only option in wallet confo criteria (no watering down); question is whether to add footnote in Confo Criteria or add instructions (maybe sunset date) in Confo Prgrm

• change in Confo Prgrm
• add ref to Prgrm in Criteria

[bluesteens]

14.9. P&A: edits in DWCC
standardized direct wallet-to-wallet
remove: It can be used to implement custom DIDComm flows meanwhile bearing in mind that these might be off-standard in the future.

IF005
Issuance of Credentials via DIDcomm with Encrypted Messaging Envelope as specified in the DIDComm Messaging Specification based on Aries Protocols

check IF003 Spherity ref or OCI ref?

[bluesteens]

DWCC edits included in PR as discussed. re IF003: see https://github.com/Open-Credentialing-Initiative/vc-status-2021-ldap >> this has been forked from Spherity but more work is needed for full migration to OCI. Hence, the Spherity link is the correct ref for now.