Orie Steele

This can be reproduced by following these instructions: https://supabase.com/docs/guides/self-hosting/docker

see https://www.w3.org/TR/did-core/#verification-methods Doing this without considering the larger standard would harm interoperability. If you want to rotate keys frequently, you can use `service` endpoints. See https://www.w3.org/TR/did-core/#services For example: ``` {...

Another alternative would be to define a new verification method type, here are some examples: - https://w3c-ccg.github.io/lds-jws2020/ - https://w3c-ccg.github.io/ldp-bbs2020/ - https://w3c-ccg.github.io/lds-ed25519-2020/ But its not clear to me what "relationship" an...

cc @selfissued since we have talked many times about "non standard" verification methods, what are your thoughts on this.

I do think committing a decentralized identifier to an external authentication service controlled by someone other than the did controller raises questions about decentralization and security... but they can probably...

Another solution would be to use a VC for this, and not publish a service endpoint or verification method associated with ephemeral keys to the did verifiable data registry at...

Or it might be better to just use a did method like `did:web` where updates (key rotations) are cheap, and its already centralized so there is no real "loss of...

Here is a thought… Your did method can define resolution in terms of service endpoints… so this is a legal way to resolve a did document: ``` did document =...

> A DID document can express verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interactions with the DID subject or associated parties. https://www.w3.org/TR/did-core/#verification-methods...

@selfissued if you have a chance to review, I recall you had opinions on GDPR / privacy guidance.