search

WebOfTrust / ietf-did-keri

KERI DID Method
Apache License 2.0
6 stars 4 forks source link

KERI related did methods did:web, did:webs, did:keri #10

Open pfeairheller opened 1 year ago

pfeairheller commented 1 year ago

A useful analogy. did:keri is to did:web what https is to http. And there should be about the same level of effort to step up from did:web to did:keri. Let's people start with the easy way, but people will quickly transform to using the secure way because they remember http/https.

Instead of did:keri, we call it did:webs and push that analogy. From a marketing perspective it’s better - not named for KERI, but powered by it. Clean slate in some circles.

SmithSamuelM commented 1 year ago

So we will support three did methods?

I think there should always be a did:keri because its recognized now and will gain more recognition over time. But having a more secure version of did:web that is a limited version of did:keri makes some sense also. Not sure.

pfeairheller commented 1 year ago

Yes, that makes more sense to me. All three methods, we are defining the last 2 here. did:keri includes the did:webs approach but also the super watcher variant. did:webs is just the variant with the domain name.

pfeairheller commented 1 year ago

So maybe we need a did:webs repo and all this initial work needs to go there.

SmithSamuelM commented 1 year ago

And if we are really successful did:webs will supplant did:web

peacekeeper commented 1 year ago

I'd like to see all of following variants be possible, is that consistent with what you're saying above @pfeairheller ?

Variant 1: did:keri:<aid>?oobi= -> DID URL gets dereferenced to DID document using "oobi" (or similar) parameter

Variant 2: did:keri:<aid> -> DID gets resolved to DID document using OOBI(s) or super watcher that are either preconfigured in the resolver or passed to the resolver as options

Variant 3: did:web(s):<domain name>:<path components>:<aid> -> Resolved just like did:web with additional KERI verification logic happening