Comments (3)
There should be a section that points to how to process the KEL to get to the Key State from which the DIDDoc is derived. Presumably, that is another spec, with implementations?
Yes, that's in the KERI whitepaper. I suggest we simply hyperlink.
Does there need to be a similar section on the "TEL" that talks about processing the TEL to get to ?? and then how parts of that data model are pulled out to populate the DIDDoc?
Yes, another hyperlink.
The section "AID Value" has much that is repeated from the core section -- notably how the AID is used in the DID identifier string. That should be removed.
+1
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.
+1
I think the "did:keri" example should be removed, unless someone is also defining a did:keri method.
+1
The fact that keys are converted from KERI format to DIDDoc format should be mechanical, perhaps with a list of transform types. E.g., there should be a generic -- conversion approach, and then Ed25519 and Secp256k1 examples.
I'm not sure we should convert. CESR encoding avoids all the cumbersome, verbose, and clunky, semi-bespoke encodings used in other approaches. We would be more interoperable to do what Stephen says, but we would also be signing up to maintain and upgrade the spec as the world keeps releasing new encoding tweaks. Interesting tradeoff. No strong vote. I'm just sayin'...
Should a Key Agreement key example be included?
Yes.
The "verification relationship" should be expressed from a DID concepts perspective vs. a KERI one. I think it is pretty typical in DIDDocs to add those items to the DIDDoc.
Yes. However, I think that KERI's mental model of the thing that DID theory calls "verification relationships" divides the conceptual space differently. For example, it has a verification relationship that is about key rotation only, and IIUC it conflates authentication and general signing. So I think it's unavoidable that we acknowledge the difference to some extent.
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.
Yep.
We need to add how a DIDComm Messaging or some other non-KERI endpoint get into the KEL/TEL and DIDDoc.
+1
from tswg-did-method-webs-specification.
I'm willing to contribute PRs for some of these, once we clarify whether there's consensus on them.
from tswg-did-method-webs-specification.
I have accounted for these suggestions in my current PR work (includes other suggestions from Stephen from another PR)
Or I have created new issues.
Created granular issues to address these:
#52
#51
#53
#54
#48
from tswg-did-method-webs-specification.
Related Issues (20)
- Reorder section 7 to emphasize the DID Method Operations and add Create/Update details HOT 5
- Security Characteristics are difficult to relate to did:webs HOT 2
- ABNF definition of method in section 6.2 not a full ABNF specification HOT 1
- Terminology needs to be aligned and KERI only question (related) HOT 10
- International and Unicode domain names
- Too much informative text; normative requirements not clear enough HOT 2
- Glossary Terms - ToIP & did:webs alignment HOT 3
- KERI Version strings all legacy in example jsons
- State document conventions regarding normative statements, informative statements, etc.
- Request to add did:webs to the DID method registry HOT 1
- Align blog post with Muggles session HOT 1
- attribute more contributors or editors HOT 2
- Direct mode AIDs are not the simplest, are they? HOT 1
- Discuss spec versioning and did document verification
- Spoofing did:webs didDocs HOT 7
- Cleanup defs and/or terminology.md HOT 4
- Remove the “Transformations” section, or at least the “did:peer” part of it HOT 2
- Full Example section paragraph is difficult for a newbie to parse and match with JSON HOT 2
- Can we shift or somehow de-emphasize the terminology section? HOT 4
- why must FQDN not include IP addresses? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 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.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
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.
from tswg-did-method-webs-specification.