smart-on-fhir / health-cards

Health Cards Framework: implementation guide and supporting material

SMART Health Cards

Health Cards Framework: implementation guide and supporting material

Participants

One group building on and contributing to the SMART Health Cards Framework is VCI. See https://vci.org for participants.

View the guide

To view the implementation guide formatted including diagrams, see https://spec.smarthealth.cards

Please review https://spec.smarthealth.cards/#introduction-health-cards to learn about project goals and choices.

Contributions

For suggestions or contributions please use GitHub Issues or create a Pull Request.

Building locally

Prerequisites:

• Python 3.9
• Pipenv

Run pipenv install to install Python dependencies.

Then run pipenv run mkdocs serve to serve a local version.

health-cards's Issues

add project scope

Currently the contribution guidelines are just:

Contributing¶
To propose changes, please use GitHub Issues or create a Pull Request.

Please add a project scope which explains what this exact project hopes to accomplish... written in a level of detail that will make it clear if a given contribution would be in-scope or out-of scope.

This type of project specification will help attract contributors that have the kind of experience you are seeking.

Personally I have worked on distributed identities, am lead author on the non-fungible tokens specification, have deployed enterprise solutions and worked on the team that delivered the largest blockchain Microsoft is using in production. And I don't know if this project is worth working on or if I should make a competing product.

Use of ION Public DIDs and Privacy Compliance

Previous review by legal compliance at Providence Health System determine public DIDs (such as ION) would not be considered compliant with HIPAA and could not be associated with elements of ePHI.
Recommend sidetree configuration support both public and private DIDs.

Document expectations for international usage

• SMART Health Cards provides a general-purpose framework suitable for use in any jurisdiction
• Jurisdiction-specific FHIR dat profiles are needed to lock down modeling choices for interop
• To start, VCI has been collaborating on a set of US realm profiles for immunizations

Bundle example 2 is not correct

https://smarthealth.cards/examples/example-02-a-fhirBundle.json

• It does not have Patient entry
• Almost all the entries having reference to resource:0 which is DiagnosticReport in the bundle. Even the DiagnosticReport.subject reference to itself.

Document paper-based (non-verifiable) presentation of verifiable credentials

Pick an extension for .fhir-backed-vc

• Do we need different extensions for encrypted vs just signed VCs?
• Do we need additional guidance about when to use (e.g., email attachments vs links to download), and how to protect these?
• Can we include example downloadable VCs in the spec?

in issue-vc response, resourceLink may not be unique across >1 VC

We could say:

Option 1 -- use param order

Alternate VCs and the resourceLink values associated with the vc

i.e.

param: VC1, (Resoure Link for VC1), VC2, (Resource Link for VC2)

downside: it's fragile to depend on order

Option 2 -- add a property into the Resource Link structure

Or we could add a VC index in the Resource Link structure (making it {vc index, bundledResource, hostedResource)

downside: this also has a dependency on order...

Option 3 -- re-work the verifiableCredential param

Update verifiableCredential to include two parts: vc and resourceLink

downside: this breaks clients that have a simple way to extract VCs today)

Option 4 -- don't fix?

Other options?

Clarify data type for parameter _since

"By default, the issuer will return health cards of any age. If the Health Wallet wants to request only cards pertaining to data since a specific point in time, it can provide a _since parameter with a valueDateTime (which is an ISO8601 string at the level of a year, month, day, or specific time of day)."

The ISO8601 extended time format (eg: yyyy-MM-ddThh:mm:ss) aligns with FHIR dateTime format.
The ISO8601 basic time format (eg: yyyy-MM-ddThhmmss) does not.
Please clarify if which format does the parameter use?

JWS vs JSON-LD

I keep hearing external complaints about the use of JWS vice JSON-LD. Hoping to start a discussion here regarding this interop issue.

Add details on CapabilityStatement for discovery

• What's the canonical URL for our operations?
• Show how to add these to http://build.fhir.org/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.operation to advertise support

UX / Language guidance for explaining "share?" decisions to users

• How to map from VC requests into user-facing language?
• How to describe set intersections like "COVID Results" ∩ "Immunization Records"?
• How to explain what identity attributes will be shared (list all of them? show the actual values on-screen?)
• How to explain when a DID will be shared, too? (do we have any good familiar words for this concept?)

Use standard conformance language

There are two places in the IG using work "MUST". Suggest change to standard conformance language "SHALL"

MUST have "kty": "EC", "use": "sig", and "alg": "ES256"
MUST have "kid" equal to the base64url-encoded SHA-256 JWK Thumbprint of the key (see RFC7638)

Add project scope

Currently the contribution guidelines are just:

Contributing¶
To propose changes, please use GitHub Issues or create a Pull Request.

Please add a project scope which explains what this exact project hopes to accomplish... written in a level of detail that will make it clear if a given contribution would be in-scope or out-of scope.

This type of project specification will help attract contributors that have the kind of experience you are seeking.

Personally I have worked on distributed identities, am lead author on the non-fungible tokens specification, have deployed enterprise solutions and worked on the team that delivered the largest blockchain Microsoft is using in production. And I don't know if this project is worth working on or if I should make a competing product.

Please clarify usage of resourceLink parameter

"In the response, an optional repeating resourceLink parameter can capture the link between hosted FHIR resources and their derived representations within the verifiable credential's .credentialSubject.fhirBundle, allowing the health wallet to explictily understand these correspondences between bundledResource and hostedResource, without baking details about the hosted endpoint into the signed credential"

Please clarify if the resoruceLink parameter may (or may not) include only part of all resources in the bundle. For example, the bundle have 10 Immunization instance and the resourceLink has only 5 of them.

feedback on patient onboarding document

Aggregated feedback suggestions on the patient onboarding document:

• The 'Where do I get..' section feels light - I expect this to be the primary question for people seeking this content. Understanding that each Issuer will have their own SOPs/technology, can this section offer examples that provide a reference point? (e.g. I already got my vaccine and have a paper card).
  • perhaps we at least note that health systems and state immunization registries may be able to issue Health Cards after the fact.
• I think there is value in including the human readable presented form in this document - using something similar to reference design.
• The document mentions destroying a paper-based SHC as a value-add in two places - is it clear to the consumer that re-issue and re-print workflows will exist?
• Sharing the SHC with other apps feels ambiguous in this document. Are we talking about one app to retrieve the SHC and another to hold it? Or is this in reference to a workflow where the SHC is 'uploaded' to a Verifier's app (e.g. flight check-in?).
• Privacy protection is another area I expect to be a focus for already interested individuals. I'd like to see this addressed earlier in the document.

and:

• how this will work for parents and kids. I assume the parents would just carry the kids' health card in their "wallet" (digital or printed QR), but it might be worth adding this to the FAQ if it's not already in there.

Determine whether adding MIME type for file downloads could provide a better "download and open" UX

There may be better Android handling available (e.g., routing Health Cards to the right wallet app) for downloads when a MIME type is available, vs just routing files based on extensions.

Questions:

• What behavior can we get by tapping a "download" link in browser (with extension only? With extension + MIME type?)
• What behavior can we get by tapping a "download" link on an email attachment (with extension only? With extension + MIME type?)

Is this providing proof of a vaccination or just proof of a record in an EHR

As far as I know, If I go tell my PCP that I got vaccinated at walgreens/cvs/etc then he or she is likely to enter it into the EHR as a vaccination record without requiring any proof from me. Once it's in the EHR I can get a signed health card where the EHR attests to the fact that I got vaccinated, even though it's only based on my claim to my doctor.

Is this correct? If so, what's the value in providing the secure framework around the attestation when the original claim can be easily faked?

Is there a requirement for the issuers to have somehow verified records they are signing, or distinguish between patient claims of vaccinations and vaccinations that were done in-house?

Add examples

• Different lab tests PCR + Ab + ?antigen test
• Immunization: Flu +TDAP
• Levels of verification beyond P1

Document that in the $HealthWallet API, you can only have one DID per account

If you call $HealthWallet.connect a 2nd time, this replaces the originally-bound DID with a new one.

Immunization Forecast

As best as I can tell (and I am no FHIR expert) the current draft IG has no provision for a bundle that includes immunization forecast as a component. For purposes of completeness this should be included. It does not mean that any particular use case needs to use it but these FHIR resources should be available. This data is contained in the ImmunizationEvaluation and ImmunizationRecommendation resources. Work on this topic is conducted within HL7's Public Health WG. Key people working on this include Nathan Bunker [email protected] who has been participating in the weekly Tech WG calls, Eric Larson [email protected], Craig Newman [email protected], and Daryl Chertcoff [email protected] who works for me.

Create a table presentation for operation

I would like to recommend a table format for operation's parameters, like http://build.fhir.org/resource-operation-validate.html. Another option would be create a separate operation page and reference it from main index page.

Benefit: It is easier to quickly identify operation's parameters' name, type, and cardinality.

The longer descriptions and examples would be after the table.

Where and how should we record information about what test kits are used?

Observation.code is a coarse-grained LOINC code; more details may be needed to interpret.

Review encryption algorithm choices

Should we be using AES/GCM ?

Update credentials examples to match PCR result example

Feature idea: add a FHIR query "hint" to request messages?

e.g. to say something more specific than "share your immunization cards", might include a FHIR query string that narrows down via CVX code to just Tdap.

Lab Results vs Immunization Status

Note that the Framework document references a "lab" which seems to cover the COIVID testing use case but not the immunization use case. Perhaps these two user experiences should be separated as they are not exactly the same nor used necessarily in the same way at the same time. This is also not consistent with the primary use case identified in the draft FHIR IG.

Trust over IP Layers as a development model

The Trust over IP Stack

Just wanted to start a discussion on the Trust over IP Stack. The stack outlines the required components for the trust ecosystem in the context of decentralized identity technologies like DID and VCs and represents a comprehensive view informed by those who have developed the underlying standards and technologies as well as companies that have been developing solutions in this space from its inception.

Here is the stack:

As you can see each layer of the stack has both technical and governance components. In my short exposure to VCI, it appears we are primarily focused on Layer 3, and reducing governance requirements is a design goal/necessity. However, you cannot wish away governance. You can encode it or externalize it, but those choices should be made and justified by the project so that implementers are aware of those choices and a coherent implementation remains possible across multiple providers.

I would propose an ecosystem subgroup to help quickly identify and document the relevant questions at each layer for both technical and governance so that we can incorporate that into the project design documents and ensure a coherent effort across all partners.

The Trust over IP Foundation

The Trust over IP Foundation is part of the Linux Foundation and was created to address the need for some sense of orthodoxy in integrating all of the disparate technologies supporting efforts like VCI. Trust over IP is tech agnostic and neither prescribes a specific solution nor seeks to compete with standards or providers, but instead informs and advises solution developers (like VCI) in wading through all the design options. MITRE is a steering committee member for Trust over IP and I am MITRE's representative to the foundation. Feel free to reach out.

Here is some additional information on the Trust over IP Foundation and its purpose:

• Introductory Whitepaper

Handling the delegation of issuing credentials

What if an issuer such as Acme hospital wants to delegate the issuance of credentials to labs or physician within the organization?

While Acme may be recognized as a trusted issuer, delegates may not. This will likely require some form of provenance chain Acme - delegates -> lab - delegates -> physician that will need to be followed in order to verify the integrity of a given credential. Aries has some information on this, but I'm not sure the problem is actually solved yet.

WHO SVC Test Suite coordination with W3C CCG?

A few of the members in the W3C Credentials Community Group have been working on a Vaccination Certificate Vocabulary that is compatible with the WHO SVC work. The W3C CCG has also been working on a Verifiable Credentials HTTP API.

For those that are not familiar with the W3C CCG, it is the group (consisting of 400+ members) that created and standardized the Verifiable Credentials and Decentralized Identifier global standards (among many others that are currently being developed). These standards are used by a large number of digital vaccination certificate projects around the world (EU, US, NZ, etc.).

We (Digital Bazaar) thought it might be interesting to see if we could create an interoperability test suite for the WHO Smart Vaccination Card work using the tools listed above.

The test suite covers 28 types of vaccines that are covered in the SVC work, including Measles, Smallpox, Polio, Yellow Fever, COVID-19, and others.

Please note:

• This is all experimental; it's not meant to step on any toes (the 40+ other vaccination certificate projects).
• The solution is designed to address all goals listed in the recently published WHO document on SVCs.
• The certificates, dictionaries, and tests will track changes WHO SVC work (and are designed to be rapidly regenerated and tested).

With that said, we've been able to achieve the following:

• A test suite containing 1,624 tests covering the 28 vaccine types in the WHO SVC dictionary.
• 7 independent vendor implementations issuing and verifying each others WHO Smart Vaccination Cards.
• 1,623 passing tests demonstrating objective results wrt. technical interoperability.

You can view the latest Vaccination Certificate test suite report here:

https://w3id.org/vaccination/interop-reports

The announcement to the W3C Credentials Community Group is here:

https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0081.html

How can we best coordinate the test suite work with VCI? We have a number of concerns related to the claims made about Health Cards being conforming Verifiable Credentials (they are not)... how can we help to close this gap?

Define a way to pass {{uuid::FHIR REST URL}} maps in $HealthWallet.issueVc

The goal here is to:

• Allow a mobile wallet to tell which source FHIR resources (on a FHIR server) have formed the basis for the resources bundled into a Health Card
• Prevent verifying parties from knowing this information (i..e, it can't be embedded in the Health Card)

Source of truth for immunization records?

I am not sure if this is in scope for this project, but the notion of "source of truth" for immunization records is an open issue. Is it the EHR? IIS? Both? Either? Note that for both the EHR and IIS that records can change and be corrected for many reasons: simple errors, discovery of a bad vaccine lot invalidating the efficacy of the dose administered. Should the patient be able to capture their immunization record and store it in their digital wallet and assume it is forever "true"? Should they be made to validate that record from its source?

A secondary issue involves IIS or other points of record consolidation (potentially an HIE). They are only as good as the systems that submit data to them (primarily EHRs) but also apply some quality assurance steps to consolidate a coherent record for a patient. Should they be a preferred, more centralized source of information over an EHR?

Does this project even care about these distinctions?

Remove encryption key from the issuer public key set

The issuer key set published at https://smarthealth.cards/examples/issuer/.well-known/jwks.json contains an encryption key. I suggest removing it, since it is no longer used in the spec. The validation tool shows warning for non-signature keys in the JWKS, so that would reduce the output for the example files.

Regulatory Compliance

Task

Identify regulatory constraints and restraints for the project.

Method

Members comment on this issue with the following template:

Regulation Name:

Regulation Country / Locality:

Title/Section/Paragraph of relevant text:

Summary of impact to project:

URL or attachment with full text of the regulation:

Using ION/Sidetree

While I think Sidetree is valuable as a layer 2 solution, it seems like it may be unnecessarily difficult to bootstrap the effort - especially since performance is not initially a problem. For example:

• Someone has to run an ION/Sidetree node and manage the underlying database: Non trivial setup
• The node needs to talk to Bitcoin/Ethereum to submit batched transactions, which means it has to pay transaction fees in the respective cryptocurrency. How are these node operators compensated? I highly doubt they’ll do this forever out of altruism
• Sidetree relies on using IPFS. So you either use the existing public IPFS network or you have to standup an IPFS node
• With all this in mind, how do you encourage the operation of multiple Sidetree nodes? You surely don’t want just 1

client_uri should be a property on SIOP Request, not .registration

client_uri should be not in registration but an optional parameter directly in the request?

client_uri should move up to be a sibling

Are we fighting yesterday's war?

A JAMA perspective on vaccines and variants suggests we need to get as much experiential / real world data as we can.

https://jamanetwork.com/journals/jama/fullarticle/2777785

IMHO, digital vaccination credentials are not enough and we need to rethink our priorities.

Typos & Clarifications

Overview

Reading through the docs I've run into a couple places where we could be clearer.

List

• Health Wallet as Issuer: In linked section, we say the wallet needs to generate a key to enable verification of JWT signatures created by this issuer. Could we clarify that issuer is referring to the holder signing JWS, not an actual Issuer from the conceptual model?
• Clarify SIOP Request Payload iss DID: In the example DID SIOP Request, the JOSE header has a kid of did:ion:<<identifer for lab>>#<<verification-key-id>>, and the payload has an iss claim of did:ion:<<did-value>>. Should the iss actually be did:ion:<<identifer for lab>> for clarity, since this JWT was issued by the lab?
• Clarity the phrase "as JWE or JWS" (example as VCs), in that this is decided by the presence of id_token_encrypted_response_* parameters in the SIOP request.
• TBD - Interactions between verifier and issuer. Do verifiers call an issuer's well-known did config?

Document end-to-end protocol and data format choices

I'm one of the global standards Editors for the W3C Verifiable Credentials specification, W3C Decentralized Identifier specification, and a variety of ecosystem-supporting specifications. These specifications allow for a variety of design choices to be made; we did this to ensure that we were building big tent where most anyone could participate in building solutions. The downside to that philosophy is that there are a varied number of technologies that are sprouting up that, while compatible with the specifications, are incompatible with each other in many practical settings. In order to ensure that decision makers have clear guidance wrt. what technologies work well together, there are government-funded programs (in the US, Canada, and EU) that are focusing on creating interoperability test suites that test the software produced for these ecosystems for interoperability.

Therefore, it is important for the health cards initiative to clearly articulate which technologies are being used for each stage of a Verifiable Credentials exchange and how many organizations have working solutions for each technology. This issue is being created to track the various options that are available and how many organizations are supporting those options today.

Support Multiple Wallets via $HealthWallet

Support Multiple Wallets (Multi-Device and Multi-App)

I think EHR-Issuers and their Patients will want to support multiple wallets per Patient, just having multiple DIDs linked to an account.

To support this, the EHR will need to know which Holder a VC is being issued for, since this will determine what DID document/JWE encryption key is used by the issuer.

This is easy enough to support for download of fhir-backed-vc files, since the issuer portal can just ask the patient which wallet the file is destined for. The portal could also try and be smart about this, where it can sense what device the user is logged in with and only show wallets that it knows came from that device (maybe registering an IP address for the device during the SIOP flow).

For supporting this with $HealthWallet resources, the best answer would be to include a holderDid parameter in the POST /Patient/:id/$HealthWallet.issueVc API call.

Here's an example payload:

{
    "resourceType": "Parameters",
    "parameter": [{
        "name": "credentialType",
        "valueUri": "https://healthwallet.cards#covid19"
    },
    {
        "name": "holderDid",
        "valueUri": "did:ion:<<identifer for holder>>"
    }]
}

Note this also covers the niche scenario of a patient having the same wallet installed on multiple devices. Those wallets will have the same client_id, BUT have separate DIDs (unless they're sharing private keys, but that seems out-of-scope). Without this parameter, EHRs wouldn't be able to recognize the difference between these two wallets issuing a $HealthWallet.issueVc call.

Originally posted by @madaster97 in #21 (comment)

Ensure DID Document populates the right verification methods

Signing keys should be listed/referenced under:

• authentication[] - https://w3c.github.io/did-core/#authentication
• assertionMethod[] - https://w3c.github.io/did-core/#assertionmethod

Encryption keys should be listed/referenced under:

• keyAgreement[] - https://w3c.github.io/did-core/#keyAgreement

Add laboratory credential type to documentation

Add a verifiable credential type to the vocabulary documentation to be used for health cards to convey laboratory data (ie https://smarthealth.cards#laboratory).

Should the SIOP Request Object from Verifier to Holder contains Verifier's DID, instead of Issuer's DID?

Presentation Protocol Details

The process begins with a QR code or openid:// link. The only differences are:

1. The SIOP Request Object includes a claims object asking for relevant Verifiable Credentials to be included in the response:

   {
     "iss": "did:ion:<<identifier for issuer>>",     # should this be Verifier's DID instead?
     "response_type": "id_token",                       # should the response_type still be an id_token, when what Verifier cares about is Holder's VC?
     "client_id": "<<URL where response object will be posted>>",
     "scope": "openid did_authn",
     "response_mode" : "form_post",
     "response_context": "wallet",
     "nonce": "<<unique value>>",
     "state": "<<client-supplied value, possibly empty>>",
     "registration":  {
       "id_token_signed_response_alg" : "ES256",
       "id_token_encrypted_response_alg": "ECDH-ES",
       "id_token_encrypted_response_enc": "A256GCM",
       "client_uri": "<<base URL for issuer>>"
     },
     "claims": {
       "id_token": {
         "https://smarthealth.cards#covid19": {"essential": true},
       }
     }
   }

show endorsements

Apparently, Microsoft, Salesforce, and Oracle have endorsed this project as per:

https://www.theverge.com/2021/1/14/22231187/microsoft-salesforce-oracle-digital-vaccination-records

This is an important fact that should be disclosed in README.

Subject-centered claims in credentialSubject

I understand the simplicity of embedding an FHIR bundle straight into a credential. This way the VC just acts as a container and you drop the bundle as-is.

However, while that works well for a proof of concept, stabilizing that construction would be at the cost of losing the VC data model semantics.

In VC, the credentialSubject JSON object represents the subject of the credential – for a health credential, that would usually be the patient. So semantically, any attribute in credentialSubject is to be read as an attribute of the patient: name, allergies, etc. See schema.org/Person for example of such attributes. As a counter-example, fhirBundle is not a property of a patient as it's a standalone object with resources, the patient being one of the resources.

I think it would be very good at some point to work on a subject-centered FHIR mapping. I don't have enough knowledge of the FHIR format to propose anything more concrete at this point so I'll let the specialists speak, but one step might be to split the bundle and try to represent each individual entry as a separate credential. What do you think?

Also we might need some additional claims to articulate an individual FHIR entry to a VC – maybe other health-related ontologies would be helpful there?

Please clarify if these requirements are required or optional

Please add SHALL/SHOULD/MAY to these following requirements:

• bullet points under JWS Header and JWS Payload (https://smarthealth.cards/#health-cards-are-small)

Change operation name to FHIR convention

FHIR convention uses lower case letter for operation name, such as "$validate-code". http://build.fhir.org/operationslist.html

Suggest change operation $HealthWallet.issueVC to $healthwallet-issuevc

SIOP Response Payload Conflict

There appears to be a conflict between the SIOP Response format in the reference implementation and what's in the docs. The reference implementation payload includes a did property, whereas the payload format in the docs includes a sub_jwk property.

EDIT: I think I overlooked some things. The docs do include a did property, so just wondering if we should be including the sub_jwk.

NIST SP800-53 Compliance Evaluation

From Issue #36.

Federal systems, and federally funded state systems, must demonstrate FISMA compliance using the NIST SP800-53 guidelines according to Federal Information Processing Standards (FIPS) 199 Moderate level of impact to comply with the Health Information Portability and Accountability Act (HIPAA).

https://www.insidegovernmentcontracts.com/2014/12/fisma-updated-and-modernized/

De-duping Guidance for Wallets

Is there any concept of a stable unique identifier that wallets can use to de-dupe VCs? If not, is there any guidance for wallets on how to de-dupe VCs. For example, if the contents of the credentialSubject/vc object are expected to be stable, wallets could canonicalize the json object, then hash and derive an identifier from that.

Add Information on Update/Recover Keys for DIDs

Update/Recovery Key Requirements for Long-Form DIDs

We should provide more/clarified guidance on what is required when generating DIDs.

Specifically, the Sidetree DID Create Operation spec details the creation of update/recovery key pairs. In the smart health cards spec, these aren't mentioned, yet seem to be required by the core sidetree spec when generating a DID Document/Long-Form DID.

The most appropriate place to mention the generation of update/recovery key pairs is in the Install a "Health Wallet" App section. In this section we spell out that DID generation requires a generating signing/encryption key pairs, but we should consider adding guidance on the update/recovery key pairs as well.

Use Cases for Update/Recovery Operations

In addition to mentioning the need for update/recovery key pairs, could we also include some example scenarios?

For instance, if a Self-Issued OP had it's private key exposed, how would they go about rotating it out of their Long-Form DID document? Is there a specific operation that can black-list a given key?

Example scenarios seem relevant not only for issuing parties that may need to rotate a key, but also for relying parties (not strictly OIDC RPs, but anyone checking a public key) that would need to respond appropriately to a key being revoked. For instance, if an Issuer had a private key exposed, how would that knowledge propagate to the Holders and Verifiers, and how would they be expected to respond?

Example Issuer Key Revocation

Take the example of an Issuer of VCs whose VC-signing private key has been exposed. For issuers using the did:METHOD:<did-suffix>:<initial-did-document> format, they may go through the following workflow:

1. Use their update private key to issue a patch/patches to their DID document that would add a new signing key and revoke/remove the old one.
   • Is there a distinction between revoking a breached key vs deprecating a stale one (that may not have been breached)?
2. On their .well-known/did-configuration endpoint, the issuer would rotate out the old document with the new one as did:METHOD:<did-suffix>:<rotated-did-document>.
   • For every distinct signing Issuer associated with an origin, we'd expect a single linked_did entry corresponding to their most up to date DID document.
3. Holders should be able to anchor on that verified DID resource to then assess the validity of the VC/SIOP request that initiated the did-configuration call. For instance, the verified DID document would potentially contain patches where a specific signing key was revoked.
   • If a holder notices that a specific private key has been revoked (during the course of normal interaction with an issuer), should it be expected to comb through and delete any VCs signed with that private key? I'd say no, since the holder should have verified those VCs at download time.
4. Verifiers seemingly can't learn about registration.client_uri, and so can't be expected to ad-hoc call the did-configuration endpoint for the issuer of a VC. I think the expectation in this relationship is that the Holder will have verified a VC before downloading it in the first place (though not necessarily verifying again when distributing to a verifier). Other than an in-spec mechanism of revoking VCs with application logic, VCs should be able to persist in spite of corresponding private keys being compromised (as long as the key was compromised after the VC itself was issued).
   • The interaction between verifiers and issuers is pretty interesting, and there's definitely some nuance here as a result of using solely Long Form DIDs.

Recap

• Mention Update/Recover key pairs for generating DIDs and DID Documents
• Provide an example workflow for Issuers whose keys get revoked, including well-known documentation mechanism
• Provide guidance to holders on responding to issuer key revocation, with respect to past-issued VCs
• Related to above, better document interaction between issuers and verifiers, and how/if verifiers are expected to get up-to-date key information on issuers OR rely on holders to have pre-verified to an extent