… The UN summit made me think I might have something to contribut here.

… I spend most of my time working on cyber-security standards for fed and state governments

… These concepts have been around for a while, and been in the “Identity Ecosystem” over the last 10-15 years. Mainly in IIW and other forums.

… Recently, it’s been called “self-soverign identity”. At the ID2020 event and rebooting web-of-trust workship, the concept of an architecture surfaced again.

… During this, dcrocker and others took a look at our work. We’re going to show the W3C members in a couple of months, so we’re trying to get it in good shape. It’s not done, but it’s a first cut.

… We need to quickly come to conensus.

… Ballancing this, they need to be complete enough.

… On average, diagrams are overly complicated. I was delighted with the diagrams from this work.

… In the NY discussion, we looked at ways to enhance it (not replace). We explored this over hours and Manu circulated some diagrams based on these talks.

… I realized that no where in the diagrams is there an indication of the identiy itself. Maybe there shouldn’t be, but we should think about that.

… I also find it useful to have diagrams which work at different levels. For example, public behavior vs private behavior. In email, there’s the user agent and mail transfer agent. Looking at RC 598, UA and MTA are still there, but there is also quite a bit more.

… The fact the original is still valid is still useful.

… For example, the repository is internal to the holder, so it might not need to be shown in the basic architecture.

… The other actors in the system need to query for information; there are different types of queries. The identiy itself, history of claims, other dynamic data. The ledger reference refers to a growing journal, but has data static when created. One might want to query dynamic data.

… The idea is to merge all of these into a single abstraction, which were listed in the box out of NY.

… The key think is the understanding that we need to have an identifier that can’t be taken away from an individual through force or coersion. We create the concept of a “WebDHT” (a hash table with history), but that’s getting into implementation details.

… A higher level requirement is that we have an identifier that can be instantiated and owned so that it can’t be taken away.

… We’ve discussed block chain, journal, DHT a number of times, but we should wind back and look at requirements.

… The value part is the “DiD object”: define the structure of an object that can provide cryptographic proof of DiD ownership and update permission.

… Also, for the DiD Object to provide pointers to other sources of claims and other peer DiDs. For purposes of privace protection, a person (or principal) may need to have multiple/many DiDs to keep different personas separate.

… From the standpoint of claims-based ID, the concept of a DiD-Tuple is a genesis claim, and is the starting point.

… most discussion was over a “public DiD”, so that you can refer to it to discover,lookup and verify a DiD. This corresponds to an “omni-directional identifier”. However, from a privacy consideration there are limitations. There are also cases for private DiDs shared by a limited set of holders, thus a “uni-directional identifier".

… There was discussion around DiD discovery. Could use ledgers or oracles as peers, which provides independence but not a known starting point.

… The second bucket was “addressable ledgers”, was to treat them as part of the URI space (ledger of ledgers). This would make the DiD itself addressable, but has questions of portability.

… The third option was meta-protocols to allow ledger interaction.

… The last option as the “index ledger”, the idea that by concensus there is a single DiD registry, where the object may be stored elsewhere, but there is a master index.

… We’re interviewing individuals intersted in this area and want to contribute; Anyone on this call is weclome to participate.

… Secondly, on the meta-DiD discussion, we wanted to be able to move the root identier from one chain to another. Self-soverign users would have a choice of what chain to use, as well as the ability to move it later. We think we have some good answers by having every chain have it’s own DiD.

… These things are hard, but we think we can say it’s possible with this architecture, but don’t want to have to prove it first. The intent is to have a design which allows for portability, but this may be a 2.0 feature.

… There is a system up already used in demos. The issue is that it’s just backed by a regular DB, it needs to be distributed.

… We don’t need it to be ready by the time W3C membership votes, but we should have a plan.

… We anticipate that a spec should/would come out of this. I’d like to get through the heart of the work this summer and be able to implement/test in the fall.

… In oreder to do DiDs property you need a proof of existence, which was also worked on at the design workship, that will make the work easier to move forward.

… There’s interest in a standard way to do this, possible using linked data sigiatureas as a way to do this.

… I wanted to introduce Joe Andrieu to talk about this.

… Our first impressions was that we wished the human value was more prominent. It should discuss how system addresses real human problems.

… For example, easily humanly recallable titles. I appriciate that there is confusion over this. Things like “the lazy doctor” in UC 4.3.1. We tried to come up with a short name capturing the human value of each use case. A lazy doctor doesn’t maintain credentials, but a bad university has credentials pulled.

… I’d like to give some examples of requirements modeling (not engineering).

… I have some tools and techniques that can make these use cases easier to absorb, to capture essential interactions.

… One of the notes is that there is a lot to digest, and there was tension between a rigorous specification/detail, but this is at odds with the process.

… This puts the focus on a really good architectural diagram.

… People make two passes of UC, 5 minutes to vote to proceed, and the second set is people actually doing the work, who will look with a comb to determine if work is in scope.

… I’m going to send out another request on the survey.

… Also, we’re hoping that Adam will work on AC or Architecture summary.