Portable DID Doc's potentially out-of-date with networked Doc

[KendallWeihe]

Originally raised here decentralized-identity/web5-rs#211 (comment) but creating a dedicated ticket here as this'll concern all SDKs. Copy pasting relevant comments:

What happens in the following case:

1. Create a did:dht
2. Export it as a portable DID (which includes the DID Document)
3. Update the did:dht (as in, update the DID Document in the network)
4. At this point, what's in the portable DID's Document is different than the Document persisted in the network
5. Instantiate a bearer DID from the portable DID
6. At this point the developer has an out-of-date DID Document in their bearer DID instance

I think we should consider removing the DID Document from the portable DID type and instead resolve upon each instantiation (upon each "import from a portable DID"). As I see it, if we want to create a dedicated type for portable DID's then that type should merely consist of:

{
    "uri": "did:dht...",
    "privateKeyJwks": [...]
}

And then from @mistermoe

aye we definitely chatted about this during the design phase of portable did. @frankhinek do you remember our rationale for choosing to include the did document as part of portable did?

ah i think i remember. w.r.t. did:dht specifically, it may be the case that a did was created but not published. if so, without including the did document in the portable did itself, fidelity is lost (e.g. on creation, n services were provided to create)

This definitely doesn't negate the issue you've raised @KendallWeihe. The scenario you describe is entirely possible. At the time we decided that it was unlikely and felt that the furthest we should probably go (but didn't in any of the sdks) for the time being would be, on import, attempt to resolve. if resolution is successful, diff the portable did doc and the published did doc. if there's a difference, throw exception

[decentralgabe]

I remain opposed to the idea that we should promote a serialization format for private key materials outside test vectors as it opens the door to bad practices and risk associated with moving private keys (interception, etc).

I made a longer comment here #142 (comment)

[decentralgabe]

also related #124

[KendallWeihe]

I agree @decentralgabe & added a relevant comment decentralized-identity/web5-rs#211 (comment)

TL;DR the only concrete use case (as you state) is test vectors, for which we can generate & serialize one-off (or better yet, could be a web5 CLI feature)