12A/ KERIfying DID Methods & KERI for Interop
KERIfying DID Methods & KERI for Interop
Wednesday 12A
Convener: Sam Smith, PhD
Notes-taker(s): Ajay Jadhav,
Tags for the session - technology discussed/ideas considered:
KERI, cryptography, public/private keys, key event logs, decentralization
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Charles:
Dmitri Z: What is did:un method?
CHarles: Indirect mode - it gets more complicated
Charles: Delegated identifiers and multiple public keys in resolution?
Dmitri: Are there features you want to see other methods assume?
Sam: Being able to easily and interoperably establish trusted communications across methods is the target end state--various ways of getting there
More brownfield approach - bootstrap various existing tech at once
Existing, hardened, legalized crypto > new stuff
Best crypto foundation using today’s hardened tech is KE logging
key event logs and hash-chained microledger
Trust spanning layer for the internet
It is based on the old crypto
Using key event logs, you’re building tooling which is [already] interoperable
Drummond: Indy method evolution - proliferation of variants (indy interopathon)
Pu
One of the key decisions was to use did:indy:subnetwork method
We could reserve a namespace for KERI’s SC identifiers
KERI masquerade
Using KERI for trust basis
As it is agnostic to the namespace
Zoom Chat logs:
From Me to Everyone: Wizards ++
From Dmitri Z to Everyone: wot is this “blockchain” business. will never catch on.
From By_Caballero to Everyone: CAGE FIGHT CAGE FIGHT CAGE FIGHT! (I joke)
From Joe Andrieu to Everyone: =)
From Xavier Vila to Everyone: No you're not ;)
From Joe Andrieu to Everyone: btw, +1 to covering did:un a bit
From Dmitri Z to Everyone: +1
From By_Caballero to Everyone: requirements gathering
From Xavier Vila to Everyone: +1
From By_Caballero to Everyone: if only we had some kind of requirements engineera legendary one, ideally
From drummondreed to Everyone: I know a Legendary Requirements Engineer ;-)
From Joe Andrieu to Everyone: lol
From By_Caballero to Everyone: it undoes did methods if you're not careful
From Me to Everyone: :D
From drummondreed to Everyone: There is an evolutionary path for KERI adoption among existing DID methods
From David Huseby to Everyone: careful, might start looking like IPv6 addresses
From By_Caballero to Everyone: ^ !!!
From David Huseby to Everyone: did:::::::::::::::::::::
From By_Caballero to Everyone: I wanna hear more about that analogydid:indy:deu:nrw:biele:keri:v4:
From Kumaravel N to Everyone: is the session recorded please?
From RuffTimo to Everyone: @Juan halting and then reversing the proliferation of DID methods is one of the desirable outcomes of KERI growth. :)
From By_Caballero to Everyone: ^ in my Bielefeld example, there was only one DID method-- just a very balkanized namespacedeu is SSI4Deutschland (one of the new indy ledgers using the same method)
From drummondreed to Everyone: I’ve suggested to SAM that DID methods that want to incorporate KERI just use the :keri: namespace inside their namespace. Example: did:indy:sov:keri:did:indy:indy:keri:oops, that was supposed to be did:indy:indy:keri:
Ah-ha, it’s autocorrect! One more time: did:indy:findy:keri
From Joachim Lohkamp to Everyone: so the sequence matters… not sure if I understood Drummond correctly saying did:indy:un(keri): so it would be rather did:un(keri):indy:Is that right?
From drummondreed to Everyone: No, it’s putting the KERI identifier namespace INSIDE the DID method namespace.
From Joe Andrieu to Everyone: Drummond, I'm pretty sure it's in the method-specific-identifier, not the method part
From drummondreed to Everyone: So if the DID method name is “did:indy:network”, then the KERI namespace under that network would be “did:indy:network:keri”
From Steve Todd to Everyone: did:un ~ urn, did:indy:indy:keri ~ url?
From drummondreed to Everyone: No, they are both URNs
From Joe Andrieu to Everyone: those DID's all have a method name of "indy" @drummondOh... they aren't dids? They are a URN that uses "did" as a URL scheme?
From Steve Todd to Everyone: But the the latter actually helps you locate the log whereas the the former is a name without any ability to locate the log.
From Joe Andrieu to Everyone: that seems wrong
From drummondreed to Everyone: Joe, those are just the examples I was using. Here’s another one: did:btcr:keri:or did:eth:keri:
From Joe Andrieu to Everyone: yes, the method is btcr
From drummondreed to Everyone: Right, the idea is that KERI can be “tunneled” inside any DID method
From Joe Andrieu to Everyone: the keri part is part of the method-specific identifier, not part of the method (which by ABNF ends at the colon)
From drummondreed to Everyone: Correct. It’s subnamespacing within the method-specific identifier
From Joe Andrieu to Everyone: I'm just correcting the language you used to describe it. I totally agree that any method could use KERI within its method-specific string. That's just not part of the method name.
From drummondreed to Everyone: Sorry, I didn’t mean to imply that the subnamespace was part of the DID method name
From Joachim Lohkamp to Everyone: Looking at the slide what Sam proposes it would be one: did:keri:ethr: or did:keri:btcr:
From Joe Andrieu to Everyone: the "un" is the method here, which is did:ethr:keri as a pattern
From Joachim Lohkamp to Everyone: I see
From drummondreed to Everyone: Just to clarify, “did:un:” (which I personally believe Sam and the KERI community should call “did:keri:” would be the “native” KERI DID method.I have a question for Sam for how that will work.
From By_Caballero to Everyone: uh.....
From Dmitri Z to Everyone: +1 to drummond - I do think did:keri: will be clearer
From Joachim Lohkamp to Everyone: +1
From By_Caballero to Everyone: could Joe answer that one? :D
From drummondreed to Everyone: So use a DHT as the global discovery mechanism
From Dmitri Z to Everyone: ok but like, DHTs are not panacea, right ; they’re just one tool in the toolbox (with clear engineering tradeoffs)
From David Huseby to Everyone: I have suggested to Sam that a DHT isn't low enough in the stack and that maybe this should be something that runs at the IP level like BGP nodes.
From drummondreed to Everyone: I have to jump to another session shortly, but from my POV, the key questions about the relationship of KERI to DID methods have been answered here. Are there any others that I can help with before I go?
From Steve Todd to Everyone: BGP is pretty analog to a DHT, imho.
From David Huseby to Everyone: @Steve Todd, it isI'm thinking more like how the DHT is built
From Steve Todd to Everyone: And BGP runs on top of the IP layer
From David Huseby to Everyone: if the KERI discovery DHT relies on DNS then it is suceptible to attack
From Joe Andrieu to Everyone: @By_Caballero you mean can did:keri work? Sure. that could be its own meta-method.
From By_Caballero to Everyone: I meant who needs DID methods for anything once there's did:KERI
From RuffTimo to Everyone: ^^ my question as well, other than the path between now and then...
From By_Caballero to Everyone: and Bernhard!
From Joe Andrieu to Everyone: I expect KERI fails when a definitive "current" document is a requirement, but as Sam has pointed out, that may not be a strong requirement for many uses
From By_Caballero to Everyone: ^ This question has come up in multiple places, I'd love to hear some discussion of this point
From Joe Andrieu to Everyone: The biggest rebuttal is that even DLTs like bitcoin never have finality, so the purist in me is trying to be open to the option of having a "good enough" establishment of the authoritative version of the DID Document.You still have to check the witnesses
From By_Caballero to Everyone: Hmm
