Suggestion: use simple time-flow example as Architecture Block Diagram

On 6/12/16 8:04 AM, msporny@digitalbazaar.com wrote:
> Topic: Discuss purpose of architecture proposal
>
> Adam Lake: http://w3c.github.io/webpayments-ig/VCTF/architecture/
> Adam Lake: Long form version,
>   https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/raw/master/topics-and-advance-readings/a-self-sovereign-identity-architecture.pdf
> Manu Sporny:  We're putting this proposal together because a
>   number of people at W3C requested it. This arch doc is here to
>   quickly inform people about the type of arch we're talking about.

I'd like to suggest a change of the basic architecture 'block diagram'.

I believe it will be easier to follow, and be more meaningful to a new 
reader, if it is presented as a 'flow diagram' that includes time.

I suggest as an example of what I mean, that steps like the ones 
below, for a simple Credential creation and check, could be blocks, 
possibly set up left-to- right or top-to-bottom for the flow of time:

1. Holder formulates Claim.
2. Holder Registers Claim (inside box: by Self or by Issuer)
3. Holder Aggregates Multiple Claims into Credential.
4. Holder places Credential into Repository.
5. Holder asks Repository to relay Credential to Relying Party.
6. Relying Party Validates each Claim with its Issuer.
7. Relying Party accepts full Credential of Holder and opens Gate.

I believe this will be a better introduction than boxes which have 
two-way (double-headed) arrows and no obvious time-flow, which lead 
the reader to not know which direction to read the diagram, and hence 
produce multiple parallel possibilities in the mind.

Those multiple parallel possibilities are probably all valid, but I 
don't believe they're the right thing to present at the start of the 
document.

I also believe that the paragraph about flaws in other previous 
attempts at this should be put somewhere else, separated from the 
first flow diagram. Having them there adds yet more parallel 
possibilities that must be juggled.

I believe getting the reader to see at the outset a single successful 
flow will be important in getting them to correctly understand the 
core defined terms and how they're used.

Steven





>   I would even go as far to say that our audience for this is
>   technical orgs, specifically members of W3C, or orgs that would
>   become members of W3C if the work takes off. That's really all
>   the background that we need.
> Manu Sporny:  Deadline is the 20th. The WPIG is going to review
>   all this stuff. To catch you up on where we are, we've been
>   talking about Verifiable Claims, they used to be called
>   Credentials, for about 4 years. This used to be in the Web
>   Payments Community Group. It was later split into its own group
>   at the Credentials Community Group, where it incubated for about
>   18 months. Then the Web Payments Interest Group, official W3C
>   group, started up and it is responsible for coming up with
>   charters for WGs. VC was taken up by the IG and the VC task force
>   was created to come up with the charter and these other docs and
>   we're going to give those docs to the IG and have them read it
>   and then ask them if they will take it to W3C membership for a
>   vote.
> Manu Sporny:  There's a F2F on the first of July.
> Manu Sporny:  That's why we have this deadline.
> Dave Crocker:  This is a hard deadline for getting a group vote
>   on whether to approve the documents in their current form and put
>   it forward to the W3C membership for approval.
> Dave Crocker:  Just trying to understand the broad strokes of
>   this. Assuming it gets approved, what happens after that?
> Manu Sporny:  If approved by IG it goes to W3C management, and
>   they will tell us if they think the membership won't have any
>   objectives. We may have a roadblock there -- if we get buy in
>   from them and can prove we've got consensus over the past 2
>   years, etc. THen they would put it to a vote by the whole
>   membership 400+ orgs.
> Manu Sporny:  There are two thumbs down we could get, one is from
>   management -- that means we haven't answered some question from
>   them, usually a large member company has an issue they need
>   resolved.
> Manu Sporny:  Management has been unconvinced twice before but
>   has come back with vague requests.
> Dave Crocker:  Thanks. I apologize for not doing this homework
>   sooner.
> Manu Sporny:  There's no way for you to know without us having
>   this conversation.
> Dave Crocker:  I'm trying to figure out a good way for us to
>   navigate here. I have a bunch of questions I'm looking at -- and
>   the stuff I'm looking at has changed dramatically in the past
>   week or two. It's not good or bad it's that there are changes.
>   When something changes that much this quickly it means it hasn't
>   had time to get into people's brains and discussions for them to
>   know how it will be used. Which strikes me exactly as the issue
>   that these votes are trying to consider.
> Manu Sporny:  Let me clarify a bit, I don't believe what we're
>   proposing in this doc has really changed when it comes to the
>   tribal knowledge in this community. When it comes to what was
>   talked about at the design workshop, that's where there are
>   differences.
>
> Topic: Analysis of current document
>
> Dave Crocker:  Right. I tried to make some annotations on the
>   document that you circulated. We didn't get around to talking
>   about those. Any example of a very basic question about this
>   question and a previous one... where's the identity in this?
> Dave Crocker:  Holder, issuer, inspector, storage location --
>   where's the identity? The entity that the claims are being made
>   about is never mention.
> Manu Sporny:  We've been calling it that the subject.
> Dave Longley:  We can get to that question in particular, i have
>   thoughts
> Dave Crocker:  We have claims that are ... where they come from
>   is clear (the issuer), where they go actually seems less clear.
>   The reason I say that is ... claims go to the holder and are held
>   in the repository. There appeared in the discussions I was around
>   ... upper box currently labeled registry and used to be ledger
>   ... it was a place to go to verify the claims. You could go there
>   to test the accuracy,  not the validity, whether an issuer made
>   the claims can be checked.
> Manu Sporny:  Let me explain removing the ledger. The W3C is just
>   starting to look at blockchain tech. End of June workshop. If we
>   walked in there with a ledger as part of the architecture, we
>   could get pushback and it's not a fundamental component of the
>   system. It's not core to the system. The decentralized identifier
>   system registry is just there for claiming identifiers that you
>   can prove you have ownership over. We tried to narrow the scope
>   of the diagram down to the minimum necessary to bootstrap the
>   ecosystem. For every box and arrow you add it's potentially
>   another spec and protocol you have to define.
> Dave Crocker:  The basic simplicity of the architecture I found
>   really appealing. A simpler architecture means we took the time
>   to make it shorter.
> Manu Sporny is scribing.
> Dave Longley:  I think you mentioned on previous calls - good to
>   have simple diagram to have people consume. Other diagrams might
>   provide more depth/features - other groups of people that want to
>   understand how you break roles down into subroles. For example,
>   holder.
> Adam Lake: Lost audio
> Dave Crocker: Looks like i got disconnected. will call back
> Dave Longley:  Holder could be broken down into software agent
>   that moves stuff around. Same thing for requests - single box -
>   single boxes can be broken down into multiple rules.
>
> Topic: Identifier registry
>
> Dave Crocker:  So, I think the question I ended on was -
>   decentralized identifier registry, in current version, is really
>   only and exactly an identifier registry, you check it to see if
>   an identifier is registered and to whom.
> Dave Longley:  We have been trying to make the diagram that we
>   present in general to be as simple as possible. There are other
>   things that can break roles down into other pieces that more
>   advanced parties would like to learn about. We have a simple
>   diagram to figure out how information can move around. We could
>   have other architecture diagrams that explain how that works.
>   Where is the identity? Where are the verifiable claims?
> Dave Longley:  You could actually break this down into subject
>   that claim is about, software agent that moves claims around,
>   repository that is a storage abstraction - furthermore, where
>   they might go might break down into software/hardware that you
>   hold onto as a person, or it could be a public blockchain that
>   you use to hold on for public claims, or you use some other
>   mechanisms to store private information.
> Dave Longley:  There are a number of different pieces that are
>   not necessary for core architecture, but very important for
>   solving more use cases and implementing the system. Same thing is
>   true for party that receives claims - that same role, which we've
>   called 'consumer', 'inspector' could really be a number of
>   subroles... requesting vs. verification of claim. Maybe claim
>   verification can be delegated.
> Dave Longley:  Or it could check a whitelist for a bunch of
>   issuers that it trusts, or it could be that issuers can receive
>   stuff from accredicration bodies. we don't want all of that in
>   the simplest diagram. We have parties that issue credentials,
>   there are parties that control these claims, parties that can
>   request them, and some concept of an identifier that has
>   independent existence - so you have more power/control - store
>   them as you see fit.
> Dave Longley:  All of those things are a part of the core
>   architecture - you could even say you could take out independent
>   existence part and still have the system work (take out
>   Decentralized Identifier Registry).
> Dave Crocker:  The concept of layering - macro-granuality for one
>   version of arch, and one for smaller-granuality.. we want to make
>   sure macro boxes don't change as you go down to the
>   micro-version.
> Dave Crocker:  So, challenge is boxes you have and what labels
>   you have on them. So, for example - registry - for registry and
>   identifiers who own them.
> Dave Crocker:  Yes, that's all that it does. is it going to be
>   something else as you add more detail. If it's going to be
>   something else, then the label is going to be a problem.
> Dave Crocker:  Saying something like decentralized is an
>   implementation issue - better to have architecture not have
>   implementation details.
> Dave Longley:  Another one of these had "oracle" - don't know if
>   that's too generic.
> Dave Crocker:  We came up with Oracle because that box had
>   multiple pieces of functionality - we had functions that were
>   different from the other two. oracle is not a good word, but
>   didn't have much else to replace it with. Reporter might work.
> Dave Crocker:  The other one, the more you and others have talked
>   about the Holder, the more I see it as something more than just a
>   holder. The reality is that it is the entity being identified.
> Dave Longley:  Most of the time that's true, but sometimes it is
>   about another subject.
> Dave Crocker:  I think that's a striking and useful basis for
>   noting that "identity" - the "identity" being identified is a
>   separate box in the architecture and it ought to be
>   distinguished. I think I understand why that didn't happen.
> Dave Crocker:  You can have actors that have different roles at
>   different times. Implementation vs. architecture - two different
>   boxes might be performed by same actor, that's okay - but they
>   don't have to be compressed into one box.
> Dave Longley:  The fact that a single player might have multiple
>   roles shouldn't affect the architecture.
> Dave Crocker:  For holder, you have a descriptive tag to say it
>   manages the registry entry. That doesn't sound like holder to me,
>   it sounds like owner.
> Dave Longley:  We had a certain concept that goes back to
>   self-soverign identity - you're in control of your own claims.
>   The fact that you might employ software agent to do some of these
>   things. We're trying to keep this particular architecture as
>   simple as possible trying to tease out those subtle differences.
> Manu Sporny:  Jsut to quickly why we try to stay away from
>   identity. Very early on we had identity in a number of these
>   documents -- and the response we got back from reviewers was
>   vehement opposition to any work because we were "trying to tackle
>   the identity problem" and W3C absolutely does not want to get
>   involved in that rolling failure that is identity on the Web and
>   the internet. [scribe assist by Dave Longley]
> Dave Crocker:  I do understand the religious wars that go on with
>   that, I used it because I saw "identifier" and that's an easy
>   term and someone owns that and I used "identity" for that.
>   [scribe assist by Dave Longley]
> Manu Sporny:  The thing that the verifiable claim is about is the
>   "subject" of those claims. [scribe assist by Dave Longley]
> Manu Sporny:  But "holder" is a bit different -- there's a part
>   of the architecture that you haven't been exposed to yet. One of
>   them is to design a privacy aware architecture, at no point
>   should the issuer or repo know who you're giving the claim over
>   to. [scribe assist by Dave Longley]
> Dave Longley:  At no point should they know that until you have
>   given consent.
> Dave Crocker:  That's fine -- but not affected by what we're
>   discussing. I think that the arch can show this privacy feature.
>   I think that's a particular bit of insight that someone looking
>   at the arch can tell or not tell. [scribe assist by Dave Longley]
> Manu Sporny:  We haven't figured out how to do it and if you can
>   do it that's great. [scribe assist by Dave Longley]
> Manu Sporny:  I wanted to mention the self-sovereign bit is
>   important. There are things we've put into the diagram,
>   specifically to demonstrate why this is different from SAML or
>   OpenID Connect. [scribe assist by Dave Longley]
> Manu Sporny:  We have orgs that can issue claims, orgs that can
>   request claims, and all of that stuff is supported in OpenID
>   Connect. Most federated systems today -- they don't support two
>   things: the concept of a subject of a verifiable claim can exist
>   independently of an IdP. That can be done through decentralized
>   identifiers -- where anyone can claim an identifier and manage
>   it. That's a core requirement for people to have independent
>   existence. That's why we don't have oracle in here. We wanted to
>   get specific about the key differences here. [scribe assist by
>   Dave Longley]
> Manu Sporny:  In the future we could have oracle in there.
>   [scribe assist by Dave Longley]
> Dave Crocker:  Saying "decentralized" in that box is a marketing
>   function to help viewers of this diagram an essential functioning
>   difference between architectures. [scribe assist by Dave Longley]
> Dave Crocker:  I'm assuming and I think it's really important,
>   that this be something that it helps guide technical people with
>   this. [scribe assist by Dave Longley]
> Manu Sporny:  The W3C AC will look at 15-30 min tops looking at
>   this proposal and there's much more material here. In every one
>   of these docs we want them to understand that this is new,
>   narrowly scoped, and achievable. [scribe assist by Dave Longley]
> Dave Crocker:  Makes sense and also explains why we want to get
>   it down to a few pages. [scribe assist by Dave Longley]
>
> Topic: Repository
>
> Dave Crocker:  A couple of suggestions: For the purposes you've
>   described, you don't need the repo box. It's an internal function
>   to the holder. [scribe assist by Dave Longley]
> Manu Sporny:  The fact that you can separate the repo from the
>   issuer is an important part of the architecture. In most tech
>   today you can't separate those two. [scribe assist by Dave
>   Longley]
> Dave Crocker:  There can be a third party -- even though all
>   access to the info in the repo is through the holder, a really
>   important point -- you want to highlight that it can be an
>   independent third party. [scribe assist by Dave Longley]
> Dave Crocker:  There would be some standard interfaces to it
>   presumably. [scribe assist by Dave Longley]
> Manu Sporny:  Yes. [scribe assist by Dave Longley]
> Dave Crocker:  The same can be said for the inspection function.
>   It can, and I suspect will, to be delegated to an independent
>   third party. [scribe assist by Dave Longley]
> Dave Longley:  I would say that's true, I would expect there to
>   be a standard way to make a request to a user agent and pass on
>   that request to a user agent that works on behalf of the holder
>   so they can fulfill that request. When you're talking about the
>   inspector, you're talking about independent verifiable - standard
>   interface or algorithm that you can run over a credential to
>   determine whether or not something is verified or fails
>   verification.
> Dave Longley:  Are you talking about protocols asking to see if
>   something is verified?
> Dave Crocker:  I was thinking about the latter - 3rd party
>   inspector was standing between the inspector and the party
>   consuming the information - how to model this - better to have
>   this as the entity that's going to consume the information as
>   being directly connected into the rest of the architecture and
>   rest of the inspection function behind delegated. Just as holder
>   may not want to delegate the function.
> Dave Longley:  I agree - don't know if we make the diagram more
>   complicated.
> Dave Crocker:  Same argument for repository is the same argument
>   that should be for inspector.
> Dave Crocker:  I think the argument is the same, functions are
>   different.
> Dave Longley:  Argument is almost the same, don't think it
>   matters if it's in the arch document.
> Dave Crocker:  Fact that the subject is not in here - maybe we
>   can have subject be above registry - one line going to Registry -
>   that will be entity that manages identifier - holder just manages
>   them - arrow from registry to holder - registry from any of the
>   bottom three - needs to go from registry to bottom 3. Issuer,
>   holder, and inspector, all they do is query the registry.
> Dave Longley is scribing.
> Manu Sporny:  Subject, I would argue is not necessary in the
>   diagram, because we don't really talk about verifiable claims
>   other than having them in the white boxes. I don't know if having
>   subject helps understand or not. To delegate inspection to a
>   third party is absolutely the same, I'm not convinced that it's
>   important to point that out. One of the reasons being that the
>   system is designed so that every website receiving this
>   information ... receiving a claim... they can do a simple check
>   on it, and it seems like if they delegate that it requires more
>   complexity. I don't know if we need to have that discussion at
>   this point. Every box we add we have to depend as being mandatory
>   in the architecture.
>
> Topic: Simplifying Diagram
>
> Dave Crocker:  So I hear you, part of balancing act, want to
>   include enough to be coherent but not too much.
> Manu Sporny:  You could remove repo and the system would still
>   function. You could remove decentralized identifier registry --
>   but that's not proposed in the first version of the WG at all.
>   We're just talking about data model and syntax. Not talking about
>   protocols yet because it was hot button.
> Manu Sporny:  Creating a decentralized registry was a hot point,
>   creating that at all means you're not ready for standardization
>   -- you need a system that's bootstrapped with a million people,
>   etc. before doing that.
> Manu Sporny:  It's great that you want self-sovereign identity
>   but it's way too early.
> Dave Crocker:  I can't say that I disagree with them, and that
>   gets into the challenge of how conservative this has to be vs.
>   how visionary can this be.
> Manu Sporny:  It can be somewhat visionary -- we just need to
>   make sure that the data model and syntax we create allows for
>   decentralized identifiers to fit in here, but not do it in v1,
>   but allow for v2.
> Manu Sporny:  We want to be able to say "This is where we're
>   headed" ... we're not putting oracles, ledgers, etc. in there --
>   because while we want those to be parts of the ecosystem in the
>   future, we feel that it would confuse or send W3C AC reps down
>   the wrong path. We want them thinking about the core problem -
>   the first step for VC. We can show them the next step after that,
>   but not expose them to the 10 year plan.
> Manu Sporny:  In general, that's our thinking on it.
> Manu Sporny:  All of that is up for debate.
> Dave Crocker:  I'm trying to understand enough of where things
>   are and what you ahve in mind so that any suggestions take that
>   in. It makes me unclear why you kept the decentralized registry
>   in there. We want to demonstrate the difference between OpenID
>   Connect.
> Manu Sporny:  We want to demonstrate the difference between
>   OpenID Connect.
> Dave Crocker:  The enthusiasm that tends to dominate cool new
>   stuff - it's always cool, but enthusiasm for it gets in the way
>   that less cool, less neat, reliable stuff works. [scribe assist
>   by Manu Sporny]
> Dave Longley:  One reason to have this in here is to demonstrate
>   that the architecture is fundamentally different from existing
>   architectures. This architecture enables new types of innovation
>   - by changing architecture, rearranging mechanism - we can enable
>   innovation - we don't have to say we need this, we can say if we
>   standardize these other parts, in the future, we can standardize
>   in the future how people can innovate. [scribe assist by Manu
>   Sporny]
> Dave Crocker:  Ok, I think I have enough now on what's driving
>   you - start w/ something with as simple as possible - maybe it
>   looks like existing systems - registry - global arbitrator of
>   identifiers. Have a registry - have the subject above it - have
>   issuer, holder, inspector, and that's it. [scribe assist by Manu
>   Sporny]
> Dave Crocker:  That doesn't look exiting - another version has
>   elaborations that we've talked about - tells people where it
>   starts and where it's going and it does it easily. [scribe assist
>   by Manu Sporny]
> Manu Sporny:  On the call yesterday, when I said maybe we have
>   two versions of these diagrams -- that's kind of what I was
>   getting at. First one can show an oversimplified view of where we
>   are and then another one for where we could get in the future.
> Manu Sporny:  The concrete changes you suggested sounded
>   interesting to me. I can see how could break out those boxes and
>   show how we get from one system to the next.
> Manu Sporny:  Do we show both of these?
> Dave Crocker:  You've already indicated some marketing/sales
>   problem if you only show the simple one - how is this different?
>   [scribe assist by Manu Sporny]
> Dave Crocker:  You have marketing/sales problems with only the
>   simple one.
> Manu Sporny is scribing.
> Dave Crocker:  The whole point behind simple one is that it's not
>   supposed to be different...
> Dave Longley:  Important to show both - this is kinda how things
>   work together, subtle differences, this is where we can head in
>   the future - purpose is to build a data model and syntax around
>   claims that allows this future visionary architecture to arise -
>   once people start using data model/format, people can innovate on
>   other components.
> Manu Sporny:  So dcrocker, you're saying, put subject in there,
>   switch the errors with the registry, put repo into the holder and
>   leave it there/don't show it, or break repository out and break
>   third party verifier out of it. [scribe assist by Dave Longley]
> Dave Longley:  That's a core architectural change - separation
>   from issuer - separate registry - identifier is integrated into
>   identity providers (issuer-repository)
> Dave Longley:  By breaking these pieces out, that's what's core
>   to building these new systems in the future.
> Adam Lake: Maybe we use just "identifier Registry" to be identity
>   provider agnostic but the architecture allows for decentralized
>   registries.
> Dave Crocker:  I'm so used to thinking as DNS as global registry,
>   I keep forgetting that we have all sorts of identifier creation
>   in various systems - Twitter username, for example. I hadn't
>   thought about this as an enhancement - you get to make point
>   about independent registration
> Dave Longley:  I like that as well - but how do we stop people
>   from talking about implementation details. We want to break those
>   things apart...
> Dave Crocker:  The short answer is URI are an existence proof for
>   global identifier registration service - and in fact, early
>   version will use something like that. It may have limitations,
>   but it's a well understood construct. The identifiers are just
>   URIs.
> Dave Longley:  Yes, I think that's okay - URIs...
> Adam Lake:  I'm working on document, observing mostly, appreciate
>   feedback/pushback - helps us understand what other folks might
>   push back on.
> Dave Crocker:  What I'm inclined to offer is to make a pass on
>   the document and make changes that you can look at and think
>   about.
>
>
>
>
>

Received on Sunday, 12 June 2016 23:56:18 UTC