Re: Question: Can DID Documents define permanent email addresses?

I have to run right now so two quick pointers:

   - DID-to-DID comms is the focus of the Hyperledger Indy #agent channel
   <https://chat.hyperledger.org/channel/indy-agent>—you can dive into it
   there.
   - Another DID-to-DID comms options is XDI
   <http://www.oasis-open.org/committees/xdi/>, a semantic data interchange
   protocol under development by a small group at OASIS. Check out
more at Markus
   Sabadello's open source XDI2 project
   <https://github.com/projectdanube/xdi2>.


On Sun, Mar 11, 2018 at 9:37 PM, John Toohey <john.toohey@dominode.com>
wrote:

> DID to DID comms are intriguing. Can you elaborate on that or point me to
> some discussions on it? Thanks.
>
> On Mar 11, 2018 21:19, "=Drummond Reed" <drummond.reed@evernym.com> wrote:
>
>> Steven, yes, actually one of the great advantage of DIDs is that they can
>> provide lifetime connections between people, orgs, and things that can
>> persist no matter how often the DID subject changes service providers of
>> any kind (email, phone, physical mail, etc.)
>>
>> The exact mechanisms may vary, but the general algorithm is:
>>
>>    1. Once assigned by an identity owner to a new connection (which can
>>    be pairwise pseudonymous), the DID for that relationship never needs to
>>    change and the connected party can always look up the DID on the
>>    relevant blockchain to obtain the current DID document (unless, of course,
>>    the DID has been revoked, which only the identity owner can do).
>>    2. The DID document will contain one or more service endpoints (which
>>    can also be pairwise pseudonymous) providing discovery, contact, or
>>    messaging services for the DID subject.
>>    3. The connected party (the entity to whom the DID was assigned) can
>>    use DID Auth for their own DID to authenticate to the appropriate service
>>    endpoint to initiate communications with the DID subject.
>>
>> This approach could of course be used to discover the identity owner's
>> current email address, however IMHO the whole concept of using DIDs to
>> discover email addresses (or phone numbers or other legacy addresses) will
>> over a few years give way to using DID communications channels directly,
>> i.e., why use email when you can do encrypted DID-to-DID messaging or
>> streaming?
>>
>> Yes, I've swallowed the Kool-aid, but I believe DIDs really are "the
>> address of the future".
>>
>> =Drummond
>>
>> On Sun, Mar 11, 2018 at 8:25 PM, Steven Rowat <steven_rowat@sunshine.net>
>> wrote:
>>
>>> Greetings,
>>>
>>> Could some combination of DID Document, Method, and Services allow the
>>> entity that has the email (and aliases) to define those in a central place,
>>> ie the DID Document, and then merely point to the current server for them?
>>> So if the server changes, the email address doesn't have to? And so all the
>>> correspondents of Entity X will never have to know, and can still
>>> communicate with Entity X by the same email address, forever (or until
>>> Entity X wishes to change it)?
>>>
>>> This seems like it would potentially be a big advance on the current
>>> system, which is either:
>>>
>>>  A. ISP based, so the email address must change if Entity X moves to a
>>> different ISP;
>>>
>>>  B. Cloud-based, so the Entity X is tied to [Google, Microsoft, etc.]
>>> who handles their email, and must change their email address if they wish a
>>> different provider;
>>>
>>>  C. Own domain (EntityX@EntityX.com) which is possible but somewhat of
>>> a pain to set up, especially for the 99% of the Internet who don't know
>>> what a server is (see: https://konklone.com/post/take
>>> -control-of-your-email-address for how that can be done).
>>>
>>> I haven't seen any mention of this on the list or DID discussions, but
>>> it seems like it would be a good thing to have if it's possible;
>>> potentially a simpler method, or at least one that the entity has control
>>> over.
>>>
>>> ?
>>>
>>> Steven
>>>
>>>
>>>
>>>
>>