8 Jun
2026
8 Jun
'26
8:51 a.m.
On 6/7/26 20:08, Goffi wrote:
It is more complicated indeed, but i think that comes with the
territory. Decentralized ID is not an easy thing to do.
Aside from the algorithm, which we can just generate something, the
problem is to figure out how to discover, verify and make identities
"portable" in some way.
I can't comment whether the XEP way of doing discovery or verification
is private or secure, which is what we get with DIDs. They have had more
scrutiny and more diverse knowledge poured into them.
The part that it is
reinventing is how to do decentralized/nomadic
identities.
The multiple ways of doing authentication i meant that DIDs can have
multiple ways of verifying an identity.
This could help for example movim or libervia in your case by using HTTP
urls or dns for verification, but also fall back to something else (or
multiple) for other uses. For example xmpp pubsub or tor or i2p.
It would also gives us multiple ways of doing said keys with OX and
OMEMO both being possible in the same DID document. From what i see it
could even be used for passwords or doing things to your account.
My concern with temporary solutions, is that they become permanent
really fast. XSF experimental XEPs can and are implemented widely (there
are other threads for that) so conversations about requirments and what
we built are all the more important before we have some proposal ready
to implement.
Regards,
MSavoritias
Hi MSavoritias,
Le mercredi 3 juin 2026, 08:14:44 heure d’été d’Europe centrale MSavoritias
via Standards a écrit :
Ah right sorry i read a bit too fast ^^'
I do not understand why the XEP is locked to
OMEMO and also we roll our
own identity scheme.
This protoXEP is not locked to OMEMO at all, why make you
think that? OMEMO is
only used for the optional automatic private key synchronization feature, and
there is an alternative out-of-band QR code based method specified.
This not really a scheme, it's inspired from existing solution (Peer ID from
LibP2P), and it's simply using an existing widely used algorithm (Ed25519).
This spec simply adapt it to XMPP mechanisms, a thing we would have to do for
any solution. What we can do
instead is use a standard that is well documented and
already exists for this Decentralized Identifiers
I admit that I was not aware of
DIDs, but we could still have to adapt it to
XMPP, and it's far more complicated to implement. The current proposal is
simple and use an algorithm that most client already use.
Also, the prefix byte is made to update to another method if necessary, so DIDs
or anything else could be used in the future. https://www.w3.org/TR/did-core/ this would give
us:
- decoupling of the verification of identity from any centralized entity
and any encryption scheme
This spec does that. The prefix byte is there to not be
dependent on current
encryption algorithm.
I understand that it supposedly strives to not
depend on servers, but
such a thing is not possible yet in xmpp due to DNS reliance. DIDs on
the other hand can support multiple verification methods.
The main DNS reliance is
in the JID. This proposal (again made to be easily
mappable on Peer ID which is widely used) is made to not have to rely on DNS.
- our own xmpp method to resolve things to
- a standardized way to represent this and do discovery, not reinvent
our own
- multiple ways of authentication besides just xmpp pubsub things
This
specification use PEP which is also what is used for OMEMO and OX, and
many other things. It's not reinventing anything. And other authentication
method are planned, notably out-of-band via QR Code.
PEP doesn't have to be the only way, it's just convenient because it has
everything needed.
Again, this is a protoXEP which would go as an experimental specification, made
to test implementation, and see if it works or not, and how it can be
improved. We are not discussing here a move to draft or final. Best,
Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org