Tim Geoghegan <[email protected]> wrote: > 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.
No, I'm saying I love it, and I want "solve" to be the term of choice!
>> 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?
All I'm asking is that the distinction and reasoning be a bit more explicit
in this document. I am willing (as a reviewer) to chase one level of
indirection, but when I did, I got two more levels of indirection.
(Many junior coders will just make an assumption at this point. And then
consider operational people debugging...)
> 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.
I don't care exactly, I just want three more sentences to give me a slightly
intuitive understanding :-)
>> 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.
If you can't influence openid to put a status statement on their document,
then maybe there is a way, as you suggest, to indicate the status.
>> 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.
Yes, but I failed when indirecting.
>> 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.
okay, so should I conclude that this example isn't correct in some way.
>> 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
I said above: I don't know what the identifier is beyond that's URL-ish.
Are IPv6 literals supported? Username/password?
But, you have disagreed with doing that.
--
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]
