- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 4 Jan 2022 09:47:56 -0500
- To: public-credentials@w3.org
On 1/3/22 3:39 PM, John, Anil wrote: > Manu -- could you provide a perspective on the > flexibility/optionality/signaling of support for these capabilities by the > issuer? The signalling is done through the Verifiable Credential itself: https://digitalbazaar.github.io/vc-refresh-2021/#example-verifiable-credential-specifying-a-manual-credential-refresh-0 Thus, anyone in possession of the credential knows how the credential can be refreshed. For automatic refresh, the protocol is detailed here: https://digitalbazaar.github.io/vc-refresh-2021/#autorefresh2021-protocol You will note that the final step results in a Verifiable Presentation Request, and that a Verifiable Presentation Request can include any number of requests for Verifiable Credentials, including DID Auth. For VCs that are bound to DIDs (such as the USCIS PRC), it is expected that a renewal will require a DID Auth, which is typically performed by the Holder. Thus, the specific flow for most VCs that are bound to DIDs is expected to be: 1. Holder's "Digital Wallet" determines that VC is expiring soon, and notes that the VC has "refreshService" set with "AutoRefresh2021". 2. Holder's "Digital Wallet" executes AutoRefresh2021 protocol, resulting in a Verifiable Presentation Request from the Issuer that includes a DID Auth challenge. Optional: The soon-to-expire VC is also requested in the Verifiable Presentation Request. 3. Holder's "Digital Wallet" creates a Verifiable Presentation and sends it back to the Issuer. 4. Issuer verifies and validates all information received from the Holder, and if everything checks out, sends an updated USCIS PRC VC back to the Holder. Fundamentally, this is the same as walking into a physical office, showing your existing PRC, giving the expiring card back to the office, and getting your new PRC from the office. In this case "giving the expiring card back to the office" doesn't need to be done, the Issuer can either explicitly mark it as revoked once the renewal is done, or let it naturally expire. > Context -- In the work we (U.S. Citizenship and Immigration Services which > is a DHS Operational Component) are doing in the issuance of digital > personal/immigration credentials (U.S. Permanent Resident Card, U.S. > Employment Authorization Document etc.), we made a concrete/explicit > decision that our Issuer infrastructure *WILL NOT* support a refresh > request coming directly from the Verifier as it removes "... control and > consent from the holder and allow the verifiable credential to be issued > directly to the verifier, thereby bypassing the holder" (as per VC Data > Model Section 5.5 Note). We explicitly require the Holder to be in the > loop for such a request for privacy, accountability and business process > reasons. Yes, a Verifier submitting a VC for this renewal use case would be rejected by the issuer since the Verifier can't do a DID Auth on behalf of a Holder. > Is there some manner of an indicator/signal that is part of this refresh > request that can be implemented by the Issuer to notify the a caller of > what we support and what we do not? The signal is in the VC itself, specifically: { ... "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", ... }, ... "refreshService": { "type": "AutoRefresh2021", "url": "https://example.edu/workflows/refresh-degree", "validAfter": "2022-01-05T19:23:24Z" }, ... } If the Holder has a VC with the above, their software knows that it can perform an automatic refresh after 19:23:24 UTC on 2022-01-05. The Issuer will, presumably, do a DID Auth against "did:example:ebfeb1f712ebc6f1c276e12ec21" before it provides the updated VC with the new expiration date. If anything looks fishy to the Issuer, the Issuer can always return an error code and a URL that the Holder might need to interact w/ manually (or physically walk into an office because something didn't check out when doing the automatic re-issue): https://digitalbazaar.github.io/vc-refresh-2021/#example-step-2-response-from-issuer-verifiable-presentation-request I answered more than the question you asked, hope the above makes sense. If it doesn't; happy to elaborate. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Tuesday, 4 January 2022 14:48:13 UTC