Email from Richard Wilsher to IAWG - 2022-08-31
Some thoughts concerning ‘Partial / Component / Not quite everything’ labelling and the TSL in general.
Our discussions over the last couple of weeks have made me think about this a bit.
Firstly, Partial vs. Component: I’m leaning towards thinking that, from a public-facing point of view ‘Partial’ is a better term. It says what it is – ‘Not quite everything’. Some might argue that even a ‘full’ service is just a component to something else. In addition, KI is not in any position to impose upon any entity how an Approved service should or should not be used. All KI says is that the subject artifact meets the stated criteria (per the SoCA). Caveat emptor surely still applies?
Therefore, an Approved Partial service might be used by a consuming entity which cares not a jot about KI. It may alternatively be included as a Component of a service which itself is subsequently Approved by KI. Note – I use the term ‘Component’ in the sense that it is a Partial service which is being embodied within another service (which could be Full or Partial – I consider that irrelevant).
Therefore, I propose that we choose to use the term ‘Component’ in the sense of a pre-Approved Partial service being incorporated into the functions of another service which is submitted for KI Approval but that such a service is labeled as ‘Partial’ in any Public-facing usage with the exception of criteria.
I would posit a definition, at least for this purpose, of a Partial service as: “a service which does not encompass a fully functional service provision which can be directly delivered to an RP and/or a consumer (as an Applicant/Subject)”.
Conveying the nature of an Approved service: I wonder if we haven’t gone too far into cramming info into the Trust Mark itself. Let’s not forget the ‘KISS’ principle. At the uppermost level, there needs to be a distinction between Accredited Assessors and Approved Services, each of which receive a TM. Dealing with services first, since that seems to get the most attention. They are of a distinct class and are either Full or Partial and may be at one or more levels of assurance. As a ‘logo’, there is a real limit to how much info can (or should?) be conveyed in the TM. I’d prefer that it was clean, rather than be cramped. I honestly don’t think that anyone is making a decision based upon what it says in a TM. That’s just not realistic, so why ar we trying to invent so many different flavors?
What if we provided a QR block which linked DIRECTLY to the applicable TSL entry? What if that entry stated very clearly the Status of the Approval (we should retain info for all states, not just for Approve), Class of Approval, whether it is a Full or Partial service, at which assurance levels and for which (broad) functionality? It could then also include the provider’s Public Service Description, which could be better structured (through requirements to be stated in the S3A)to provide additional information in a normalized form, even though it was free (directed?) text.
One particular point which must be clearly stated is that the Approval is strictly for the service as described in the Public Service Description as provided by the CSP, hence the PSD must be scrutinized by KI to ensure that nothing exaggerative nor potentially misleading is included in that text (and included in the TSL).
Other info re. approval dates, renewal/ACR dates, contacts, … is then provided as a part of the full TSL record.
I’d be happy to lead a small task force (not even worthy of being capitalized) to consider these collective points and make some proposals to the IAWG, if the WG so approves. I’d reckon it needs only 3 or 4 of us and I suggest Lynzie is ‘voluntold’, because she has to manage all this ‘stuff’. Maybe at least one CSP as well?
And I’ve only mentioned service Approvals because, as I said, they seem to be causing the greatest friction right now, but the same considerations apply in the general sense to Assessor Accreditations and the task force include those in its scope.
Sorry about this spanner (wrench) in the works.
R
Richard G. WILSHER
CEO & Founder, Zygma Inc.
www.Zygma.biz
+1 714 797 9942
___________________________________________________________________________________________
Diagram/response from Andrew:
