André Cruz

I've updated the RFC where I mistakenly said the the Session Private Keys where generated and stored on applications side. It's now clear the the Session Private Key securely lives...

Copy pasting to be easier to discuss: > Next, in step 4, Alice retrieves her authorization from the Guest-list. She decrypts the message using TemPrivKeyDoc-Alice, and extracts the documents read...

Like @diasdavid said, we may change a few knobs to increase security while decreasing usability and the other way around. Having a password combined with Alice's keys will increase security...

Regarding compromised keys: > To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all...

> So, in this scenario, everytime two entities interact which each other they would have to reauthenticate themselves? Alice sends me a message, I once again verify her DID-Document to...

> In this case the address book would only need to contain DIDs with verified identities (the manual process through which a user verifies another user's proofs of personhood) and...

I'm happy to do a PR if this is indeed a bug and if you agree to use `tagPrefix` in there. One thing that I would prefer in my case...

An identity, represented by its DID, should be able to prove its authenticity. To do so, the identity might disclose a set of claims that can then be verified by...

@EvanOxfeld turns out that sometimes weird things arrive to the readable-stream: ``` null { buffers: [], length: 0 }

I would like to understand if these pages get queued or if they are simply discarded. Also why does this happen in first place? Is it because of api rate...