Add issue references per 2024-03-07 meeting

Author: scouten-adobe

spec/did_resolution_options.md

@@ -1,5 +1,9 @@
 ## DID resolution options
 
+::: issue 
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/6: Planned review by of this section by task force
+:::
+
 This DID method introduces a new DID resolution option called `x509chain`:
 
 Name: `x509chain`

spec/identifier_syntax.md

@@ -1,5 +1,9 @@
 ## Identifier Syntax
 
+::: issue
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/5: Planned review by of this section by task force
+:::
+
 The `did:x509` ABNF definition can be found below, which uses the syntax in [RFC 5234](https://www.rfc-editor.org/rfc/rfc5234.html) and the corresponding definitions for `ALPHA` and `DIGIT`. The [W3C DID v1.0 specification](https://www.w3.org/TR/2022/REC-did-core-20220719/) contains the definition for `idchar`.
 
 ```abnf
@@ -26,6 +30,10 @@ In this draft, version is `0`.
 
 The following sections define the policies and their policy-specific syntax.
 
+::: issue
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/8: Re-evaluate Rego vs alternative descriptions of policy.
+:::
+
 Validation of policies is formally defined using [Rego policies](https://www.openpolicyagent.org/docs/latest/policy-language/), though there is no expectation that implementations use Rego.
 
 The input to the Rego engine is the JSON document `{"did": "<DID>", "chain": <CertificateChain>}`.
@@ -68,6 +76,10 @@ The overall Rego policy is assembled by concatenating the core Rego policy with
 
 ### Percent-encoding
 
+::: issue
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/4: Can this section be rewritten more fully in terms of RFC 3986?
+:::
+
 Some of the policies that are defined in subsequent sections require values to be percent-encoded. Percent-encoding is specified in [RFC 3986 Section 2.1](https://www.rfc-editor.org/rfc/rfc3986#section-2.1). All characters that are not in the allowed set defined below must be percent-encoded:
 
 ```abnf

spec/operations.md

@@ -18,6 +18,10 @@ Finally, whether a `did:x509` should pin to an intermediate CA instead of a root
 
 ### Read
 
+::: issue 
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/10: Add discussion on timestamp of signature issuance relative to cert validity
+:::
+
 The Read operation takes as input a DID to resolve, together with the `x509chain` DID resolution option.
 
 The following steps must be used to generate a corresponding DID document:

spec/security_privacy.md

@@ -2,6 +2,10 @@
 
 ### Identifier ambiguity
 
+::: issue
+https://github.com/trustoverip/tswg-did-x509-method-specification/issues/8: Review this section.
+:::
+
 This DID method maps characteristics of X.509 certificate chains to identifiers. It allows a single identifier to map to multiple certificate chains, giving the identifier stability across the expiry of individual chains. However, if the policies used in the identifier are chosen too loosely, the identifier may match too wide a set of certificate chains. This may have security implications as it may authorize an identity for actions it was not meant to be authorized for.
 
 To mitigate this issue, the certificate authority should publish their expected usage of certificate fields and indicate which ones constitute a unique identity, versus any additional fields that may be of an informational nature. This will help users create an appropriate `did:x509` as well as consumers of signed content to decide whether it is appropriate to trust a given `did:x509`.