Re: Agenda: Verifiable Claims Teleconference - Tuesday, June 13th 2016

G'day,

On 6/13/2016 1:51 PM, Manu Sporny wrote:
> If you want to add anything to or modify the proposed agenda below,
> please respond via the mailing list or make a note of it at the
> beginning of the call.


>  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/


Diagram lines:

   An architecture details actors/roles and the relationships among them.  A relationship is more than a line; it has directionality in order to show something about the flow of information.

   Flow of information is a higher-level construct, having to do with the transfer of content payload and is different from the lower-level construct of protocol interaction, such as push or pull, which are the underlying mechanism for effecting the information transfer.

   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.

   Most architectural relationships have information flow in one direction.  The arrow should be towards the receiver of the information.   Arrows should be at both ends of a line/link only if the relationship really does transfer information in both directions.

   As an example, a web interaction to retrieve some information is a flow in one direction, to the user.  A web interaction to complete a form can be shown in both directions, to show the display of the form and the return of completed information; or it might be depicted as a flow in one direction to the server, to emphasize the ultimate goal of obtaining input from the user.)



Holder:

   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.


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.


> Proposed Verifiable Claims Architecture Goals
> 
>    Enhance website usability by removing the need to manually enter verifiable claims
>    Reduce fraud by creating a standard way to share verifiable qualifications
>    Ensure maximum privacy in claims sharing mechanism
>    Separate production and control of an identifier from the production of claims associated with the identifier
>    Separate control of claims sharing from creation of claims
>    Develop standards for interactions between architectural roles, independent of market vertical
>    Re-use existing protocols where appropriate

   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.

   The first three bullet are for things that the architecture does /not/ automatically provide.  Rather they are for things that will take significant /additional/ work.  So while they are worthy goals and while implementing the architecture might well lay the foundation for achieving them, they will not automatically achieve it.

   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.

d/

--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net