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

Received on Tuesday, 14 June 2016 20:19:31 UTC