Original text:
Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement. <del> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. </del>  The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document.

Reviewer comments:
with unclear definition and regex requirements with DN currently in draft.
Calling NAME for some
Perhaps I missed it, but what is the motivation of changing to a URI?
We are specifically customizing the usage of in CWT as defined in . In that document, it is a type and it seems like we shifting away from the base usage of URI to something else and with a regex spec I couldn't find in a relevant I-D, RFC, or standards doc that we can normatively cite as a reference. Is there something I am missing, and is there a valid reference we could use?
I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the must be a URI with no further specification is equally unsatisfying. How about we drop any mandate to use a particular format of if the protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the value is largely redundant.
There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear? I don't mind that if others have that feedback I'll close this out and start over. That will obsolete the feedback from Hannes that triggered this PR at the same time. I can bring that on list and reference this discussion.
Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the value, we can reference RFC 4514.
I can also bring that up as an option on list and adjust accordingly if that is ok.
I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.
It is similarly unclear to me in the architecture requirements what one should or must do with the DN. It is implied, but left to the implementer to decide for desired X.509 use cases. It is not clear what one should do with it to correctly validate the cert use per the claim, regardless of DN or URI is chosen. Can we both agree that is part of the problem?
In any event, I apologize for the delay, I have created the following thread on list to discuss before moving forward with the PR in any significant way. I may stand corrected and others will prefer your approach (which I dubbed Approach ). URL
Deferring 'till the week of 8/19 as some folks are on vacation.
I support this change on behalf of the URL project.
8192 characters in length that fits the regular expression of a distinguished name. What is the "regular expression of a distinguished name"?
I do understand the intent, but it would seem that distinguished name is not clearly going to have a specific reference we can use. That reference sets aside the regex requirement. I understand the need but there is some assorted LDAP RFCs and other attempts, but none seem to be the right kind of reference, even if about distinguished names in X.509. I am going to propose we go back to what we know and then put forward my understanding and interpretation of the requirement, that we want a StringOrURI like the underlying CWT requires, perhaps with added length requirements?
LGTMLGTM Hello, Last week I attempted to pick up some issues thanks to the many contributions by Hannes Tschofenig. One such issue requesting clarification or change is issue . For that, I made an associated PR, pull request . URL URL So far there has only really been feedback from Corey Bonnell (and that has been most appreciated!). I wanted to poll the list for feedback and understand if there is consensus on using the X.509 Distinguished Name for the issuer of the claim, whether or not there is a clear regex and length requirement. The current text reads like so. characters in length that fits the regular expression of a distinguished name. https://ietf-wg-URL I see a few ways forward. Do nothing, leave the current statement in the specification as-is, and close the issue reported by Hannes as a WONTFIX because it is good enough. Keep the Distinguished Name, and add a useful regex from a relevant LDAP specification proposed by Corey in his comment, RFC4514. Adapt the requirement to match a subset of the underlying data type of the CWT claim iss field, URI (from stringOrUri), and not add an additional requirement for DN regexes and format parsing. Be most permissive and interoperable, remove this requirement entirely. Corey appears to support 2 (please correct me if I am misrepresenting your position, Corey), whereas I prefer 3. I understand the intent of further constraining iss in the presence of X.509 certains and checking against their thumbprint. It makes it more convenient and consistent for the case of Issuers creating Signed Statements with X.509 certificates as a first class solution, but at the expense of the alternatives (short-term and long-term) and resulting interoperability in the long-term. Additionally, the requirement as-is appears to adapt the CWT field to match a differing purpose from its base specification that key use in the context of SCITT. To me, that seems undesirable. Do others have support for one of these positions or related feedback that motivated the current state of the change? Given the feedback over the next week, I will modify or close PR accordingly to meet consensus of authors and WG members who respond on list to the best of my ability. Sincerely, A.J. Stein

Revised text:
Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement.  <ins> When "x5t" is present, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </ins> The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document.