Re: VC-HTTP-API - A follow up on the RAR presentation

Hi Anil,

Thank you for the detailed review. I believe all of us appreciate your
intent for solutions that will span the public and private sectors:
>> 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.

The objection to "just use OAuth2 with client credentials to start" is that
it violates the clause:
>> The Subject SHALL have control over and be accountable for the release
of their data (credentials) to the Verifier
when the Subject is not also the Holder.

Before we go on to discuss "at best scope creep" *can you clarify if your
intent, 6 years ago or today, is to link control to possession of the VC?*
https://github.com/w3c-ccg/community/issues/195 is how this has been
presented to CCG.

- Adrian





On Mon, Jul 12, 2021 at 9:23 AM John, Anil <anil.john@hq.dhs.gov> wrote:

> 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
>
>
>
> [image: https://www.dhs.gov/science-and-technology/svip]
>
>
>
>
>