need to clarify revocation vs. rotation #386
Comments
|
@SmithSamuelM already commented on this, but I want to directly answer @jandrieu's question. The whole point of digital signatures is that they are non-repudiable; they commit the signer to a historical action in a way that they can't deny. This is the basis for holding a party accountable. It's the non-repudiation that makes them useful. If I use Revocation is different. It presupposes a shared understanding between multiple parties that unambiguous history needs to be given new semantics based on future developments. With that understanding in place, it's possible to construct mechanisms that allow either party on their own, both parties together, or even third parties to apply new semantics to a historical event, no matter how strongly attested. "Yes, Fred really did sign this mortgage. No question about it. But Fred wasn't legally competent when he did so. Therefore the mortgage is invalid -- not because we deny existence of the signature, but because we are viewing the event with different semantics." We have to be able to tell the difference between rotation (unilaterally change rules for the future) and revocation (joint agreement about how/when to change semantics we apply to the past). If an issuer uses Besides, if rotating a key cancelled all previous assertions, how would we do the other operation (the one that merely changes future possibilities, without attempting to apply a new lens to the past)? I don't know what language in the spec, if any, we might want to revise to clarify this point, but I think there's no question this must be the understanding we impart. |
|
Yes the term revocation is used in two completely different ways in the identity space. In the key management world one may speak of revoking keys. In the statement issuance, authorization issuance or credential issuance world one may speak of revoking an authorization or a credential or a token. This becomes confusing when revoking keys also implicitly revokes authorizations signed with those keys. KERI terminology usually avoids that confusion because a key rotation operation is the equivalent of a key revocation operation followed by a key replacement operation. So one operation rotate instead of two operations (revoke and replace). A bare revocation is indicated by replacement with a null key. So only one operation is needed rotate where a special case of rotation is to rotate to a null key. Given that then in KERI revocation is usually unambiguous applied to mean revocation of authorization statements. When in doubt just use the modifier key revocation vs statement revocation. I hope that clarifies my terminology better. |
|
@dhh1128 Authorization tokens which are a form of signed statement often employ the rule 2) that when the keys used to sign the token have been rotated that this implies that the token’s authorization is revoked. Effectively the token is always verified by the current set of signing keys so it will fail verification after rotation. Whereas in Rule 1) the verification is w.r.t the set of signing keys used to create the signature at the time the statement was issued and signed. This means the verifier has to have a way if determining what the history or lineage of control authority was via a log or ledger to know that a statement was signed with the authoritative set of keys at the time. This means that the log or ledger must not only log the lineage of keys (key rotation history) but the statements signed by those keys (a digest of statement is sufficient). Otherwise a compromise of the current signing keys (which rotation protects from) would allow an exploit to create verifiable supposedly authorized statements after the keys have been rotated. So it either must be rule 1 or 2 or 3. And non-automatic revocation of signed statements requires a log of both the key rotation history and signed statement history. Obviously if keys are not rotatable, then any signed statement may not be revoked by merely rotating keys but instead a revocation registry may be used to determine if a signed statement has been revoked by explicitly using a revocation statement. So non-rotatable keys may use a modified rule 4) where there is no key rotation history log or signed statement log but merely a revoked statement log. Although typically non-rotatable keys are used for ephemeral identifiers, in which case, revocation log is not used. Instead of rotating keys for ephemeral identifiers you just rotate the identifier (make a new one with a new set of keys) and abandon the old identifier and all its signed statements. |
|
This makes sense to me. I always try to map these discussions into the healthcare use case where the physician is licensed by the DEA IFF they can be held accountable for signing a (controlled substance) prescription in a non-repudiable manner and also the prescription can be revoked when dispensed or "lost". Under the DEA rules, the physician's authority to sign that prescription, can flow one of two ways. Either the process and tech itself is certified and audited, or another DEA credentialed person (maybe another physician or notary) is held accountable for issuing the credential of the prescriber. The issuer physician as effectively a notary. They are examining the process and other claims of the would-be prescriber, signing using their non-repudiable signature AND, importantly, making a log entry that they, as the notary, will keep of this transaction. The notary binds the issuing process (typically represented by a document such as a loan) to a non-repudiable signature of the prescriber (because the prescriber shows the notary a deduplicated, legally binding credential like a drivers license.) This use-case is relevant because it is decentralized. The self-sovereign prescriber chooses the notary. The notary's logs are not public or aggregated but they are secure and auditable. The notary's logs have a reference to the document (the digest @SmithSamuelM mentions). For some related detail, here's a link to the recent HIE of One DHS SVIP (rejected) proposal for Trustee(R) Notary which I truly hope some in our community help us with. It's turtles all the way down in the sense that the self-sovereign prescriber then takes on the role of issuer when Alice wants her Adderall. The prescriber signs her prescription, coded as a verifiable credential, and keeps the log with the digest of the prescription in case of audit. Revocation, of this VC remains an unsolved problem and this is where the DID aspect of SSI decentralization threatens to break down because the revocation mechanism has to be centralized and incredibly privacy-invasive for Alice. It's called a prescription drug monitoring program (PDMP) and the privacy issues they raise would fill a book. Since this issue is about revocation of a VC, I would suggest that we need to give data holders the option to avoid the centralized revocation privacy problem by letting them authorize the verifier to get the VC directly from the issuer instead of passing the VC through an intermediate store. This is a privacy compromise because it leaks information to the issuer but it avoids the rotation problem because the VC can be ephemeral. Our SSI designs #382 must not take this option away from Alice. The logic is described in #370 (comment) |
|
Consider that https://developer.okta.com/docs/concepts/key-rotation/ ^ the did document use case is identical, it just does not require HTTP or JWK/JWKs. absence of a singing key in the expected location, implies revocation of all signatures.... you can see why caching can cause security issues. ^ this statements applies just as much to VCs as it does to |
|
@OR13 You are confirming that in token based security systems verification of a token is against the current set of signing keys not the keys that were authoritative when the token was issued. That is they use Rule 2). This is in direct opposition to what the normal use case for VCs which is verification is against the keys used to issue the VC not the current set of keys. That is rule 1). Hence the confusion. |
|
Here is a related Issue in DIF for KERI use case for key rotation in IoT. |
|
I think the ambiguity here is that how to interpret DID:Docs. Does a DID:Doc act like an OIDC authorization token which uses rule 2) or a verifiable credential which uses rule 1). I suppose it depends on the DID method. This is one of the security problems of DID methods. There is no good expectation of behavior from one method to the next. |
|
I agree that this is an under estimated issue. I brought up at the face-to-face in Amsterdam (and in a related issue #168) that we currently have no way to record in the DID Document anything about a key that is NOT currently valid. I believe ALL spec-text in both DID and VC work discusses that the validity of the VC is checked against the current DID Document. The notion that you need a "version" parameter in a DID URL (so you can check to see if a VC would have been valid) was also discussed in a side chat in Amsterdam, with what I thought was agreement that the current specification--even with a ledger-based tamper-evident history--cannot make any valid statement about whether or not a key was valid at any particular point in the past, precisely because there is no way to know if the key was revoked or rotated. If retirement is revocation because it was compromised, then you absolutely MUST not treat that key as valid. If retirement was because of rotation, I can see that past-credentials signed by a rotated key might be appropriate, but can also see arguments that rotation on its own doesn't mean that old keys should still be considered valid, especially when you can't know for certain when the VC was signed. It might have a date in the past, but be signed after the compromise, BY the party that compromised it. So, two directions here.
I'd support adding language that changes the conclusion from #168 to allow explicit statements of rotation, revocation, or both, but other participants rallied rather convincingly against exactly that option. |
This is not correct. https://w3c.github.io/vc-data-model/#proofs-signatures-0
There is no difference between verifying a JWS with an The logic the verifier performs is the same. dereference the If dereferencing fails the token or credential fails verification.... the status of a verification of a token is orthogonal to the concept of getting a new VC / token because some key rotation occurred. If you encode a DID Documents are not VCs... DID Documents are well known jwks uri controlled by the did controller. https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig In OIDC, it goes like this:
In DID + VC, it goes like this:
The fact that a person can look at past versions of the JWKs, and see points in time where a JWS would have been valid is orthogonal issue, it's useful for forensics, but it does not answer the question of "does this token / vc verify now". The answer to "does this token / vc verify now" is obtained by dereferencing the verification method / iss + kid, and using the public key bytes to check the signature. If dereferencing hits a cache / or relies on a read of an eventually consistent system (like a blockchain or slow distributed data base)... the answer might change when consistency is achieved or the cache expires. If dereferencing is guaranteed to always produce public key bytes, thats like issuing from a did doc that does not support key rotation, like If Hyperledger Indy based ZKP Proofs do something different here, thats possible, I am not as familiar with how they do or do not support rotation of issuance material. |
I strongly disagree. Verifying now has to be a question of whether the assertion was valid then (where "then" is the moment the assertion was made). All legal precedent is based on this kind of analysis. We're in court, arguing about whether Alice should be held accountable for transferring a million dollars to Bob's account. Alice says, "I now consider Bob a shyster, and I don't like what he's doing with my money. I don't stand by the signature I affixed to the transaction. I want my money back." Bob says, "Well, Alice may not like me, but did she or did she not sign?" Who is going to win? Signing a VC is no different than signing a a money transfer -- and indeed, VC use cases that involve money (or that have any sort of legal meaning) will depend on these semantics. Any other interpretation gives the issuer unilateral power to deny what they've said on the record, makes reputation useless with respect to issuance, and undermines the whole system. |
|
BTW, the need to have some kind of unwinding of assertions is the reason why we need a VC revocation feature. If an issuer knows in advance that they may have reasons for withdrawing their support from an assertion, they can publish to the world their intention to support revocation with respect to the VCs in question. For example, a driver's license bureau can say, "We're making our driver's licenses revocable. When we revoke a driver's license, this means we have learned since the date of issuance that we no longer want to assert the person's right to drive. If a license was issued on Jan 1 and is revoked on July 1, the person no longer has the right to drive after July 1. But if the person is sued for a reckless driving incident that occurred on May 1, revocation doesn't mean that their right to drive on May 1 was retroactively cancelled. They were indisputably a licensed driver on May 1; revocation took effect from July 1 onward." |
|
I copied this discussion to the DIF KERI repo because it had relevance to KERI but realized that new comments by Orie that I responded to were there not here. These are relevant. decentralized-identity/keri#52 (comment) |
|
The conflict is the verification model or rules. As I pointed out above, authorization tokens use a different rule than what most VCs use. The rule for authorization tokens is automatic revocation of the token if keys are rotated. So in this sense @OR13 is right that a log of when an authorization happened is merely forensic since a key rotation revokes all tokens issued prior. One may call this an ephemeral authorization model. Tokens carry an ephemeral authorization that does not require a specific revocation action. Key rotation simplicity revokes. However the VC model of Issuer, Holder, Verifier is a persistent authorization model. The credential is valid until specifically revoked. which means that the only way to determine how to verify the credential is to know the history of revocations. Its true one could embed the public keys used to issue credential in the VC but then one still doesn't know if they were valid at the time of issuance (a type of replay attack) unless one knows when in the key rotation history the credential was issued. In this regard @dhh1128 is right. |
|
There seems to be some strong cognitive dissonance on verification models. This is why I detailed the three choices of rules. 1) 2) and 3). So one can pick which set of rules one uses but that selection determines how you build your system. There are all valid choice but not simultaneously valid in the same system. One has to pick. |
|
This is one reason why "token" security models are not necessarily a good fit for VCs. They use an ephemeral model of authorization and VCs use a persistent model. They are not the same and should not be confused. |
|
What that means is that tooling designed for the ephemeral model is of little use in a persistent model. Trying to leverage tooling from one model for the other will be an exercise in frustration. |
|
Using an ephemeral model for DID:Docs and a persistent model for VC issued against DID based on those DID:Docs will likewise be an exercise in frustration. |
|
AFIK most implementations of Object capabilities also use an ephemeral authorization model, although there is nothing in the object capability concept that requires it. An implementation could use a persistent authorization model. But clearly credentials are much more than authorization tokens and that means IMHO that a persistent authorization model works best for them. As the uses cases for both DIDs and VCs clearly express. This may be yet another "issue" that is problematic for the DID spec community because we have a clash of unexpressed but assumed authorization models for DID:Docs and VCs. |
|
VCs are the new kid on the block. There were designed without expressing conceptually what their authorization model looks like. But revocation registries clearly indicate that its a persistent one. This becomes glaringly obvious when you answer the question. Does key rotation of the issuing DID require that all issued VCs must be re-issued? If the answer is no then your have a persistent authorization model. If yes then an ephemeral one like a token. |
|
So we can ask the same question of a DID:Doc. If I use a persistent authorization model for a DID:Doc then I have just made it possible to use a VC as an ersatz DID:Doc. |
|
If DID resolution metadata returns a proof of control authority (BTCR, KERI, Sovrin State proof) then I don't need a Did:Doc to use a DID. I can just use the DID resolution meta data to establish authoritative signing keys and then issue a VC that contains everything else I ever wanted to put in the DID:Doc. The DID Spec gets really simplified as a result. The serialization wars and interoperability between serializations becomes a non-issue. |
|
@dhh1128 I agree with your basic argument, that the use case for checking a signature would benefit from being able to check if the signature was legitimate at the point of signing. However, can you point to any spec text in VCs or DIDs that describes verifying anything in that manner? I think we have quite a bit of work to do to adjust the language and existing consensus to support how you have been thinking about this requirement. If there is language in existing spec-text that already discusses verification of credentials for which a key had been rotated (and hence, not in the current DID Document), then we can build on that. But, when you say
I don't see anywhere in the actual standard that supports this. So, any spec text you can point to will go a long way to helping us build some bridges. My attempts to address this exact point (in issue #168) were roundly rebuffed by multiple, competent members of this community. So, we have some work to do to get support for what you want. |
|
@jandrieu I would be very surprised if the spec text mentioned such a requirement. As I pointed out above it has now become glaringly obvious that the authorization model has been an "unexpressed but assumed one" and as this issue points out. One that is assumed differently by different practitioners. Its only recently that security models has had more than a smattering of discussion in the DID spec. IMHO it was just assumed that if one is using a ledger than security comes for free. But the DID methods are a security problem and did:doc authoritativeness is just one aspect of that bigger problem. So the answer is not to point to existing spec language but to point out that we need spec language otherwise we will run aground yet again on security.. |
|
Small note to indicate that I think the persistent model is required for DID Docs, and I support the separation of concerns between revoking keys and revoking credentials. Let's revoke credentials independently. |
|
@jandrieu "My attempts to address this exact point (in issue #168) were roundly rebuffed by multiple, competent members of this community. So, we have some work to do to get support for what you want." It think there is a nuance between what we are discussing here and issue #168. Unfortunately, its an issue that quickly gets muddled. In the KERI concept of a Self Certifying Identifier (SCID). There is a root control authority that is held by the controller of the SCID. Because the derivation of a SCID consists of one or more cryptographic one way functions from a public key or keys. It is very clear how that root authority starts is held and may be exercised. It is starts with the public keys used to derive the SCID and is held and may be exercised by the holder of the associated private keys. So where I talk about key rotation I am only talking about the key rotation associate with this root authority not any other set of keys. So any other keys besides the root authority are immaterial to establishing and maintaining this root authority. This "other" keys may be encryption keys or delegated signing keys or any number of keys but they are not participants in the root authoritative keys (although they may be derived therefrom). So in this issue the discussion on key rotation is solely about the root control authority. With reference to a DID:doc then when one has a clear sense of the keys that constitute the root authority for the identifier then it becomes obviously clear that those are the keys that are the root authority for the DID:doc as well. Any other construction is fraught with potential security problems. The idea that a did:doc is some generic key authorization mechanism causes all sorts of confusion because one feels enabled to partition root control authority among multiple sets of keys. Then rotation almost becomes non-sensical. There be dragons. Clearly root control authority needs to be precise and atomic. If one is using multi-sig then there are multiple keys in the set but they are all of the same class in terms of authority and belong to a defined multi-sig scheme. They are not a hodge podge of keys with varying degrees of authority or function. |
|
So, @SmithSamuelM, that suggests we need to be clear about the reality that one cannot rotate the "root keys" that control a DID Document, you can only revoke them? And as such, the current design for root authority works for you? Namely, that if a root authority is not present in the CURRENT DID Document, then it cannot be used for verifying a VC as current? The consequence of that is that--even in a version of DIDs that aligns with KERI--if you want to be able to rotate the keys without invalidating a VC, then you cannot sign the VC with the root authority. Perhaps you can sign it with a key in a verification method other than the root authority, but the root authority itself is revoke-only, not rotatable, and hence not usable for rotation-surviving VCs. Correct me if I'm misunderstanding. HOWEVER, we still don't have a way for a non-root authority to be specified as valid for VCs issued for some specific period. Some DID methods may allow an implicit capability for this (DLTs can be used as timestamps), but there is currently no way to state that a given proof mechanism should be treated as valid for proofs in a certain time frame while a different proof mechanism should be treated as invalid. The only check we have now is for the proof to match a verification method in the CURRENT DID Document. Which means rotating a key invalidates all previously issued credentials. The current language, to the best of my knowledge, has zero support for rotating keys of the issuer while maintaining the validity of existing VCs. What we do support is the rotation and revocation of a subject's keys, such that proof-of-control as identity assurance regarding claims in a VC remains functional throughout the lifetime of the DID. Because proof-of-control is based on the current DID Document, so there is no notion that older proofs-of-control remain valid. I realize the Evernym world doesn't use DIDs for subjects that are human individuals, but others in this ecosystem rely on that rotatability for long-lived credentials, where the privacy benefits of link secrets is outweighed by the rotatability of keys in DID Documents. So we can't get around this by saying "But DIDs are for public entities!" As Drummond did in #382. Again, I agree it would be worthwhile to support statements that a particular key should be considered valid for proofs created in a limited time frame. But we currently have no way to do that. Unless someone can point to some spec text that gives us that ability--or asserts that ability even if vague on how--then I fear we are stuck trying to solve a problem that is, at this point, a new feature. |
|
@jandrieu I guess I wasn't clear. The root authority is transferable to a new set of keys via a rotation. That is what KERI does is provide a key rotation methodology for the root authority. |
|
@msporny What is my deadline for raising a PR? |
I expect that the PR needs to be in by the end of this month. I can't give you a firm date as the WG hasn't decided when it's entering CR... just that it's "really urgent that we do so as soon as possible". We expect to have the remaining major issues resolved this week, and with a few weeks of time for the Editors to get the spec into shape... I expect we'll start the process of closing/deferring this week with the process increasing in intensity through the end of the month. The sooner the better... PRs raised this week have a better chance to be refined by the end of the month than a PR submitted towards the end of the month. |
|
@dhh1128 -- you said in #386 (comment) (Yes, that was a while ago.)
I think you meant "letting a borrower off the hook". Rather different meaning. I think it's worth correcting that comment, because whether a PR goes in for this Issue now/soon or this Issue gets tabled until the next spec that branches from DID-Core (or until one or more separate DID Method specs, as I'm currently thinking most likely), others will be re-reading this thread to understand and/or write the PR(s) that address(es) it. |
|
@TallTed : Thank you for the catch. You're correct that my fingers moved faster than my brain when I typed that comment. :-) I've now fixed it. |
|
I will try to address this with non normative language that accounts for #337 |
|
I took a stab at this in #548 I took a pretty strong stance on the "revocation is forever" side of this debate.... While solutions that require a blockchain / special kinds of VDR might exist might allow for relative confidence that a revoked key was used by the controller and not the attacker, I find no evidence that this is sufficiently described in did core to be even hinted at in the spec... As as such I have separated the stew we had before into 3 categories:
I am aware of some community perspectives that a certificate from a "revoked key" should still be valid / trusted "assuming
I think this may close the door on some folks who were planning to get creative with |
|
Instead of copying and pasting and reformatting. Section 4 of the following white paper provides my view on this issue. https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf |
|
My approach is to separate key management (rotation =revoke and replace keys = recovery) from statement management (issue and revoke). IMHO we want to have standards that allow loose coupling between the two. Its ok for an application to use a tightly coupled model (as the white paper above indicates when it looks at the 4 models) but not for the standard to force tight coupling. Thus the only way to allow loose coupling is to to separate key management from statement management at the standards level. |
|
Related to this issue is authorization models. Keys are used to authoritatively authorize statements. So statement authorization verification models also play a role. The following white paper characterizes the most common authorization models for statements which might also bring some additional rigor to the discussion. https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf See section 3 property comparison for the different models of authorization. Understanding how the model properties differ provides additional information as to why we want a separation between key management and statement management. |
|
@OR13 and @dlongley : Please tell me if I have understood your concern accurately. I think you're worried that an issuer could use key A from Jan 1 to June 1, and then revoke key A. Then, on July 15, a malicious party could get key A and use it to sign a credential, claiming that the issuance date was months before, when key A had not yet been revoked. Essentially, possession of the revoked key allows an alternate past to be invented. Have I understood your concern accurately? There are several solutions to this problem (I'd be happy to go over some), but I claim it is not the DID spec's job to provide them. It is just the DID spec's job to provide a way to reference a state of a DID at a particular point in the past. That is using the The DID's state in the past is immutable. We cannot give the future the ability to rewrite the past. You are worried about a malicious use of the key rewriting the past; I am worried about a malicious use of revocation rewriting the past. Neither is acceptable. That is why I am opposed to Orie's verbiage in #548; revocation cannot be retroactive. |
I agree with your entire post and that has been my position from the beginning :). +1 to consensus! |
|
My main points (which I think you also agree with):
|
|
PR #569 has been merged, closing. |
|
Late to the party. Is there a summary of the consensus? I landed here because I was wondering how a verifier would verify a credential signed with a key that has since been rotated. Am I correct that this would require each DID document to persist its entire history of keys forever and that the verifier either knows which specific key to look for or needs to "crawl" through the history of those keys? Thanks |
This is an involved use case that probably doesn't have a consensus answer at this point, so the following are just my thoughts (as the Editor of the specification and an implementer): DID Documents probably won't "persist its entire history of keys forever". Some DID Methods might choose to do this, but you probably won't be able to count on that feature. DID Documents that are stored on DLTs will probably provide some sort of "historical DID Document" feature that allows you to see if a key was valid at a certain point in time. With these DLT-based DID Methods, where you can check a key's status at a certain point in time, it would be possible to tell if a credential was every valid at a certain point in time. Though, you're going to be dealing with the least common denominator here, and that's going to be... for an active verification on a credential, if a key has been rotated, the verification on the credential will fail (because the key will not exist in the latest DID Document for many DID Methods). Hope that helps, just my $0.02. |
|
Thanks. I'm surprised that the default would be rotation=revocation, this seems less than ideal, but I guess I don't really see a way around that. Wouldn't this be a common situation? It feels like verifiers will routinely bump into rotated keys. I guess the holder of the VC, via an agent, could periodically hit the issuer's "refresh service" just in case the issuer happened to have rotated the signing key, but that seems awkward. Or maybe the holder, when presenting the VC to a verifier, could hit the refresh service for the VC before wrapping it in a VP? Alternatively, the DLT-based "historical DID document" feature you mention will become a must-have feature |
-1 ... rotation doesn't mean removing the verification method from the DID document; that is revocation. See: https://www.w3.org/TR/did-core/#verification-method-rotation Rotation involves decommissioning or destroying the secret key material associated with a verification method so that it is no longer used. This does not mean that the public key material is removed from a DID document. That may happen for keys that are intended to be short term, but it would be bad practice for long term keys. That being said -- the rest of your comments regarding history and being able to see if a proof was valid at a previous point in time are applicable for cases where verification methods are revoked. |
|
+1 to the clarification that @dlongley made above.
You might want to read how a refresh service spec might work first: https://w3c-ccg.github.io/vc-refresh-2021/#refresh-protocol Again, just my personal opinion for now... I expect that, eventually, credential validity periods will be less than half of a key validity period (including rotation and then, eventually, revocation). If we have automatic credential refresh, you'll get a new one, for the new issuer key before they end-of-life the old issuer key (via revocation). The time periods will largely depend on the issuer and use case. I expect much of the industry to settle on Let's Encrypt-like practices for credential validity (3 months) and key rotation/revocation (2-3 years to rotate, 5 years to revoke -- presumption on HSM-backed issuer keys).
This could result in DDoS for large issuers... the current refresh protocols we have suggest a time window when holder software should try to refresh.
We can't make the feature a must have... some DID Methods will never be able to/want to support it (did:key, did:web, did:git come to mind). |
Creating a new issue to track a tangent to #382.
There appears to be a misalignment in the community about the semantics of changing a key associated with
assertionMethodin a DID doc. The relevant comments from #382:#382 (comment)
#382 (comment)
Tagging @jandrieu and @SmithSamuelM who have already commented on the topic.
The text was updated successfully, but these errors were encountered: