# Planning for DIF ID WG

https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md

* Are DIDs are considered personal data? [Get latest update from Nacho?]
* Peer DIDs are not a GDPR problem..? [Invite DanielH]
* Discussion: Can you use anywise DIDs and still be GDPR compliant?
* If link between person and identifier is minimized, it's acceptable?
* What is n "ephemeral identifier" (see discussion in OIDC SIOP) [DavidCh, NatSa]

### DIDs and Personally Identifiable Information

- Privacy is one of the pillars of SSI
- DIDs and public keys, when used with Verifiable Credentials, become PII
- Some DID methods store DIDs and DID Documents on-chain

Meeting goals:

- Define when and why DID becomes PII (pseudonym)
- Examples of PII (public key, hash of public key, ...)
- Summarise ways to mitigate the issue (user consent, private settings (blockchain with limited access), zero-knowledge proofs, other ideas?)
- What to keep in mind when designing DID methods.

## Potential discussion topics

### DID method vs DID profile

DID method today, is a generic term describing any DID method or instance/fork of a DID method. However, we could split the DID methods in (at least) two broad categories:

- DID method - did:ethr, did:peer, did:web, ...
- DID method profiles: instance/implementations of DID methods

DID methods should be profiled (TODO: which properties?)
- anywise, pair-wise, N-wise
- Full DID Document updates, event based (KERI), did document diffs
- ...

Same DID method, can be implemented in several ways. Such DID methods should be called "DID method profiles". DID method profile should only define:
- user authentication (none, oidc/saml, 2fa, ...)
- identification and identity binding (none, basic, substantial, high)
- DID registration (full did documents, diffs, ...)
- DID resolution
- DID storage (distributed, local; blockchain, ipfs, combined, ...)
- Supported verification methods

Context: KERI in the context of existing DID methods, as opposed to KERI being its own DID method.

### DIDs in substantial/high-assurance use cases

DID, blockchain, KERI - importance of knowing the exact last state of the DID Document (so user cannot "hide" the last state)

Resolution of the previous versions of the DID Document - in several cases, I need to know that a given DID key belonged to a specific DID with a certain assurance.

### DIDs and identity binding

Some DID methods don't require any identification/authentication.
In these cases, DIDs only be used for authentication with low assurance level.