# `did:ucan2:{encodeUriComponent(dataUri)}`

syntax `did:ucan2:${encodeURIComponent(dataUri)}`
* we can say the dataUri must be decodable to either application/json or dag-json

how to resolve `did:ucan2` to did document
* decodeUriComponent to get a data uri
* decode the data uri to get a did document
* assert did document has `controller` property of a verifiable ucan principal (e.g. `did:key`)
* assert did document has a `proof` property containing a proof created by `controller` - (this may not be that important)

how to validate UCANs issued by `did:ucan2:...`
* resolve the `did:ucan2:` to a did doc (synchronously)
* look in the did document `capabilityInvocation` section (it will often contain identifier matching a `controller`, but not always)
* for each verification method in that section (i.e. verification methods with verification relationship `capabilityDelegation`
* determine a `publicKeyMultibase`
* e.g. if the verification method has id `did:key:...`, the `publicKeyMultibase` is the `...`
* e.g. if the verification method is an object whose `@type` is `Ed25519VerificationKey2020`, look at its `publicKeyMultibase` property https://www.w3.org/TR/did-core/#example-capability-invocation-property-containing-two-verification-methods
* if cannot determine `publicKeyMultibase`, continue to next verification method
* if the UCAN signature verifies against `publicKeyMultibase`, the ucan is valid

More:
* resolved did doc (signed by `controller`) can contain more UCANs that are issued by the `did:ucan2`, and, e.g. then that could be used to represent (as ucans)
* contains ucans indicating who can revoke the identifier `iss=did:ucan2 aud=did:key:zAlice can=ucan2/revoke`
* who can revoke/modify/control specific verification methods within the outer did document

Putting it together:
* I want to issue a single ucan that can be re-delegated by any of 2 keypairs keyA, keyB, and invokable by keyA
* So I create a did document like { ..., capabilityDelegation: [`did:key:zKeyA`, `did:key:zKeyB`], capabilityInvocation: [`did:key:zKeyA`] }
* `ucan.issue(iss=did:key:zBengo, aud=did:ucan2:{encodeUriComponent(toDataUri(didDocument))})`
* redelegations `iss=did:ucan2:...` could be signed by either of keyA, keyB. Invocations using last delegation as proof have to sign as keyA

Starts to get fuzzy after that. it feels like UCANs are good for describing did doc verificationMethods. There's some kind of duality there.