appendix text added

[talltree]

Signed-off-by: Drummond Reed [email protected]

This PR includes three appendices explaining three key facets of DID architecture:

1. What Does a DID Identify?
2. DID Controllers and DID Subjects
3. Multiple DID Controllers

---

Preview | Diff

[iherman]

Unfortunately, the preview does not carry over the figures. A the figures are important for the appendix, they can be found here:

https://github.com/talltree/did-core/tree/appendix/diagrams

[jandrieu]

We'll have to have further discussion here.

Identifiers don't identify things.

Identifiers are used after something has been identified to refer to that something.

Please adjust any statement that says "DID identify..." to "DIDs refer to". This adjustment probably needs to bubble up to elsewhere in the spec.

[iherman]

A bunch of editorial remarks:

• Please, use the respec trick of enclosing all subsections into its own <section> resulting in:

  • give a section number
  • get those appear in the ToC.

  The latter feature is important for accessibility, and our document must be accessible.

• I do not know if it is possible to get some clear definition of what the color coding of the diagrams are...

• It would be great if all diagrams were done in SVG with a PNG fallback. I do not think these diagrams would work well on a mobile screen... To put my money where my mouth is, if you have difficulties with the recreation of the diagrams in SVG I can also do it, I have some diagram-creating tools that generate decent SVG.

[iherman]

In fact, again editorially, it would be good to have all these as one single Appendix with sub-appendixes. Seen from the point of view of the overall document, they are pretty much related after all...

[rhiaro]

+1 @iherman

@talltree I can do the section-wrangling to do what Ivan suggests if you like, either before or after any content changes are made (just, probably, not at the same time) - just let me know

[talltree]

@iherman Agree on all your points. After accepting the numerous other suggestions, I will do a first pass on that refactoring. @rhiaro I may very well need your help in further formatting after I get through that refactor.

[iherman]

Just to avoid any misunderstandings, let us not use the word "recommendation". The "Cool URIs..." is indeed a cool document [sic!], but it is only an Interest Group Note (published by the now defunct SW Education and Outreach IG). It does not have a formal status.

(I realize that you have not capitalized the word, but it is still possible to misrepresent it...)

Maybe use the word "guidance"? But I let you find the better term...

[talltree]

@iherman I totally agree and will change the word to "guidance".

[iherman]

I believe the 'Equivalence' (dotted) arc should be symmetric, ie, with an arrow head on both sides. Note that the owl:sameAs is strictly symmetric, and the text refers to it...

[talltree]

@iherman Great point, I will fix the version of the diagram I have, and then coordinate the SVGs with you.

[iherman]

Purely editorial: I think all predicates like owl:sameAs or alsoKnownAs should be typeset as code, i.e., using the <code> element...

[talltree]

Agreed. I will fix.

[iherman]

Maybe it is worth, for laypersons, to have some sort of a reference or some example somewhere else in the document how a multi-sig or m-of-n scheme can be added to a DID document. This is the only case in the appendix where the DID references are not immediately clear based on the core spec itself...

[kdenhartog]

For multi-sig we could include multiple Link Data Security proofs as an array in a document showing the old state and the new state being signed by multiple keys from the old state.

If we want to show a simple threshold option, we could talk about using a Shamir's secret sharing scheme, but from an example perspective there's not a great solution for this because this feature is actually managed at the key management layer. Another example that would be more complicated, but could show good examples would be to use a BLS Threshold signature. However, I don't know of anyone that's got running code to show that working properly and able to produce legitimate signatures with. If we just want some example signatures that don't actually verify I'm sure we could just encode a random string to the proper length and that would work, but we'd have no additional documentation about the LD security suite that would be associated with it because no one has actually created and properly documented that work.

[talltree]

@iherman and @kdenhartog I agree with both of you that such examples would be helpful for the spec. However I don't think this appendix is the place for them vs. someplace in the main body of the spec. If one or more examples are added there, then we can add links to them from here.

[iherman]

We'll have to have further discussion here.

Identifiers don't identify things.

Identifiers are used after something has been identified to refer to that something.

Please adjust any statement that says "DID identify..." to "DIDs refer to". This adjustment probably needs to bubble up to elsewhere in the spec.

I am afraid of getting into a long discussion on how various communities use that term. The PR refers to [RFC3986] which clearly uses the term 'identify things' and that is also the terminology used in the Semantic Web world. We may want to add some notes that goes into the fine prints and distinctions here as used in other communities, but the text is, as far as I can see, conform to the usage in the Web community (Semantic or not).

[jandrieu]

@iherman I can appreciate a desire to align with existing work in this area.

However, in this case, I think it is imperative that we speak rigorously.

First, because decentralized "identifiers" are literally what we are defining. It's on us to be specific about what an identifier actually is.

Second, it's well recognized within the identity community that properly distinguishing relevant terms is vital, for example, using "identity" and "identifier" properly is vital to communicate clearly with each other. We've learned this over a decade of people talking past each other when using these terms. Yes, we try to have grace with folks who inadvertently mis-speak, but when we are writing specifications together, it pays to be accurate.

Third, we, as a group, specifically built our work from this perspective: we are not developing "decentralized identity" a standard, we are creating "decentralized identifiers" as a technology that can be used to facilitate decentralized identity. These distinctions matter to this work.

Fourth, if we don't speak accurately about what a DID "identifies" we will encourage improper mental models of what you can actually accomplish with DIDs. In particular, it is vital to communicate that the binding of a given identifier to anything is outside the scope of DIDs and DID Documents, as per https://w3c.github.io/did-core/#authentication-and-verifiable-claims:

The process of binding a DID to something in the real world, such as a person or a company, for example with credentials with the same subject as that DID, is out of scope for this specification.

Fifth, we need to be absolutely clear as to the security guarantees that are, in fact, provided by DIDs, including the specific limits to those guarantees. One of those limits is that DIDs provide one and only one form of identity assurance on their own: proof-of-control. This is because having a DID, on its own, is insufficient to actually prove that a given subject is the referent. It is only in the context of assertions about that identifier--and the provenance of those assertions--that we can begin to establish confidence that any particular identifier does, in fact, in a specific context, relate to a given individual. Having established that confidence, we could then accept that we have identified the subject, based on the evidence before us. But DIDs played just one small role in that evaluation.

Sixth, the more we say things like "DIDs identify subjects"--and especially the more we say this is a "permanent binding" the more that developers, regulators, and even judges are going to interpret DIDs as permanently relating to specific individuals. And that will run us afoul of GDPR and other regulatory problems.

Seventh, I'll note that global identifiers are one of the core problems that the semantic web handles poorly. I don't want to get into that sideline, but I could go on for quite a bit. But that is perhaps better suited to a less formal context.

DIDs are used to "refer" to entities. They do not, on their own, "identify" those entities. Even with the DID Document, herd privacy means that we should NOT be able to distinguish one DID Subject from another simply from the content of the DID or its Document.

[talltree]

@iherman Just a quick note that I appreciate all of your editorial suggestions and will incorporate them as soon as I can get to my next sustained writing block (which is often weekends these days). I may be back to you with a few further questions.

[talltree]

@jandrieu While I appreciate your intent, I disagree with your definition of what identifiers do. It's this simple:

• A DID is a URI as defined by RFC 3986.
• The first line of RFC 3986 is: "A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."
• Therefore a DID identifies an abstract or physical resource.
• In this specification, the resource identified by a DID is called a DID subject.

Full stop.

You can make all kinds of arguments about whether a particular DID produced by a particular DID method is anonymous, pseudonymous, or verinymous. But regardless, it still identifies the DID subject. That's what identifiers do.

Furthermore, if a DID identifies a natural person in any way that can ever be associated with that person—no matter how anonymous or pseudonymous it starts out or what mechanism is used to make that association (including proof of control)—then that DID is personal data under GDPR, period. (I am not a lawyer but every GDPR legal expert I've ever discussed it with gives that same answer.)

[brentzundel]

We'll have to have further discussion here.

Identifiers don't identify things.

Identifiers are used after something has been identified to refer to that something.

Please adjust any statement that says "DID identify..." to "DIDs refer to". This adjustment probably needs to bubble up to elsewhere in the spec.

@jandrieu I respect this assertion and want your concerns to be addressed, but feel that since the language used in this PR currently matches language used elsewhere in the spec (e.g., the DID Subject is defined as 'the entity identified by the DID.'), your concerns are with the whole spec, not just this PR.
It would be good to raise an issue where the group can discuss how best to address this language everywhere in the spec. Changing just this PR would make it inconsistent with the rest of the spec.

[kdenhartog]

I really like how you put this all together. My review only reviewed the text, but I can infer the graphs are supportive as well.

The only aspect that I was left wanting to change a bit was the part where we imply the DID Subject and DID Controller are the same entity. In my mind, the DID Controller is compromised of the DID Subject + some software and properly talking about it as the combination of the two will help to frame the conversations that overlap between legal and technical minds.

I had a few other suggestions and grammatical things I found as well, but nothing major really.

Overall though I'm satisfied with how this reads and would be content if this was merged as is. Thanks for putting this all together @talltree !

[kdenhartog]

While this statement is true, I'd prefer to suggest the idea that parties should communicate with a service endpoint rather than look at their other DIDs. Would you be open to adding that section or replacing this one with a paragraph about communicating with a service endpoint to discover additional data?

[talltree]

@kdenhartog Good point, although keep in mind that DIDs that identify digital resources directly may not have any service endpoints. So I will edit this to reflect both options.

[kdenhartog]

This seems to be a better introduction of the usage of the "alsoKnownAs" property in my opinion.

[talltree]

@kdenhartog Thanks - I agree. @rhiaro I'll leave it up to you if you want to reflect that in your text about the "alsoKnownAs" property.

[kdenhartog]

This statement still feels a bit off to me. Curious if you're open to saying:

"The DID Subject is the same entity as the DID Controller with the assistance of additional software"

This nuance has become more apparent to me as we've looked at SSI from a legal perspective and so my thinking is that adding this will help to align legal minds and technical minds a bit more in their mental models.

[iherman]

I am not sure I fully grasp the distinction. If the DID Controller, while identifying the same entity as the DID subject, has a different DID as a value, then I can see what you mean. But I would expect that if I create the DID document for my own DID (ie, identifying me) then the value of subject and controller will be the same DID, in which case I am not sure how I would understand your statement...

[brentzundel]

It feels odd to me to include mention of the "additional software" for the DID Controller.
If I rake the leaves in my yard, I don't say "I raked my leaves with the assistance of a rake," I say, "I raked my leaves."
I seems like pointing out that a DID Controller uses a tool to exert control of a DID is unnecessary. Of course there is a tool. I don't rake my leaves by picking them up one at a time with my hands, nor do I create a digital signature by counting on my fingers.
Just feels like a distinction without a difference.

[kdenhartog]

It feels odd to me to include mention of the "additional software" for the DID Controller.
If I rake the leaves in my yard, I don't say "I raked my leaves with the assistance of a rake," I say, "I raked my leaves."
I seems like pointing out that a DID Controller uses a tool to exert control of a DID is unnecessary. Of course there is a tool. I don't rake my leaves by picking them up one at a time with my hands, nor do I create a digital signature by counting on my fingers. Just feels like a distinction without a difference.

I find that the analogy of a rake and a person not quite analogous to the situation at hand because the rake is incapable of performing actions on behalf of the person moving the rake. In other words, the rake has no agency whereas software performing digital signatures can. I'd suggest thinking about this example instead. If I had malware loaded onto my router and my router becomes a bot in a botnet and starts further spreading malware who is liable? Am I the owner of the router liable, or is the author of the malware liable, or is the manufacturer of the router liable?

---

The difference comes when considering that the software is often not under the control of the Subject (e.g. they don't write, compile, and publish). Since they are not in control of the software there's the capability of the software behaving in an unexpected way to what the DID Subject expects and consents to. While from an identifier perspective it may appear logical to conjoin the two and say they're the same entity, from a protocol layer it doesn't always make sense. This is essentially the same idea as what OAuth 2.0 has done by separating the resource owner from the Client. They are not always logically equivalent and that distinction becomes important at layers above. Therefore, the DID Controller should be recogonized at least as a combination of the software and the person clicking buttons, not as a single entity. Or in OAuth terms the DID Controller is the combination of the client and the resource owner (although I'd probably be told off by others of assuming those two roles can be collapsed in any way).

[kdenhartog]

@brentzundel @iherman @talltree does my argument above sway you guys at all on this topic?

[brentzundel]

I won't fight it going in if others want it, but it feels unnecessarily pedantic to me, especially in a non-normative part of the spec.

[talltree]

@kdenhartog Sorry to take so long to reply to this thread but I have been waiting for to gather all the suggestions on the Appendix before processing them all (which I'm doing now).

So, first off, yes, I understand the distinction you are making between the DID controller as an entity and the software used by the DID controller to effect control of the DID / DID document. However I don't think it makes it clearer to expand the definition of DID controller to include the software (I actually think that make the situation muddier).

However it is a good idea is to clearly state that the DID controller exerts control via software, and from an architectural perspective (and even a legal perspective), that software needs to be taken into account.

I will reflect that notion in my update to the Appendix text that I'm preparing right now. However I think your point about the separation between the DID controller as an entity (human, org, thing) and the software is important enough that you should do a PR to either add a separate subsection of Security Considerations to explain it — or see if it can be added to an existing subsection.

[kdenhartog]

For multi-sig we could include multiple Link Data Security proofs as an array in a document showing the old state and the new state being signed by multiple keys from the old state.

If we want to show a simple threshold option, we could talk about using a Shamir's secret sharing scheme, but from an example perspective there's not a great solution for this because this feature is actually managed at the key management layer. Another example that would be more complicated, but could show good examples would be to use a BLS Threshold signature. However, I don't know of anyone that's got running code to show that working properly and able to produce legitimate signatures with. If we just want some example signatures that don't actually verify I'm sure we could just encode a random string to the proper length and that would work, but we'd have no additional documentation about the LD security suite that would be associated with it because no one has actually created and properly documented that work.

[rhiaro]

I wonder if this appendix, as it is substantial, would stand alone as a NOTE and be more likely to be read than as an appendix of the Core spec.

[rhiaro]

+1 @iherman

@talltree I can do the section-wrangling to do what Ivan suggests if you like, either before or after any content changes are made (just, probably, not at the same time) - just let me know

[rhiaro]

link to figure directly, numbering might change

[talltree]

@rhiaro I totally agree but I'm not sure how to do that. Can I ask for your help with that after I've processed all these suggestions?

[rhiaro]

needs direct link to figure / appendix

[talltree]

@rhiaro I may need your help with this, thanks.

[msporny]

Waiting on @talltree to respond to @kdenhartog and @rhiaro's suggestions. Waiting for @jandrieu to respond to @talltree.

[jandrieu]

@talltree wrote:

@jandrieu While I appreciate your intent, I disagree with your definition of what identifiers do. It's this simple:

• A DID is a URI as defined by RFC 3986.
• The first line of RFC 3986 is: "A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."
• Therefore a DID identifies an abstract or physical resource.
• In this specification, the resource identified by a DID is called a DID subject.

Let's unpack this.

If existing specifications addressed identity correctly, we wouldn't be here. The point of our collaborative effort is to improve upon the practices of the past. Yes, we want to build upon what works, but what doesn't deserves iteration.

"Identity" and "identifiers" are notoriously misused, ESPECIALLY within the "identity" industry where we would hope people would know better. DIDs themselves are proactively named to enshrine the specific awareness that what we are specifying are "identifiers" and not "identities". I have published numerous papers discussing how the community often talks past each other simply because we have different ways of thinking about identity:

• https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/identity-crisis.pdf -- "Identity Crisis" Where we demonstrate that identity is fundamentally an act of correlation.
• https://bit.ly/FunctionalIdentityPrimer -- "A Primer on Functional Identity" Where we advocate talking about how identity works rather than what it "is" and provide a definition based on that approach.
• https://bit.ly/FiveMentalModels -- "Five Mental Models of Identity" Where we describe five distinct mental models seen in identity collaborations.

My simple assertion is that while the URI spec used a definition of URIs that worked for them to some non-trivial extent. IMO, it does not work for us as written. And in many ways, I'd suggest it didn't actually work as well as hoped, even for their anticipated use cases. From HTTPRange14 to the unending evolution of URLs, URIs, URNs, and IRIs to our own debates and confusion over whether or not DIDs are URLs or URIs, there is clear evidence that the current definitions for identifiers have vital gaps and fail to meet all of the hoped for capabilities.

Given the DID Core specification is literally defining a new class of identifiers, we should be rigorous in specifying exactly what these new identifiers do and don't do.

With a bit of whimsy, I can imagine "magic" identifiers that, in fact, identify a subject. That is, they actually can, somehow, interact with an environment, recognize a subject, and explicitly distinguish those subjects from other candidate entities. For example, an identifier that is a protein binding molecule that will, under the right UV light, cause, breast cancer cells to glow. THAT would be an identifier that, in fact, identifies the subject. That molecule identifies breast cancer cells. Similarly, I could see an identifying virus that, through the magic of genetic engineering, makes a specific single individual sneeze (or other physically observable reaction). These bio-identifiers would, in fact, be identifying subjects.

This is not what DIDs do.

DIDs are used to refer to subjects. They don't perform the act of identification. They don't identify a subject.

Yes, it is often understood, as it was with URIs, that when we say "URIs identify a resource" we mean that URIs "label" or "refer" to resources identified by someone else (who associated that URI with that resource). In the vernacular, this short-hand is perfectly reasonable. Unfortunately, this particular use of "identifies" doesn't help when we need to build concrete systems that manifest a nuanced notion of how decentralized identifiers allow the building and use of decentralized identity.

This is not an esoteric distinction. It came out of a privacy review with counsel for a project I'm advising on. I was similarly gobsmacked by the attorney's assertion that a credential itself does not identify the subject, even though that credential has a name and photo on it. From a legal standpoint, it is the credential issuer who identified the subject as a particular entity, then provided assertions and attributes about those subjects. In a separate act, the recipient of such a credential provides a secondary act of identification. After verifying the authenticity of that credential, the recipient then uses biometrics embedded in that credential (photo, age, etc.), correlating the person in front of them with the subject of the credential. The information in the credential is used to identify the subject, but it does not, on its own, do the identification. Consider a situation where the recipient is blind: no matter what photo is in the credential, the recipient would not be able to use that data to identify the subject, because the identifier doesn't do the identification, the person does.

Unfortunately, the excitement around DIDs has led to a nearly unbounded hype machine, leading to unfounded, but often well-meant assertions about how DIDs magically fix EVERYTHING, just like blockchain fairy dust fixes EVERYTHING.

But DIDs don't fix everything (just like blockchain). They are useful for particular functionality that can help realize systems with different characteristics than those we have in place today.

The more clarity we have in our language, the more likely the mental models of users, developers, maintainers, and regulators of this technology will align with the actual capabilities, which will mean better systems realized in actual usage.

If you like, I'd be happy to suggest new text that achieves the same intent with more rigor.

[msporny]

@jandrieu wrote:

If you like, I'd be happy to suggest new text that achieves the same intent with more rigor.

Yes, for the sake of Odin's Beard, please suggest some alternate text! :P

[msporny]

Please retarget this PR to the main branch. You can do this by going to the top of this page, clicking the Edit button beside the title of the pull request, and using the drop-down menu beside the w3c:master target branch indicator for the pull request and changing it to main.

[OR13]

I find this language very, very helpful, but agree that it may be so large as to be better served in a note.

[OR13]

Agree with @rhiaro 's comments, though given we don't have another place like a "note" for these, I suggest this be merged into did core, once her comments are addressed and moved out to a note, only with WG consensus.

[iherman]

The issue was discussed in a meeting on 2021-01-05

• no resolutions were taken

View the transcript

3. Give feedback on PR 460

See github pull request #460.

Brent Zundel: If you have not looked at this non-normative appendix text, please do. They are important for the spec.

Drummond Reed: on 460, there has been some good feedback. since resource parameter has been pulled in, the appendix text needs a small update..

Drummond Reed: encourage everyone to take a look at the text and comment. Preferably this week so I can update this weekend.

Brent Zundel: if your AC rep needs the link let us know.

Joe Andrieu: on 460, I posted a lot. The current language is confusing and misleading. We can do better. Identifiers refer to things rather than identifying things..

Brent Zundel: everyone, please make your opinions known on the pull request..

[TallTed]

@jandrieu --

DIDs are used to refer to subjects. They don't perform the act of identification. They don't identify a subject.

Sure.

A DID doesn't identify, nor refer to, nor take any other kind of action.

A DID is no kind of actor.

Humans are the actors, the identifiers.

Humans act to identify the DID subject with a DID.

The DID -- the Decentralized Identifier -- isn't an identifier at all. (I guess we should rename the group, and all the documents we're producing...)

And while DIDs are used to refer to subjects, they don't themselves refer to subjects.

But if we're really going to move to fully rigorous language, we need to employ at least some semiotics (that may not be the optimal document to reference, but it's the best I was able to quickly locate). We might need to do a lot more education of ourselves before we try to educate anyone else.

However, the DID is a sign.

And that sign is used to denote a DID Subject.

A DID is used as a denoter.

It denotes the subject.

It's a Decentralized Denoter. A "DD". (Among at least 215 other meanings of DD.)

Or maybe a Decentralized Signifier. A "DS". (Among at least 243 other meanings of DS.)

Neither of which will be easily understood nor recognized by anyone, and both of which will prove to be even more overloaded than "DID" (which appears to have only 45 other meanings), part because as a Two Letter Acronym (TLA) there are even fewer competing candidates than for a Three Letter Acronym (TLA) (and here we have another collision, between TLA and TLA).

(On the bright side, Dunkin' Donuts has rebranded, so instead of DD they are now simply D, and that list of expansions has been shrunk by 1.)

---

On a rather more serious line, we need to remember that English is a complicated language, and "identifier" has multiple meanings. The following is copied-and-pasted from Google, which they got from Oxford Dictionaries, who publish the (usually accepted as authoritative) OED.

i·den·ti·fi·er
/īˈden(t)əˌfīər/
noun
noun: identifier; plural noun: identifiers
a person or thing that identifies something.
"the new number is to be known as the “unique patient identifier.”"
COMPUTING
a sequence of characters used to identify or refer to a program or an element, such as a variable or a set of data, within it.

Forget everything else I said above. A DID is clearly "a sequence of characters used to identify or refer to a program or an element, such as a variable or a set of data, within it", and therefore DIDs are Identifiers.

[jandrieu]

Ok. I'll yield on finding more rigorous language. My point remains valid, but if we want to continue the errors of the past for the sake of simplicity, I'm not going to fight it.

The only remaining shift in this section that I think is important is that we currently have

The DID subject itself (e.g., the id and

Which is not correct. The DID subject itself is not the id. Using the language in the
rest of the PR, the value of the id property is a string of characters that identifies the
subject and which MUST conform to DID syntax. It definitely is not the subject itself.

We would have a very hard time creating a DID whose subject is the string of characters
of that DID. We'd get lost in a tautological loop we'd probably never find our way out of.
Call it a Goedellian boundary of the system.

I suggested this as an inline change.

[talltree]

@jandrieu I agree very much with your point and will make that change along with the other suggestions that have been made. I aim to incorporate those revisions to the PR within the next 48 hours.

[peacekeeper]

The DID subject itself is not the id.

+1

[iherman]

The issue was discussed in a meeting on 2021-01-28

• no resolutions were taken

View the transcript

1. PRs on the Appendix

See github pull request #457, #460, #574.

Manu Sporny: Real quick, Drummond, just to check in on your PRs. For appendix and persistence and the URN thing. Can we get an update on those?

Drummond Reed: Lots of progress on one, not the other. Came down to the amount of time in the day. The PR on persistence... on our last call, I said "Hey, Joe, can I add something on URNs." He said he'd consider it.
… When I looked at his PR it was really about a different set of topics on persistence. In the end I felt that the points I wanted to be made about URNs, and so on should just be in a different section, which I called DIDs as URNs.
… Rather than shoehorn/appending it to Joe's section, I just made a new section. I revised it to just be a standalone section with a different name. Meanwhile, I reviewed Joe's PR and made one suggestion about formatting. That's my full report. Because I changed the substance of what my PR was suggesting, I just went back to the reviewers to ask to look at it again.
… I completed last night at midnight so maybe no reviews yet.

Manu Sporny: I'm hearing persistence PR is on a good glide path, good reviews, will probably go in. You've got another PR that needs review, and maybe there's alignment there with some of Joe's comments on it. Potential alignment there. There were a lot of change suggestions for the appending, but it seems no one is objecting anymore.

Drummond Reed: Everything after Joe had done the same thing and read it closely, he's got a particular way to characterize identification and in the end we agreed. There are like 20 small suggestions, I agree with all of them and just need time to incorporate them. The largest one is a formatting suggestion from Ivan and I just need to reformat to be a single section.
… Then I need to change the settings inside and do wordsmithing.
… My next highest priority is to get that done by the end of this weekend. My next assignment after that is either another section or adding more to a section on privacy regulations. I've prepared wording for that, short and sweet.
… Then I can put all my energy into review.
… That's my report.

Manu Sporny: Unless there are any objections, we can move onto concerns around the CBOR section. Anyone want to cover anything else first?

[agropper]

@talltree How can a DID identify a digital resource "directly" without a service endpoint?

…

On Sun, Jan 31, 2021 at 6:16 PM Drummond Reed ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In index.html <#460 (comment)>: > + </li> + <li> + How to to interpret the specific representation of the <a>DID document</a> + (e.g., the ***@***.***</code> property for a JSON-LD representation). + </li> + </ul> + <p> + There is only one required property in a <a>DID document</a>—the <code><a>id</a></code> + property—so that is the only statement guaranteed to be in a <a>DID document</a>. + That statement is illustrated by the solid red arrow in figure 2 asserting + that the <a>DID</a> identifies the <a>DID subject</a>. + </p> + + <h2>How can you discover more information about the DID subject?</h2> + <p> + This is the purpose of the <code><a>alsoKnownAs</a></code> property. The @kdenhartog <https://github.com/kdenhartog> Good point, although keep in mind that DIDs that identify digital resources directly may not have any service endpoints. So I will edit this to reflect both options. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YKGAJ2QTPTCNRAAND3S4XQGLANCNFSM4TXLGZLA> .

[talltree]

@talltree How can a DID identify a digital resource "directly" without a service endpoint?

By the DID referring to a digital resource stored directly in a verifiable data registry. This is the kind of resource that can be returned using the resource=true parameter as discussed in #199. (Such parameter is not going into DID Core but into the DID Spec Registries.)

[agropper]

I'm extremely concerned about any attribute related to a DID that is not fronted by a request to an authorization server. I haven't been following the DID Spec Registry issue closely enough. I truly hope that DID Core does not encourage any information unrelated to control AND that the control information should have extremely high entropy. We have the service endpoint mechanism as the demarcation point for access to resources. Can a service endpoint type provide the return of a resource stored directly in a verifiable data registry?

…

On Sun, Jan 31, 2021 at 8:00 PM Drummond Reed ***@***.***> wrote: @talltree <https://github.com/talltree> How can a DID identify a digital resource "directly" without a service endpoint? By the DID referring to a digital resource stored directly in a verifiable data registry. This is the kind of resource that can be returned using the resource=true parameter as discussed in #199 <#199>. (Such parameter is not going into DID Core but into the DID Spec Registries.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YN3H6VVVTGG3KVMH3TS4X4MJANCNFSM4TXLGZLA> .

[talltree]

I just completed accepting all suggestions. Then I did a restructuring of the Appendix sections per @iherman 's suggestions which I think helped make it cleaner and give it a more natural flow.

@iherman The only thing I was not able to do is replace the PNG graphics with SVG versions as I don't have an SVG editor handy. I did some research and MS Powerpoint for Windows can save the diagrams in SVG, but I created them in MS Powerpoint for Mac and there is no option for saving a graphic as SVG.

I can send you the Powerpoint file if you have the ability to save the graphics as SVG files.

[msporny]

Suggested change

	those involving the Semantic Web, may need a more precise definition of how
	those involving the Semantic Web, might need a more precise definition of how

[msporny]

Imagine that you were blind and reading this. It's not clear what a "graph model" looks like. You could say something along the lines of:

A diagram showing a number of circles connected by lines. The first circle is labeled "foo" with a line extending from it labeled "bar" connecting to a second circle labeled "baz". The relationship between the two circles is... and so on

[talltree]

I totally agree, @msporny. One question: do I need to do this full description for each of the figures in the appendix? And it may take quite a few words to describe the diagram—is that okay?

[msporny]

Yes, we need to do this as a part of our accessibility requirements: #118 -- the description should go in a longdesc attribute associated with each image so that people using screen readers will be able to hear the descriptive text while those that can rely on their sense of sight will be able to look at the image.

[iherman]

@iherman The only thing I was not able to do is replace the PNG graphics with SVG versions as I don't have an SVG editor handy. I did some research and MS Powerpoint for Windows can save the diagrams in SVG, but I created them in MS Powerpoint for Mac and there is no option for saving a graphic as SVG.

I can send you the Powerpoint file if you have the ability to save the graphics as SVG files.

@talltree Google doc does a decent job in exporting graphics to SVG. AFAIK, Google Doc slides can import Powerpoint.

[msporny]

Minor nits to avoid the use of normative language.

[msporny]

This PR is looking more and more like something that shouldn't go in the base specification, but rather an implementation guide or primer... Specs typically don't have FAQs in them. We can keep this here for now since we have nowhere else to put it.

[talltree]

@msporny I was thinking the same thing and actually played with different names for this section. Happy to change the main heading and reword the subheads so they are not questions.

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.