Architecture Stages, and options of Subject-Holder (was: Re: Agenda: Verifiable Claims Teleconference - Tuesday, June 13th 2016

On 6/14/16 2:41 PM, Manu Sporny wrote:
> On 06/14/2016 04:34 PM, Dave Crocker wrote:
>> Removing arrows from the lines connecting the boxes means that the
>> reader is unable to get any sense of how information flows in the
>> system.
>
> We're attempting to address this by using either your or Dave Longley's
> document (as discussed on the call today).
>
>> The holder is specified as registering the identifier.  That means
>> the holder is the Subject.  It is confusing to use a label that
>> refers to one, later part of their role, but not to their original
>> role.  It also simply looks odd to say show the "Subject identifier"
>> being registered by anyone other than Subject, given the important
>> message of this effort that a person can control their own online
>> information.
>>
>> Also, I had been told that the Holder might not be the Subject.
>
> Yes, don't quite know how to reconcile this at this point in time.

These two problems (time flow, and the optional "Subject is Holder" 
and/or "Holder is Issuer") bothered me also. They're the main reason I 
began formulating a different layout.

I have that on paper now, but it won't be in digital graphic form for 
an unknowable time (possibly 24 hours, but maybe longer).

I'll attempt to very roughly describe it here, ie., how I've treated 
these two problems:

  A. There are separate lanes (Stages) for each major new entity 
involved, except for the first Stage, which has both Subject and 
Holder. The next Stage adds Issuer, then the next Repository, then the 
next Checkpoint (Relaying Party).

  B. In the first Stage, there is a dotted box around Subject and 
Holder that says "If Subject is Holder". In the second lane, there is 
another dotted box around Holder and Issuer that says "If Holder is 
Issuer".

  C. Then in each Stage there is an arrow to a separated section 
containing what is created/accomplished in the Documents (Claims, 
Credentials) at that Stage.

By means of this system it looks to me like I can not only deal with 
the optional "if Holder is Subject" or "is Issuer", but I can 
additionally show the steps of how the Claims get aggregated into 
Credentials, and how the ids can be checked from any point in any 
Stage, since the Registry is the graphic's background -- it's 
available anywhere (since it's public), and so resides in all the 
borders and edges. :-)

Of course, there's going to be a lot of data on this graphic. It will 
be a challenge. But as a roofer I talked to last year said about my 
neighbour's house, "There's nothing like a challenge".  :-)

Steven


>
>> Time sequence diagrams:
>>
>> I haven't studied these in detail.  Including them is interesting.
>> Not sure they strictly qualify as 'architecture', since they move
>> more into the realm of 'protocol'.  However they do give life to the
>> relationships among the roles/boxes and that seems useful.
>
> On the call today, we decided to keep them in the document.
>
>> This comes after the brief opening paragraph to the document.  A
>> list like this, early in a document like this, needs to be tight,
>> clear and compelling.  It should set expectations carefully.  It is
>> better to be conservative and exceed expectations than set them too
>> high and miss the mark.
>
> We've updated the introduction to address some of your concerns. I know
> you've sent feedback, will try to integrate that tonight.
>
>> I suggest moving the first three bullets up to the opening
>> paragraph, as part of the prose, describing some broad purposes in
>> pursuing the topic.  That is, these are some important social goals,
>> but they aren't goals of the architecture itself.
>
> Done.
>
> -- manu
>

Received on Tuesday, 14 June 2016 22:27:49 UTC