a DID method spec for did:webs
Home Page: https://trustoverip.github.io/tswg-did-method-webs-specification/
License: Other
A spec for the did:webs DID method.
The spec is written in W3C's respec format using DIF's Spec-Up Tool. To browse the spec, see the rendering on github pages. To contribute to the spec, submit PRs that modify the .md files that are used to generate the .html files in this folder.
Before submitting a PR, please see the Editing The Spec document for guidance on generating the specification locally for review.
I think the spec would be better by referring to the did document file as did.json and the verification resource as did.keri
In last Friday's meeting we detailed several ways that a resolver reference impl could verify the did.json file.
In order to generically reference in the spec what the verification resource will contain, I suggest we use the .keri extension to refer to all of the keri KELs/TELs needed to verify the did document.
That's because did:webs could be retrieving resource from a web server like github and/or doing asynchronous oobi resolution and/or using watchers and/or a local db/cache to get the KELs/TELs necessary to verify the did document.
I attempted to rewrite this paragraph, but didn't understand it clearly enough to complete this.
It currently reads as follows:
The following blocks contain full annotated examples of a KERI AID with two events, an inception event and an interaction event, some witnesses, multiple public signing and rotation keys and an Agent with the resulting DID document that an implementation would generate assuming the implementation was running on the example.comdomain with no unique port and no additional path defined:
It would be helpful to enumerate each section during the introduction, such as:
The following blocks [in the ?XX?] contain full annotated examples of a KERI AID with 1) an inception event (icp) with ...; 2) an interaction event (ixn) with ...; 3) ....; 4); ... and 5) ...
We need a way to say how "AlsoKnowAs" values are injected into the KEL/TEL, included in the end states of those, and then put into the DIDDoc. The ones we care about are when a did:webs is redirected to a new URL by its controller, so that existing references to the "old" DID are not useless.
did:plc has the concept of a handle or a "pet name" for a DID. That is, a unique name for a DID that can be resolved in some circumstances. did:plc uses that for the human-friendly BluSky identifiers for people/organizations on the BluSky social network. The handle is unique and enforced by the registration of the DID with a authorized entity.
It would be interesting to see if we can add the concept of a handle to did:webs. A purely self-attested name (stephen) would not be sufficient as it would not ensure uniqueness in any form. Perhaps we could use the "AlsoKnowAs" to remove the restriction that a did:webs MUST have the AID as the last part of the name. Any web path could be a did:webs as long as the AID was in the DIDDoc, and the KEL/TEL was available as required by the DID Method.
Since the point of did:webs is to enable the use of transferrable (in KERI terms) identifiers, there is not need to mention non-transferrable AIDs. Or at most reference it as "KERI has non-transferrable identifiers, but they are not relevant in this specification.".
Detail the KERI events that allow did:webs DID urls to be verified
@swcurran @peacekeeper and @2byrds will coordinate.
One of the objectives in this work is to make sure that a did:webs can also be resolved as a did:web, e.g. the following should both be resolvable:
did:web:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7Mdid:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7MPer DID specifications, the value of the "id" property in the resolved DID document must be the DID that is being resolved. In our current design however, both the did:web and did:webs methods look for the same file "did.json" at a path that corresponds to the DID. This leads to the question whether the "did.json" file that is stored on a webserver should contain a did:web "id" or a did:webs "id".
Options how to deal with this:
1. Introduce some kind of query parameter or HTTP header or content negotiation, to instruct the web server to either return a DID document with a did:web "id" of did:webs "id", depending on which DID method is being resolved. This has many complexities and risks I think.
2. Define the did:webs method such that it uses a different file, e.g. dids.json instead of did.json. The contents of dids.json and did.json would be the same, except for the "id" property. This might be acceptable, since we are already envisioning one additional file did.oobi (formerly known as did.kel) anyway, so we would just be introducing two additional files on top of what did:web does. However, this still adds some complexity and raises questions about consistency, and may lead to divergent results between did:web and did:webs resolution.
3. Stick with the exact did.json file used by did:web, and define even in the did:webs method specification that this file always contains the did:web DID in the DID document, to be fully compatible with the did:web method. AND:
3.a. In the did:webs method specification, we also define that at the end of the DID Resolution process (i.e. after retrieving and verifying the DID document), the did:web "id" is replaced with the did:webs "id" by the resolver. There are many other DID methods which have similar processes, i.e. where the DID document that is stored somewhere is not the "final version" that comes out of the DID Resolution function. OR:
3.b. In the did:webs method specification, we define that the DID document is actually generated by the did:webs resolver from the did.keri resource (which contains the KERI event stream), and then verified to match everything in the DID document that is retrieved from the web server, EXCEPT for the different method name. In other words, instead of first retrieving the DID document and verifying that it matches the KERI event stream found in the .keri resource, we first retrieve the .keri resource and verify that it matches the DID document, EXCEPT for the different method name.
3.a. and 3.b. have in common that on the web server side, everything is 100% compatible with did:web. The difference between 3.a. and 3.b. is only the did:webs resolution process, the end result is the same.
The strongest verification method available to an AID controller is to anchor a seal of the hash (SAID) of whatever is to be authenticated. This is stronger than merely signing because the anchor binds the authentication to the key state and an attacker can't later create an anchor with compromised keys from an earlier key state.
So the open question is how to indicate in the did doc that anchoring seals are a verification method .
In a sense, an anchoring seal is similar to an Indy state proof but more granular. Or similar to an Indy Attrib record update but again more granular.
In order to potentially support many key types, it may be easiest to just use the general JsonWebKey2020 or MultiKey types for all verification methods in the DID document, instead of using more specific ones such as Ed25519VerificationKey2020.
E.g. see this sentence:
https://github.com/dhh1128/did-method-webs/blob/9c540269e87bcf47a2189bed2df5daa1973cd9ca/spec/diddocs.md?plain=1#L134
This a general comment but still an important one: while the spec document contains most of the necessary material, during my review I felt as a whole it needed significant refactoring. This means three things:
One specific editorial recommendation for to the third point above: make all normative statements "human-addressable" within the spec. This means that wherever the spec has a normative statement, do one of three things:
Following this rule, 100% of the normative statements contained in the spec can easily be referenced by:
From @swcurran I would suggest that there should not be KERI service endpoints in the DIDDoc. Anyone that wants to use the additional features of KERI can get the endpoints from the KEL/TEL. I would push against adding the list of the roles for KERI into the spec, or any reference to BADA-RUN. That is all in the KERI spec.
As the spec changes the generated did document from the KERI Event Stream might also change, making older did documents non-verifiable by the newest spec. How should we handle versioning/generation/verification?
Using the KEL, this DID method can nicely support a history of DID documents. The value of the versionId DID parameter could be a sequential number, or a KERI-specific way of identifying a "version of the KEL".
Supporting versionTime may be harder. According to PhilF:
KERI events don't have time associated with them per se, but implementations store their own local "first seen" date/time for each event. We could use that, but it gets tricky if the host of the DID Doc is the controller and the events are seen by a watcher that could be at some time after they actually occur
Research the DID Spec to see if/how multi-sig and thresholds are handled in DIDDocs. Can they be expressed?
Suggestions on the DIDDoc section:
I just sat down to read the specification as true HTML after a long time being down in the details, and I found myself feeling put off by the terminology section.
This is NOT because terminology isn't good, or needed. I know that a lot of work has gone into getting it into its present state, and I don't really want to change its content. I also understand that careful definitions are the foundation of clear communication. However, as a reader, I found myself taking the perspective of someone encountering many of the ideas in this DID method for the first time, and I found that running into technical definitions (beginning with ACDC, autonomic identifier, and CESR) before I encountered the overview material (how to recognize a DID in this method, how this method stores DID docs and supports CRUD operations) was confusing. I think it could also backfire, politically. We will have readers who come from a did:web background, and who need to feel this method's similarity to those concepts that they know; instead, we throw them into very deep water and overwhelm them with dense, unfamiliar, low-level details before they get the high-level concepts.
What I'm wondering is if we can find a way to bring the reader to the high-level concepts first, before they see glossary-like material. For example:
I know it is common to put terminology up front, and that some standards orgs require this. DID Core has a terminology section before the heart of the spec. However, all uses of terminology are always hyperlinked, and we can even provide hovertext, so a term is never really used without providing its formal definition. Given that, the classic approach of defining terms first seems unnecessary.
If you read that RFC thoughtfully, you will see that the section doesn't attempt to define every term/concept; it truly defines only the core ones. And it doesn't do so with a glossary; it does so through exposition. It is teaching, not just providing a reference. In our spec, "ACDC" is a supporting idea rather than a core concept, but because we have a generic terminology section, and because it sorts first alphabetically, and because we are defining rather than teaching in a broader sense, we run into this definition first. If we had a "Terminology and Core Concepts" section, we'd teach the core concepts, and introduce the terminology as we did so. We would still need a glossary, and the glossary would need to include more terms than we introduce in this section, but the basics could be learned from the exposition. (Of course, a drawback of this approach is that it takes a lot of editing. Maybe it's too ambitious.)
Recognizing how our terminology breaks up the flow for certain readers, we could simply insert a small statement at the front of it: "Careful definitions are foundational to a full understanding of this specification, and it's traditional to include them at the front of a specification. We provide them here. However, many readers may find it easier to skip ahead to the Core Characteristics section, and learn terms as they encounter them in context."
Alignment is needed with the current current ToIP Glossary (Google Doc).
We need to determine what is helpful for the did:webs specification and what is overkill. We don't want to duplicate the ToIP glossary but there are terms in the specification that require ready access to definition.
Originally posted by daidoji December 20, 2023
To be compatible with did:web and did-core I added this PR to match did:web. #114 for did:webs
However, due to KERI and AIDs in general mitigating (in theory) a lot of the issues that make homograph attacks possible we could explore future versions of this spec that provide explicit canonicalization schemes for unicode domain names without losing our compatibility to did:web. Not sure how feasible or if everyone thought this might be in scope (probably not for this current edition of the spec we're trying to get out) but thought I'd open the discussion as a placeholder for anyone who may be interested in the future.
Should a Key Agreement key example be included?
@swcurran asked several important questions in another PR, about service endpoints in did:webs and the corresponding keri service endpoints. This issue will be resolved with a PR that details did:webs service endpoints, and accurately describes the KERI events related to service endpoints.
Original spec text:
"In KERI, service endpoints are defined by 2 sets of signed data that follow the Best Available Data - Read, Update, Nullify ([[ref: BADA-RUN]]) rules for data processing. The protocol ensures that all data is signed in transport and at rest and versioned to ensure only the latest signed data is available."
Questions from Stephen:
#46 (comment)
I think this should this be “In did:webs service endpoints are defined by 2 sets of signed data using KERI’s Best…."
#46 (comment)
Is this the same for all services in the DIDDoc, or just the KERI services? If just the KERI services, I think it should be in the next section, with this intro section covering all DIDDoc services.
A simliar recommendation to @dhh1128 's comment in #97 about the document not getting to the key points.
I recommend updating section 7 so that it gets to the point, and is used as a place to explain how to actually create and update a did:webs.
The reordering suggestion is to move the current 7.6 DID Method Operations up to immediately after 7.3 Target System(s), moving the Equivalent Identifiers and Handling Web Redirection (which are edge cases -- important, but not fundamental).
The detail to be added is to the Create and Update subsections to describe how to create and update a did:webs DID. I think the following operations should be covered:
At this point, I don't know how those actions are carried out, nor where to look to find out.
Would it be possible to explain those operations without referencing all of KERI?
This is a minor issue but one we should probably clear up before publishing.
All the examples use the legacy string format version and not the Version String to be published with the specification.
As per trustoverip/tswg-keri-specification#120 I think we should only publish examples using the updated version string format and leave the legacy version strings unmentioned as these are new specifications and although there are production deployments, these are small enough that new implementations based on these specifications shouldn't need to implement the legacy string version information.
(Note that this holds for both KERI and ACDC version strings)
Let me start off with stating that I really like the did:webs idea and I am impressed with the amount of work that has gone into it so far.
The specification is currently fairly non-normative. Right now there are far too many references to draft specs and terms that don't close the loop on definitions. I am pushing a PR that starts to close off some of the approach but I wanted to raise the issue here for broader discussion.
The pattern I see is that we have two intertwined issues:
I could have raised this as two issues but I believe the problem is how these two tie together.
DEFINITIONS
My PR (#113) tries to unravel a gordian knot of terms that aren’t coming to completion. Part of that is helped by adding the ToIP Glossary of terms, which is intended to be normative. I think this should help. We have taken an action items to convene the TSWG chairs with the CTWG crew to see how we can reach rapid alignment.
KERI ONLY
While I get that KERI has a solution for did:webs I believe we should leave the door open for other solutions.
If we can support others, then examples need to be characterized that way. There is work required to get to that point:
If there is only one way to do did:webs and that is KERI, then, at a minimum, we need to make KERI easier to approach. We should make the approach to KERI as simple as possible and explain only the parts/components of KERI that are required. This may mean a visit with the various KERI-suite spec writers is needed.
As an example, the KEL is clearly required, but a “KERI Event Stream” can have any number of things in it. What is mandatory for did:webs support?
Further, can we rename KERI Event Stream to something more general (e.g. Key Event Stream)? This supports the same concept as above - concept/concrete - though the dual use of K- to start the acronym could get confusing fast.
Probably a small thing but wanted to note it in case we cared.
The ABNF method in section 6.2 is not a full ABNF specification.
The did:web spec doesn't specify the ABNF of the method fully either, preferring to use an ABNF like psuedo-code that is probably okay I guess and omit the reference to ABNF completely. https://w3c-ccg.github.io/did-method-web/#method-name we probably copied it from there in the creation of our document.
That being said, we did add the ABNF reference qualifier statement to our document so we should probably either:
domain-name, aid, path in the correct ABNF form) as well as not defining webs-did twice (which I (@daidoji) is glad to do but its too late at the time of this issue's creation)did:web and use the hand-wavy definition which is probably all right because we define all these things clearly below in the document. We would then delete the reference to the ABNF spec and move on with our lives.Either is fine by me but I wanted to note it for precision's sake.
We have been making a lot of use of the term "KEL" for the file that exists beside the DIDDoc. However, as we have learned, we think it really needs to be a CESR "KEL/TEL" file. I think that we could use "CESR" as the name, but that is (AFAIU) a generic term for storing any Event Streaming data in a useful way, kind of like JSON is a generic term for storing arbitrary data in a useful kind of way.
Should we stick to "KEL/TEL", "CESR" or is there another name the is tied to KEL/TEL? Regardless, we should update the spec to be consistent throughout so it's clear when we are talking about Key Events, Transaction Events, and the KEL/TEL CESR file that contains those events.
The spec currently says:
DID docs for this method are pure JSON
However, the vast majority of DID methods prefer DID documents in the JSON-LD representation. This includes did:web DID documents I have seen in practice.
Therefore I would also prefer to specify did:webs DID documents in JSON-LD.
This question came up several weeks ago in a call, and was also recently raised in a recent Slack channel question. I thought it worth raising as an issue here, for possible inclusion in a "resolver implementer's Guide".
@SmithSamuelM talked about the efficiency of keeping around key state and processing just the added events when necessary, vs. always processing the event log from scratch to prove verifiability.
My understanding/expectation about this is that a resolver will retrieve and process the KERI log set of events, which in turn will produce interim and a final DIDDoc. As well, the DIDDoc corresponding to the KERI log will also be published on the web server and can be retrieved directly — and verified against the derived one (from the events).
Given that the KERI event format is append only, I think that it should be possible for a resolver to:
Is that technically possible?
Is that implemented such that a resolver could use that tactic of using cached data in the processing of commonly resolved, frequently updated KERI identifiers?
We have defined def: throughout our documentation, and then also started to do it in terminology.md. Recommend we either shift every def: to terminology.md or distribute the terms out of terminology.md and remove it.
Note there is an open PR for the terminology.md that lead to a flurry of comments #66
Add a section section to spec if we decide yes.
In the AID Value Section in did-method-webs/spec/diddocs.md, it says " If the AID is non-transferable (does not support key rotation) the AID is generated by taking a cryptographic digest of the first (and only) public key of the identifier."
If I understand correctly, a non-transferable AID is the same as its public key, not its digest.
From our 2023 August 31 meeting, Sam discussed:
This is a core concept/feature of identity and scalability in KERI. @peacekeeper are you aware of a cooperative delegation (two DIDs specifying a delgator/delegate relationship) implementation in the DID-world? In KERI this allows, for instance, the ability to delegate an AID that can issue credentials on your behalf. That make horizontal scaling and other desirable features for bulk credentialing, etc. Lets discuss possible ways.
In spec/keri.md in the "Derived from Public Key" section, 2nd paragraph, it says
"The simplest AIDs (called [[ref: direct mode]] AIDs in KERI) have no additional input to the derivation function, and expose a degenerate KEL that can hold only the inception event."
In my understanding, the simplest AIDs are non-transferable AIDs without any witness. AIDs in direct mode can still be transferable and is thus not necessarily the simplest.
The key state for the did:webs DID provided in a did:webs didDoc is verifiable against the keri.cesr file because the keri.cesr file includes the key event log (KEL) for the AID portion of the did:webs DID.
An attacker may create their own AID and associate it with the same DNS domain name as some other did:webs DID (but differ in the AID portion). They could use this to give the false impression that they represent the entity that is supposedly the controller of the domain name common to both DIDs.
did:webs by itself does not prevent such an attack. The attack is not attacking the control of a given did:webs did but is attacking the control of the domain name common to both did:webs dids. A given did:webs DID is controlled by the key state associated with its AID not its doman. A related attack is when the didDoc includes service endpoints or other information that is not part of key state or is not anchored to key state. This attack will be discussed below.
The root-of-trust for any did:webs DID is the AID in the DID. There are many ways to impersonate the controller of a given domain name or web host. This is the primary vulnerability in did:web that did:webs fixes because spoofing control of a did:webs DID (unlike a did:web DID) requires compromising the keys that control the AID in the did:webs DID.
A did:webs didDoc that does not have the correct did:webs DID for a given key state will not resolve given a compliant (trustable) DID resolver because the resolver verifies the key state w.r.t to the AID in the associated did:webs DID against the KEL provided in the keri.cesr file. The keri.cesr file provides a hash chained signed proof of key state. Control of the full did:webs DID which includes the AID is thus protected. One can't spoof control of the full DID without compromising the private keys in the KEL.
To elaborate, anyone can create their own AID and then create a KEL and then create a keri.cesr file from that KEL and then create a did:webs DID with the AID for any domain name they choose. A didDoc that provides the key state from by that keri.cesr will resolve. The did:webs resolver in that case is only verifying that the key state provided in the did:doc is consistent with the key state in the keri.cesr which will prove the key state for that AID (at a given point in the KEL). This does not in any way prove that the domain name is controlled by the controller of that AID. That requires a different type of proof.
The only way for a user to know that a given AID is under the control of a given entity is via a out-of-band exchange of information that binds the AID to that entity. This includes binding that AID to the entity that truly controls a given DNS domain name. This could be done in many ways. Given that we are assuming that the dns/ca system itself is insecure. We can not merely trust that the appearance of a did:webs DID (with its AID in tow) on a web host of the did:webs' domain name makes a secure binding between the controller of the associated AID and the controller of the associated domain name.
For example, in GLEIF's case, the binding between GLEIF as a legal entity and its root AID is secured by multiple attestations under domain names or other identifiers that either GLEIF controls or are controlled by trusted entities that control GLEIF to that AID. (see the vLEI ecosystem governance framework). This set of multiple links provides a multi-factor out-of-band mechanism for binding GLEIF as a legal entity to its root AID.
As mentioned above, a related attack is to spoof other information, besides key-state, by providing that other information in a didDoc for a given did:webs DID. Any information not provided in or anchored in the KEL of an AID is not directly verifiable against the keri.cesr file so some attacker could place that information in a did:webs didDoc and purport that that information is valid.
There are several ways to protect against such attacks.
Provide a "strict" mode for did:webs resolution that only includes KEL anchored data in the did:webs didDoc. A compliant resolver in strict mode never includes anything but KEL anchored data. Primarily this is key-state, witness AIDs which embed witness key-state, and config traits. Please note that other information anchored via a seal is not directly observable and hence verifiable by the resolver merely with only key events from a KEL in the keri.cesr. That information, however, could be provided via attachments to the KEL which attachments are also included in the keri.cesr file.
expand the resolution to normatively look for anchor seals and attachments that expose the contents of the seal hashes when those attachments are included in the keri.cesr file. Then in strict mode a resolver can include the seal anchored information in the rendered didDoc. This information is thereby verifiable.
expand the resolution parametrization to normatively allow for the inclusion in the parameters of exposed anchor seal contents that are dynamically (at resolution time) merged with the keri.cesr file to include such anchored content in the rendered did:doc
Protect unanchored information such as service endpoints using BADA-RUN on the service endpoints. There are several ways to approach this.
To summarize, there is a rampant misunderstanding that merely signing a document makes the contents securely attributable to some entity when that signature verifies. Signatures attributed to persistent identifiers (which support changes to their controlling key state) are invalid once the key state changes. The signed data must also be bound to the key state of the identifer at the time the signature was created. This, indeed, is one of the major, if not the major security vulnerability in the DNS/CA system. Domain names are persistent identifiers whose controlling key state may be changed by the issuance of a new Cert from some CA (usually any CA). There is no way in the existing DNS/CA system to bind signed data to the actual key state at the time of signing in a verifiable way. Recall that the main reason to change key state (rotate) is to protect from key compromise. Thus any stale signatures from state keys must be assumed to be compromised signatures unless the signed data is anchored to the key state in such a way that later key compromise is prevented from making new anchors.
Consequently, without key state anchoring, only the latest key state should ever be used for verification and because it is possible to miss-issue verifiable certs from multiple CAs there is no cryptographically verifiable way to establish the one and only one latest key state. Certificate Transparency will tell a verifier that are multiple valid key states but not which one is the truly valid one.
In the did:webs case, the underlying KEL in the keri.cesr file provides cryptographically verifiable proof of the key state at the time any data is anchored to the KEL. Because the events in the KEL are signed with a post-quantum protected forward and backward chaining mechanism related to key state (pre-rotation), then any anchored data is also verifiably bound to the key state at the time of its anchoring event. It is effectively signed by virtue of its anchor. Recall that signing a cryptographic strength digest of data is equivalent to signing the data directly. Signatures on the anchored data are, at best redundant and at worst may be misleading because they are weaker than the anchors (by virtue of being unbound to key state at the time of signing) and therefore should be ignored.
The did:peer discussion is not relevant, and should be removed.
While the did:peer DID Method is extremely important, and one we should promote, the idea of “dynamic peer” DIDs has been dropped in favour of using (when needed) DID Rotation in DIDComm. did:peer numalgo=0 should probably never have been introduced, as it is the (logically, at least) equivalent of the better known, commonly used and sufficient did:key DID Method. numalgo=1 in theory permits key rotation, but in practice is well-under specified, and as such has never gained momentum. did:peer:2/3/4 are far more useful and have a future, but don’t support dynamic keys. However, they do support service endpoints and multiple keys, so a “transformation” into did:webs is much more challenging.
I would support removing the transformations section entirely, as
At minimum, we need to remove the did:peer section.
I'm thinking as I'm writing this that the pre-rotation keys commitments don't need to be in the DIDDoc at all. If anyone is interested, they are available in the Key State, and are used in the KEL processing to get to the Key State.
Leaving this issue in so we can talk about it.
The specification already mentions the use of the alsoKnownAs DID document property, which is good.
We may also want to mention the equivalentId metadata property, which has stronger semantics than alsoKnownAs. equivalentId is specifically meant to be used for same identifiers within a single DID method, i.e. did:webs in this case.
For example in this sentence:
From our 2023 August 31 meeting, Sam/Phil discussed:
The did doc publisher should be under the authority of the controller(s) of the KEL/AID (or perhaps a delegated AID of the contorller). We would not want an unauthorized non-controller (random or nefarious) to be regarded as a legitimate publisher of a did:webs did document.
We should go over mentions of the SSL/TLS common name and think about what we want to require there.
For example this part: https://github.com/dhh1128/did-method-webs/blob/9c540269e87bcf47a2189bed2df5daa1973cd9ca/spec/diddocs.md?plain=1#L91
But the common name should probably only be the domain-name part of the method specific identifier, not the entire method specific identifier.
This is taken from the did:web spec.
I want more people credited on this spec than who the spec currently mentions. This is A) 100% true; and B) politically desirable. Would people mind if I submitted a PR putting other names in -- and if not, who wants to be an editor vs. a contributor?
Tagging a few people who might need to be named. @2byrds @m00sey @peacekeeper @talltree @nkongsuwan @SmithSamuelM
per #123
I have a negative reaction to this statement: "The fully qualified domain MUST NOT include IP addresses" which occurs here. I wrote the first draft of this particular section, and I remember copying this sentence from the did:web spec, so I assume that's why the sentence exists. In did:web, it was justified by the idea that security was tied to certificates, and certificates wouldn't be issued to IP addresses. Thus, having a FQDN that's an IP address would introduce unnecessary caveats to the method.
This is not true of did:webs. We lose no security by allowing a FQDN to be an IP address, and we gain quite a lot of flexibility. In a world where IPv6 is ubiquitous, that flexibility might be valuable. We could publish did:webs docs on a mobile phone, for example.
The counter argument that I'm aware of is that we want to keep this sentence so did:webs and did:web remain as similar as possible. That is, we want to prevent did:webs DIDs from being published in places where did:web DIDs can't also be published.
This feels irrational to me. Any places that are capable of publishing a did:web DID can also publish a did:webs DID, so being more flexible in did:webs sacrifices zero in terms of an upgrade path. And we are trying to provide a one-way upgrade path, not a two-way equivalence, are we not? What the flexibility does sacrifice is the guarantee that every did:webs can also be viewed as a did:web; there could be corner cases where that is not true (that is, the equivalence is not perfect in both directions). But those corner cases are unlikely to be interesting to people who want did:web support, anyway (who would try to publish a corporation's did:web/did:webs on a cell phone running IPv6?).
My preference, therefore, is to simply remove this one sentence.
If the will of the team is to keep it, because of the compatibility argument, then my fallback recommendation is to at least justify the sentence with an explanation: "To maximize similarity with did:web, which depends on certificate security, the fully qualified domain MUST NOT include IP addresses."
The Security Characteristics seem (from my reading) to be targeting those familiar with KERI and its not clear to me what the relevance of the "Concepts for securing did:webs informationtodid:webs. Admittedly, the definitions for KEL Backed DataandKRAMare not yet linked. But the line to connect those concepts todid:webs` security are hard to follow.
What about writing that section from the perspective of the "Common Security Threats" list. How does (for example), did:webs mitigate denial of service or key compromise attacks?
I think the answer comes back in many cases to -- if the KERI Event Log is verifiable, all is well. But how for the different cases? And in the cases where the KERI Event Log is not the answer (e.g. DOS attacks), what is the answer?
Per the 2023 August 31 weekly meeting, Stephen discussed:
We need to document in the spec the events a controller of an AID will follow in order to publish their did:webs did doc. The base information was started in the did document section PR.
We will use keri.cesr instead of did.keri to indicate that application/cesr is the mime type of the KERI event stream
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.