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
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
