Re: Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]

On 8/22/21 3:12 AM, David Chadwick wrote:
> On 21/08/2021 16:42, Moses Ma wrote:
>> Yes, you are correct. The idea is that for the diagram to be 
>> simplified - there needs to be /two/ diagrams, one for a passenger 
>> with a digital vaxcert and one for someone with a paper card that 
>> could be forged.
>
> *Unfortunately there probably need to be three separate diagrams*
>
> 1. For people with digital vax certs
>
> 2. For people with paper vax certs and mobile phones
>
> 3. For people with paper vax certs and paper-based cruise ship 
> vax-passes (who either don't have suitable mobile phones or are not 
> able to use them as required)
>
> Keep the diagrams separate and don't try to merge them
>
> Kind regards
>
> David
>
Hi David,

This is a good point, but the solution we're going to pitch cruise ship 
operators is to lend a phone to passengers, especially ones disembarking 
at a port of call, that has a wallet/vaxpass installed. Some luxury 
hotels already do this, offering a cell phone in the suite, preloaded 
with maps, tourism guides, and a custom concierge app. We may be heading 
into a future where people load a multiplicity of vaxpass apps - one 
when you're in New York, another in Europe, another from OpenTable, 
another from Fandango, etc.

Also, for kids, we are planning to partner with nodle.io, which makes 
wireless badges. However, this would be more useful for contact tracing 
while on the ship.

I've attached the second user experience graph for passengers with 
digital certs. My belief is that at least for the first few years, 
digital vaxpasses and beacons will not interoperate smoothly, and will 
require heavy technical support to get things to work. To pay for that, 
we need someone making money to provide customer service, so that means 
the retail establishment or the cruise ship operator needs to be 
incented to help make the VC/non-VC system hang together, otherwise 
users will curse us and rue the day we made it a "standard".

Moses


>> I believe that addingthe if/then to cover thelogicalcondition of 
>> paper or digital will make the diagram more programmer centric, and 
>> present a cognitive hurdle for some executives at a typical cruise 
>> ship company. This mightresult in an unarticulated “sales resistance” 
>> based on a desire not to look dumb.
>>
>> This particular diagram is for a passenger from Texas, which has 
>> banned digital vax certs and passes, and a modified diagram would 
>> cover someone from New York who may or may not have an Excelsior 
>> pass. Cruise ship operators will need to be able to accept passengers 
>> from all over the world with different kinds of documentation, and 
>> something that simplifies that process could be desirable.
>>
>> More importantly, the cruiseshipoperatorneeds to simplify the user 
>> experience for passengers visiting a port of call. An interesting 
>> case to consider is for a cruise ship operator in the Caribbean. The 
>> various ports of call will be for a number of small island countries, 
>> each with its own immigration service. A cruise ship could 
>> potentially issue a VC that could make it easier for passengers with 
>> paper vaxcerts to enter and engage in tourism more safely in the 
>> various ports of call… especially if a majority of the 26 major 
>> cruiseshipoperators agree to a standard. Inthiscase,the restaurants 
>> that service cruise ship tourism areas could, by downloading an app 
>> and printing outasignto affix to the door, that could also offer a 
>> discount to those using the cruise ship vaxpass, to drive safer 
>> tourism with integrated contact tracing for international visitors.
>>
>> Moses
>>
>>
>>
>>
>> -
>> *Moses Ma | FutureLab Consulting Inc*
>> moses.ma@futurelabconsulting.com 
>> <mailto:moses.ma@futurelabconsulting.com> | moses@ngenven.com 
>> <mailto:moses@ngenven.com>
>> v +1.415.952.7888 <tel:+1.415.952.7888> | m +1.415.568.1068 
>> <tel:+1.415.568.1068> | skype mosesma
>>
>>> On Aug 21, 2021 at 5:08 AM, <David Chadwick 
>>> <mailto:d.w.chadwick@verifiablecredentials.info>> wrote:
>>>
>>> On 21/08/2021 06:18, Moses Ma wrote:
>>> Hi Moses
>>> your flow chart (causality graph) is good at explaining what is 
>>> going on, but of course it misses one of the major benefits of VCs, 
>>> namely that the Cruise Operator should not have to validate paper 
>>> based certificates, and wont have to if it operates in Europe or 
>>> other ex-USA places where health authorities issue VCs directly to 
>>> users.
>>> Kind regards
>>> David
>>>> Hi Joe,
>>>>
>>>> Thanks for sending these diagrams. I actually had a suggestion for 
>>>> a new kind of diagram, but first, let me explain why...
>>>>
>>>> 1) When I was in college, I majored in physics and took this class 
>>>> from this amazing physicist, Richard Feynman. He had this great 
>>>> story about the time his college math professor decided to assign 
>>>> an unsolvable problem to see what would happen. Feynman said he 
>>>> realized that none of what he was taught would work to solve it, so 
>>>> he invented - on the spot - a new mathematics of fractional bases 
>>>> to solve the problem.
>>>>
>>>> 2) Later in that lecture, he described how he came up with Feynman 
>>>> diagrams, and the reason was because a simple diagram could replace 
>>>> a page of equations. He created a new method of diagramming to 
>>>> figure out what was going on, so he could totally understand it.
>>>>
>>>> 3) He finished by saying that if a professor couldn't explain 
>>>> something so a freshman (like us) could understand it, in really 
>>>> simple terms, s/he probably didn't really understand it completely 
>>>> himself. Understanding comes with the ability to simplify its 
>>>> explanation.
>>>>
>>>> Now, DIDs and VCs are a bit like quantum physics in terms of their 
>>>> complexity, and I'd really like to come up with a different kind of 
>>>> diagramming to explain how they work in terms that a "freshman" 
>>>> could understand them, without a mastery of software engineering 
>>>> and cryptography.
>>>>
>>>> What I came up with is what I call "user experience causality 
>>>> diagramming", that tries to explain as simply as possible, how 
>>>> something like a VC would work. For example, if I have to explain 
>>>> it to a cruise ship operator, they have to feel like they 
>>>> understand it before they'd be willing to pilot it, never mind 
>>>> staking their career on it.
>>>>
>>>> Here's a sample of what one might look like, which is supposed to 
>>>> be very simple:
>>>> If you, or any of the others, think this might have some potential 
>>>> for better explaining how VCs would work than the more "programmer 
>>>> centric" diagrams you produced, I'd love to participate in a small 
>>>> work project with a small number of us to figure out a meaningful 
>>>> standardized approach to visualizing VC processes.
>>>>
>>>> Moses
>>>>
>>>> PS, sorry for bloviating again, it's a side effect of aging...
>>>>
>>>>
>>>>
>>>>
>>>> On 8/16/21 2:16 PM, Joe Andrieu wrote:
>>>>> Howdy folks,
>>>>>
>>>>> Based on conversations with the use case team, I've put together 
>>>>> the attached diagrams, illustrating a minimum conceptual model 
>>>>> based on the USCIS Green Card use case, as implemented using CHAPI.
>>>>>
>>>>> I'm sure this model is lacking some elements for folks who have a 
>>>>> slightly different configuration. I chose this use case because it 
>>>>> is the one I'm most familiar with, making it easiest to be 
>>>>> complete. I'd like to speak to folks with different scenarios and 
>>>>> see if we can't come up with a variation that covers your 
>>>>> requirements.
>>>>>
>>>>> A few notes.
>>>>>
>>>>> 1. There are sequence and communications diagrams for both 
>>>>> issuance and verification, plus a class diagram.
>>>>>
>>>>> 2. All of the components are "owned" by one of the core roles 
>>>>> (Holder, Issuer, Verifier) are color coded.
>>>>>
>>>>> 3. The class diagram aggregates the method calls on each of the 
>>>>> lifelines in the other diagrams.
>>>>>
>>>>> 4. The components are
>>>>>   a. *Holder* The entity who holds the VC once issued and later 
>>>>> presents it for verification.
>>>>>   b. *Holder Application *The software or service that allows 
>>>>> holders to manage their credentials. Often called a wallet. For 
>>>>> symmetry, it could be called a Holder Service.
>>>>>   c. *Storage Service *The software or service that actually 
>>>>> stores VCs long term (on behalf of the holder)
>>>>>   d. *Issuer Role* The website or software that provides issuing 
>>>>> functionality to a holder on behalf of that issuer)
>>>>>   e. *Issuer Service* Software or service that actually signs VCs 
>>>>> and VPs) This component is used by both the issuer  (to mint VCs) 
>>>>> and the holder (to create VPs for presentation)
>>>>>   f. *Verifier Role* The website or software that uses a 
>>>>> Verification Service as part of its decision making process for 
>>>>> providing services to holders.
>>>>>   g. *Verifier Service *The software or service that verifies VCs 
>>>>> and VPs by checking proofs and checking status.
>>>>>
>>>>> Note that there are more components than had previously been 
>>>>> itemized in the vc-http-api work, because storage and status 
>>>>> services had not be broken out as distinct capabilities. This 
>>>>> sometimes caused confusion. Some implementations will bundle all 
>>>>> or some of these components into a full-stack credential platform, 
>>>>> however, the APIs, IMO, must support interoperability between 
>>>>> these components. So, yes, a Holder Application will need to have 
>>>>> a way to get VPs created. Instead of assuming that's a 
>>>>> subcomponent of the Holder Application, breaking it out 
>>>>> illustrates, for example, the API that might be useful at an 
>>>>> Issuer when acting on behalf of a holder.
>>>>>
>>>>> 5. The class diagram is a distillation across all component 
>>>>> instances in all sequence and communications diagrams, so it 
>>>>> starts to suggest an API for each of those components. Since I 
>>>>> have only modeled one scenario's issuance and verification, I 
>>>>> expect the API is not full coverage. However, it is nice to see 
>>>>> that I only have the messages indicated by the USCIS, CHAPI-based 
>>>>> flow (where, for example, VCs are always delivered in VPs, so the 
>>>>> Verifier Service doesn't need a Verify VC method).
>>>>>
>>>>> 6. The message names are chosen for logical consistency in "normal 
>>>>> English"; they should likely be turned into camel case or 
>>>>> something and we can have a bikeshed festival.
>>>>>
>>>>> 7. The dance between roles and services matches the architecture 
>>>>> for the services operating SaaS style for a front-end that is 
>>>>> providing the "role" functionality on behalf of the actual entity 
>>>>> in that role. For example, the USCIS plugfest had mock-up USCIS 
>>>>> websites that beneficiaries interacted with, and which, in turn, 
>>>>> it interacted with Issuer services. It is understood that the 
>>>>> enterprising organization could run both the role and service 
>>>>> software using its own bespoke custom software.
>>>>>
>>>>> 8. It is worth noting that all of the user tasks from the VC Use 
>>>>> Cases document, except two, are accomodated. 
>>>>> https://w3c.github.io/vc-use-cases/#user-tasks 
>>>>> <https://w3c.github.io/vc-use-cases/#user-tasks> In particular, 
>>>>> "move claim" and "amend claim" don't really have much support: 
>>>>> neither the spec nor any implementation I know of addressed these 
>>>>> use cases. "Move claim" feels like it gets addressed by "store", 
>>>>> "retrieve", and "delete". Notably, the "delete" is not in the VC 
>>>>> use case document, but probably should be; It almost certainly 
>>>>> needs to be a feature in at least the storage service API. For the 
>>>>> "amend" claim, I believe the only real way to do that today (given 
>>>>> cryptographic proofs) is to revoke and re-issue. FWIW, I think we 
>>>>> should remove "move" and "amend" the VC Use Cases document.
>>>>>
>>>>> 9. The "revoke" capability is not modelled yet, but it makes sense 
>>>>> to add it to the status service (we just have the verifier service 
>>>>> checking status). I just didn't build out that diagram.
>>>>>
>>>>> That's it for now.
>>>>>
>>>>> Plenty of fodder for discussion.
>>>>>
>>>>> Comments and feedback welcome.
>>>>>
>>>>> -j
>>>>>
>>>>>
>>>>> On Sun, Aug 15, 2021, at 4:41 PM, Manu Sporny wrote:
>>>>>> VC HTTP API Work Item - August 17th 2021
>>>>>> Time: Tue 4pm ET <x-apple-data-detectors://10>, 1pm PT 
>>>>>> <x-apple-data-detectors://11>, 10pm CET 
>>>>>> <x-apple-data-detectors://12>, 8am <x-apple-data-detectors://13> 
>>>>>> NZDT (Wed)
>>>>>>
>>>>>> Text Chat:
>>>>>> http://irc.w3.org/?channels=ccg <http://irc.w3.org/?channels=ccg>
>>>>>> irc://irc.w3.org:6665/#ccg
>>>>>>
>>>>>> Jitsi Teleconf:
>>>>>> https://meet.w3c-ccg.org/vchttpapi 
>>>>>> <https://meet.w3c-ccg.org/vchttpapi>
>>>>>>
>>>>>> Duration: 60 minutes
>>>>>>
>>>>>> MEETING MODERATOR: Manu Sporny
>>>>>>
>>>>>> AGENDA:
>>>>>>
>>>>>> 1. Agenda Review, Introductions (5 minutes)
>>>>>>
>>>>>> 2. VC HTTP API Renaming Poll Reminder (5 minutes)
>>>>>> https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0124.html 
>>>>>> <https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0124.html>
>>>>>>
>>>>>> 3. Simple Majority Objection w/ GNAP-KBAT (30 minutes)
>>>>>> https://github.com/w3c-ccg/vc-http-api/pull/224/files#r682106281 
>>>>>> <https://github.com/w3c-ccg/vc-http-api/pull/224/files#r682106281>
>>>>>> https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0110.html 
>>>>>> <https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0110.html>
>>>>>>
>>>>>> 4. Feature Scoping (15 minutes)
>>>>>> https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0122.html 
>>>>>> <https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0122.html>
>>>>>>
>>>>>> 5. Pull Requests (5 minutes)
>>>>>> https://github.com/w3c-ccg/vc-http-api/pull/224 
>>>>>> <https://github.com/w3c-ccg/vc-http-api/pull/224>
>>>>>>
>>>>>> -- manu
>>>>>>
>>>>>> -- 
>>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/ 
>>>>>> <https://www.linkedin.com/in/manusporny/>
>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>> News: Digital Bazaar Announces New Case Studies (2021)
>>>>>> https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com>
>>>>> LEGENDARY REQUIREMENTS +1(805)705-8651 <tel:+1(805)705-8651>
>>>>> Do what matters. http://legreq.com 
>>>>> <http://www.legendaryrequirements.com>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>>
>>>> *Moses Ma | Managing Partner*
>>>>
>>>> moses.ma@futurelabconsulting.com | moses@futurelab.ventures | 
>>>> moses@ngenven.com
>>>>
>>>> v+1.415.568.1068 | skype mosesma | /linktr.ee/moses.tao/ 
>>>> <http://linktr.ee/moses.tao>
>>>>
>>>> FutureLab provides strategy, ideation and technology for 
>>>> breakthrough innovation and third generation blockchains.
>>>>
>>>> Learn more at /www.futurelabconsulting.com/ 
>>>> <http://futurelabconsulting.com>. For calendar invites, please cc: 
>>>> mosesma@gmail.com
>>>>
>>>>
>>>> Or whet your appetite by reading /Agile Innovation/ 
>>>> <http://www.amazon.com/Agile-Innovation-Revolutionary-Accelerate-Engagement/dp/B00SSRSZ9A> 
>>>> | /Quantum Design Sprint/ 
>>>> <https://www.amazon.com/Quantum-Design-Sprint-Application-Disruptive/dp/1799143864> 
>>>> | my blog at /psychologytoday.com/ 
>>>> <http://www.psychologytoday.com/blog/the-tao-innovation>.
>>>>
>>>> NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT FOR ONLY THE INTENDED 
>>>> RECIPIENT OF THE TRANSMISSION. IF YOU RECEIVED THIS E-MAIL IN 
>>>> ERROR, ANY REVIEW, USE, DISSEMINATION, DISTRIBUTION, OR COPYING OF 
>>>> THIS E-MAIL IS STRICTLY PROHIBITED. PLEASE NOTIFY THE SENDER 
>>>> IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND PLEASE DELETE THIS 
>>>> MESSAGE FROM YOUR SYSTEM. THIS EMAIL SHOULD NOT BE CONSIDERED 
>>>> BINDING; HARD COPY DOCUMENTS ARE REQUIRED TO CREATE LEGALLY BINDING 
>>>> COMMITMENTS. FOR CALENDAR INVITES, PLEASE CC: MOSESMA@GMAIL.COM
>>>>
>>>
>

-- 

*Moses Ma | NextGEN Ventures Inc*

moses@ngenven.com | moses.ma@futurelabconsulting.com

/v/ +1.415.952.7888 | /m/ +1.415.568.1068 | /skype/ mosesma

/blog & social media:/my blog at psychologytoday.com 
<http://www.psychologytoday.com/blog/the-tao-innovation> | 
/linktr.ee/moses.tao/ <http://linktr.ee/moses.tao>

/books: /Agile Innovation <http://agileinnovationbook.com> | Quantum 
Design Sprint 
<hhttps://www.amazon.com/Quantum-Design-Sprint-Application-Disruptive/dp/1799143864> 
| Soulful Branding 
<http://www.amazon.com/Soulful-Branding-Unlock-Hidden-Company/dp/1515114414/>

/for calendar invites, please /cc: mosesma@gmail.com


NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT FOR ONLY THE INTENDED 
RECIPIENT OF THE TRANSMISSION. IF YOU RECEIVED THIS E-MAIL IN ERROR, ANY 
REVIEW, USE, DISSEMINATION, DISTRIBUTION, OR COPYING OF THIS E-MAIL IS 
STRICTLY PROHIBITED. PLEASE NOTIFY THE SENDER IMMEDIATELY OF THE ERROR 
BY RETURN E-MAIL AND PLEASE DELETE THIS MESSAGE FROM YOUR SYSTEM. THIS 
EMAIL SHOULD NOT BE CONSIDERED BINDING; HARD COPY DOCUMENTS ARE REQUIRED 
TO CREATE LEGALLY BINDING COMMITMENTS. FOR CALENDAR INVITES, PLEASE CC: 
MOSESMA@GMAIL.COM