Thank you for reviewing the document and the kind words, Michael. Further responses inline:
> I like that this document says to "solve" the challenge. RFC8555 does not seem to use that term, and that's a shame. I think I picked this term up from Lego (https://github.com/go-acme/lego) while I was modifying it to support this new challenge type. Is there another verb the WG prefers? Documents like 8737 or 8738 say "use with" or "validate". I think "solve" is good, too, but I'm happy to align with established ACME conventions. > and I find it hard to understand how [an OpenID Federation entity identifier] is different than a dns identifier. > Yes, it's a URL, not a FQDN. Well, I think URL vs. FQDN already suffices. The OpenID Fed spec ( https://openid.net/specs/openid-federation-1_0-43.html#section-1.2-3.4) mandates that an entity identifier be a URL, using the https scheme, and allows it to include port and path components. A name in DNS can't have a scheme, port or path, right? A further wrinkle is that the URL in the entity identifier _is not necessarily resolvable_. IIUC an OpenID Federation entity is not required to control the DNS name in its identifier, or even to serve any response to requests sent to the URL. Is a name that can't be resolved really a DNS name in any meaningful sense, or is it just a string? If a tree falls in a forest, and nobody is around, does it make a sound? Now you might say that OpenID Federation's definition of an entity identifier is rather surprising. I might agree with you. But I think that none of this messy ontology needs to be ACME WG's problem if we're careful about not violating the abstraction boundaries between draft-ietf-acme-openid-federation and openid-federation-1_0. The ACME document should treat things like OpenID Federation entity identifiers as opaque objects, referring to openid-federation-1_0 or other OpenID documents as necessary for more nuanced definitions and implementation guidance. My goal is that if openid-federation-1_0 eventually changes entity identifiers to be just 64 random hex digits, nothing has to change in draft-ietf-acme-openid-federation. > 1. clarify how stable openid.net/specs is. I suspect very, but it would be nice if that document said something. The document has no status statement. This is a good point. There's got to be IETF documents in places like JOSE that refer to OpenID publications, so I would hope we can draft off of whatever determinations those WGs have made about the relationships between the two SDOs. > 2. provide a few additional examples that make it clearer how the value is not a dns name. And a better reference to examples. Respectfully, I disagree, for the reasons I just laid out: I don't want draft-ietf-acme-openid-federation to become de facto responsible for defining what an OIDF entity identifier is or how to validate one. To cite a precedent: RFC 8737 and 8738 do not provide robust definitions of TLS ALPN or IP addresses (respectively). The reader is expected to refer to authoritative documents on either topic to get a complete understanding of what's going on. > It would be nice if the definition list in the section (token,trustAnchors,sig,trustChain..) was more clearly a definition list with intended definitions, or alternatively, they were clearly numbered (sub)+sections. The declarations in this section are modeled on RFC 8555 (e.g. the HTTP challenge in 8.3 https://datatracker.ietf.org/doc/html/rfc8555#section-8.3). RFC 8737 is structured similarly ( https://datatracker.ietf.org/doc/html/rfc8737#section-3). Can you provide an example of the preferred style? > Why is it a non-normative example? What would a normative example look like? It's non-normative in the sense that it's not a test vector that implementations MUST accept in order to be correct. It's an informative example of what this looks like to help readers understand. > I find that there is a lot of detail here, yet there isn't a lot of high-level explanation. > Yes, okay, but what about familiar with ACME, but not OpenID? Mike Ounsworth also raised this point, and while I stand by my philosophical point that ACME must avoid getting into the business of specifying OpenID Federation, I do think it's incumbent on the document authors to provide the ACME WG with enough context to responsibly contribute to the draft. It would help a lot to get more detail on what parts of OIDF are unclear so we can compile appropriate explanatory materials in this appendix (once again, this stuff would not appear in the published RFC). Do we just need a primer on what OIDF is, and perhaps how it compares to X.509 hierarchies? Would links to presentations or explainers from the OpenID community suffice? Tim On Wed, Dec 31, 2025 at 12:16 PM Michael Richardson <[email protected]> wrote: > > I realize that this review is late. > I've reviewed acme-openid-federation-01. It seems overly complete, and I > think we should have adopted it some time ago. I would not find fault if > it > went straight to a WGLC. > {I have purposely, not read the thread yet} > > I like that this document says to "solve" the challenge. > RFC8555 does not seem to use that term, and that's a shame. > > In section 4, an example of an openid-federation ID is provided with: > > https://requestor.example.com > > and I find it hard to understand how this is different than a dns > identifier. > Yes, it's a URL, not a FQDN. > I see that OPENID-FED is at: > https://openid.net/specs/openid-federation-1_0-43.html > and I see something that looks like an RFC/I-D, and section 1.2 seems to be > terminology. I'm then referred to RFC7519, RFC6749 and Connect Core. > Please could you: > > 1. clarify how stable openid.net/specs is. I suspect very, but it would > be > nice if that document said something. > The document has no status statement. > I understand that openid federation is authoritative for this, > and I'm fine with that. I wondered if an RFC is even needed for this, > given that all of the entries in RFC8555 9.7, are "Specification > Required" > and openid certainly counts as stable. > > 2. provide a few additional examples that make it clearer how the > value is not a dns name. And a better reference to examples. > > === section 5, trust chain or not. > > Maybe the distinction isn't between including a trust chain or not, but > rather between including a chain that leads to a trust anchor or not? > It would be nice if the definition list in the section > (token,trustAnchors,sig,trustChain..) was more clearly a definition list > with > intended definitions, or alternatively, they were clearly numbered > (sub)+sections. > > Why is it a non-normative example? What would a normative example look > like? > I find that there is a lot of detail here, yet there isn't a lot of > high-level explanation. While I can explain the high-level of > OAUTH/OAUTH-Connect to my mom, I am not an expert. So I'm exactly sure > what > is in the chain of signatures. It's a bunch of JWS... > > --- appendix. > This section contains explanatory material that recaps a lot of RFC > 8555. It is included here for the benefit of readers who are > familiar with OpenID Federation but not with ACME, and want to see at > a glance how the whole thing fits together. > > Yes, okay, but what about familiar with ACME, but not OpenID? > Diagrams are too wide for the text version. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
