section 4 Wallet Conformance Criteria: description of DID methods

[bluesteens]

4.1.2 Verifiable Data Registry & Endorsed DID Methods
a. This sentence should be removed, as it offers a loophole for others to challenge or complicate existing OCI architecture.

A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials.

b. The last column in the table (OCI Credentialing Actor) should be removed, as OCI should simply state which DID methods are endorsed without imposing the roles for which they are used.

c. OCI should define what is meant by:

Digital Wallet Providers SHALL implement and support all DID methods

"Support" can simply mean being able to resolve DIDs but also to offer DID creation for usage. I'd removed the word "implement".
It is the solution provider's decision, which DID methods to offer to users for creation/usage. OCI can only really demand DID resolution of all methods to ensure interop.

d. OCI may want to consider setting out broad expectations on the qualities for DID methods to justify the recommended ones, e.g.

• DID document integrity
• DID document history
• always available registry

03/31 update: following review, this ticket has the same objective as ticket #32 - thus it is recommended to discuss them together

• There is no conflict between using did:web and and ETH-based trusted issuer registry. see also comment below: section 4 Wallet Conformance Criteria: description of DID methods #31 (comment)

[bluesteens]

loosely related to issue: Open-Credentialing-Initiative/Credential-Issuer-Conformance-Criteria#12

• moved comment after ticket was split

[bluesteens]

• Is Issue appropriate for OCI Architecture
• Create Steering-Level summary of request
• 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

[bluesteens]

fix of CI 6.1 could be done alongside issue #15
ref relates to ticket #32

[rceleste125]

The Trusted Issuer List is on Etherum and is a list of Trusted DIDs. Do the DIDs need to be ETH DIDs?

[bluesteens]

separate ticket into 2 based problem areas

• move 1st half to Steering
• refine 2nd half (can did:web sit in ETH TIL?) >> now ticket did:web for issuer? #32

[lleifermann]

The Trusted Issuer List is on Etherum and is a list of Trusted DIDs. Do the DIDs need to be ETH DIDs?

The trusted issuer list in its state right now stores the list of trusted dids as strings. So all even though the list resides on Ethereum it supports all types of dids (and other identifiers).

[bluesteens]

atm the Digital-Wallet-Conformance-Criteria talk about did:web security but not did:ethr >> consider adding a section

[alexcolganLD]

A. I read this as general information, but OK with removal as it might lead to confusion.
B. Agree, this seems like an outdated placeholder.
C. How about the following: "To ensure resolution of DID methods, Digital Wallet Providers SHALL support the resolving of all DID methods endorsed by OCI, and SHALL implement at least one DID method."
D. 160+ DID methods exist or are under development, suggest we leave this one alone as a change management process question.

[rceleste125]

Steering Summary:

1. Remove the limitation for issuers to be limited to use DID:Web method only (allow all OCI supported methods)
2. Define what "Support" means for a Wallet.

[bluesteens]

edits on branch https://github.com/Open-Credentialing-Initiative/Digital-Wallet-Conformance-Criteria/tree/bluesteens-did-methods

[bluesteens]

13.7.23: amend - "Digital Wallet Providers SHALL support the resolving of all DID methods endorsed by OCI, and SHALL implement at least one such DID method, i.e. create and maintain the resulting DIDs."