RE: VC-HTTP-API - Unintended Consequences

John,

The unintended consequences of the DHS program has resulted in additional cliqueinous within the W3C CCG – with some organizations have funded implementations but these implementations are not completely open and available to the larger community - then there’s the rest of us.  There are no open implementations for reference or comparison.  We end up with a lot of haves and have nots (in terms of internal implementation experience) talking past each other and over each other as we’ve seen over the past few weeks.

What can DHS do to promote more openness? …more visibility? …more transparency?

p.s. This cliqueinous is not new …it has been an undercurrent within W3C CCG for a long time now (https://hyperonomy.com/2019/04/09/clique-speak/).

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image003.jpg@01D77735.422545F0]



From: John, Anil <anil.john@hq.dhs.gov>
Sent: July 12, 2021 7:21 AM
To: public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Subject: RE: VC-HTTP-API - A follow up on the RAR presentation

Adrian >>”Most of all, I think it's ill-advised for DHS to drive the SSI standards as hard as it did and now stay silent on the current sovereign asymmetry issue they most certainly helped to create.”

I’ve been watching the VC HTTP API public threads, the sidebar conversations, as well as the working group discussions without publicly weighing in on this to date but OK …

As a potential customer and implementer of this API within the context of the VC/DID ecosystem, we do have a clear POV on this that I will articulate below:

Challenge
--------------

  *   We are concerned with the “blockchain / DLT /DAG / Centralized Platform” hype where security, privacy and interoperability are not a priorities – As such our response based on R&D and POCs starting almost 6 years ago has been to:
     *   Enable systems and services that are resilient, self-healing, and can operate under duress in a world where perimeter-based security is no longer enough
     *   Prevent development of “walled gardens” or closed technology platforms that do not support common standards for security, privacy, and data exchange
     *   Remove limits on the growth and availability of a competitive marketplace of diverse, interoperable solutions for government and industry to draw upon to deliver cost effective and innovative solutions that are in the public interest.
  *   We have in the past been walked into a corner by vendors / technology providers who required us to buy into licensed, proprietary APIs in order to integrate with their systems. This has resulted in vendor/platform lock-in and non-trivial switching costs. This is no longer a path to success for us!
  *   We fully support solution providers building value added services “behind / on top of” an open API and, based on the value provided, we are willing to evaluate and pay for those services if it addresses our problem sets.

DHS/SVIP Approach
----------------------------
In our VC/DID ecosystem solicitation (from 2018), we articulated the following as our requirements:

  *   All APIs that are presented to the Issuer and the Verifier SHALL be publicly documented, patent free, royalty free, non-discriminatory, available to all, and free to implement using widely available and supported programming languages.
  *   The solution SHALL incorporate, if appropriate to the particular use case, the following emerging specifications and/or standards for interoperability that have been funded, tested and/or championed by DHS:
     *   Verifiable Credentials Data Model (Standards Development Organization - W3C)
     *   Decentralized Identifiers (Standards Development Organization - World Wide Web Consortium / W3C)
     *   JavaScript Object Notation for Linked Data / JSON-LD (Standards Development Organization - W3C)
  *   The Subject SHALL have control over and be accountable for the release of their data (credentials) to the Verifier
  *   The solution SHALL provide very high resistance to data deletion, modification, masking or tampering e.g. Show equivalency or better between the digital solution and physical security features currently required official licenses and certificates.
  *   The solution SHALL NOT have a dependency on a single Resilient Registry Infrastructure.
  *   The Identity Verification component that is implemented between the Subject/Holder and the Verifier SHALL use standardized, strong authentication technologies that is at least Authenticator Assurance Level 2 (AAL2) compliant as documented in NIST Special Publication 800-63 Revision 3 (or later).
  *   The solution SHALL support Federal Information Processing Standard (FIPS) compliant cryptographic algorithms for hashing, encryption, digital signatures, random number generation and any other relevant cryptographic operations that are performed as part of the solution to ensure its ability to be operationally deployable on a US Government network.
  *   The Subject/Holder SHOULD have the ability to selectively disclose credential information with consent
  *   The solution SHOULD support online and offline presentation of Credentials to the Verifier
  *   The solution SHOULD support non-Certificate Revocation List (Non-CRL) based revocation methods (Issuer initiated, Person Initiated, Multi-Sig based and others) that removes Issuer dependencies i.e. “Phone Home Problem”.

DHS/SVIP Guidance to the Companies that We Fund
--------------------------------------------------------------------------

  *   We are NOT going to provide you information on our internal APIs in our Issuer or Verifier Role – for the explicit reason that if we do so, and you build to it, it will result in bespoke, Gov-centric approach that is not broadly scalable. We do not want this!
  *   We expect you all to work out in the open in the global standards/incubation communities (e.g. W3C CCG etc.) in developing open APIs that meet the needs of a global implementer community to ensure both visibility of the work AND technical review and input on the work.
  *   Our sense and intent here is to have the potentially competing interests of implementers be reconciled thru this open work and discussion to reach a common outcome that benefits both us AND the broader and global technical community.
  *   We fully expect this to be noisy, occasionally contentious, and a lengthy process but we are in this for the long term, so will support this work (NOTE: We started investing in the DID/VC ecosystem ~ 6 years ago, and we remain committed to this work)
  *   What we commit to you in turn is that, the resultant API that is “… publicly documented, patent free, royalty free, non-discriminatory, available to all, and free to implement using widely available and supported programming languages”, will be implemented and supported by us in both in our Issuer and Verifier roles.

Why we support the VC/DID ecosystem
-------------------------------------------------------
W3C VC/DID architecture is an evolution of existing models that:

  *   Addresses the “phone home” problem in centralized PKI, SAML, OIDC and App based models
  *   Enables an individual to have agency and control over their data
  *   Provides credential aggregation and selective disclosure with informed consent
  *   Removes the conflation of identifiers and authenticators when addressing entities
  *   Supports global resolution of an Issuer’s identifier to its public key(s) & their retrieval
  *   Encourages a plurality of implementations to counter the “one ring to bind them all” model

Our Perspective on where things currently stand
--------------------------------------------------------------------------

  *   The VC HTTP API was the answer from our funded companies to our requirements around the Open APIs that we sought in our solicitation -- we appreciated that competing organizations showed the ability to reach agreement, with public input, on what was produced in a manner that balanced both the common utility and individual business value
  *   The companies in our portfolio have used early versions of this API to demonstrated cross-vendor, cross-platform integration and interoperability across remarkably different implementations (both ledger based and not ledger based)
  *   From our perspective, the argument that the VC HTTP API should not address the Holder feels a bit disingenuous  – The VC HTTP API exists within the constraints of the VC Data Model which includes interactions between an Issuer, Verifier, Holder/Wallet and the Registry.
     *   The language of our requirements notes that “All APIs that are presented to the Issuer and the Verifier …”.
     *   Any API presented to an Issuer *includes* both the API facing the Wallet AND the API facing the Registry and any API facing the Verifier *includes* both the API facing the Wallet and the API facing the Registry << We are NOT going to go down the path of a proprietary Wallet API or a Proprietary Registry API implementation.
  *   As an Enterprise (and similar to any other Enterprise) we will NOT support unauthenticated/authorized APIs AND we expect that any APIs that we use be able to support our *existing / proven / standardized and widely available* API protection capabilities using API Gateways and Protocols such as OAuth2.
  *   To us, the discussion around delegation *at this time* looks to be at best scope creep, and at worst the desire to attach niche or early stage tech that does not have broad adoption/traction to something that is broadly acceptable and useful in the hope of “drafting” behind it.  We are concerned about the utility of this approach.

Best Regards,

Anil

Anil John
Technical Director, Silicon Valley Innovation Program
Science and Technology Directorate
US Department of Homeland Security
Washington, DC, USA

Email Response Time – 24 Hours

[https://www.dhs.gov/science-and-technology/svip]