<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 13 Aug 2019, at 15:14, Marcos Sanz via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">I had a chance to go through the federation draft (though I admit I <br class="">skipped the appendixes because I found them a bit difficult to read) and <br class="">have a couple of comments to make. I have separated comments in category <br class="">"discussion-prone" and simple nits:<br class=""><br class="">Main things:<br class=""><br class="">- Section 5: The usage of well-known URIs is different to what I have seen <br class="">in other OpenID specs: Usually, at the well-known URI you'll find a <br class="">(static) document that will inform you about configuration parameters, <br class="">discovery information, URIs of actual endpoints of the service, and so on. <br class="">However, the federation spec is running the federation API directly under <br class="">"/.well-known/openid-federation". This is, for starters, a break with the <br class="">existing practice in the spec family. I then tried to look for standards <br class="">advice on the topic. In the (now obsolete) RFC 5785 there was the <br class="">following guidance text:<br class=""><br class="">"well-known URIs are not intended for general information retrieval or <br class="">establishment of large URI namespaces on the Web. Rather, they are <br class="">designed to facilitate discovery of information on a site when it isn't <br class="">practical to use other mechanisms". Also from 5785: "the well-known URI <br class="">space was created with the expectation that it will be used to make <br class="">site-wide policy information and other metadata available directly (if <br class="">sufficiently concise), or provide references to other URIs that provide <br class="">such metadata".<br class=""><br class="">Both sentences have admittedly disappeared in the younger RFC 8615, but <br class="">you'll still find text in 8615 speaking of "metadata discovered by <br class="">dereferencing the well-known URI", which somehow implies what the <br class="">expectations are when you visit that URI, namely, metadata.<br class="">Now you could claim that fetching entity statements and doing trust <br class="">negotation is acquiring metadata from the federation, but I think that's <br class="">executing business logic of the API ("Application _Programmers_ <br class="">Interface", see? ;-). On top, I see operational problems in front of us if <br class="">the spec sticks to this well-known URI usage: if it's already difficult to <br class="">place a static document for a service like IdP discovery under <br class="">.well-known/webfinger in the generic domain <a href="http://amazon.com" class="">amazon.com</a> (I heard that from <br class="">an authoritative source at the IIW last year), go figure if you want to <br class="">run application code there.<br class=""><br class="">All in all, I defend using the well-known URI of the federation to <br class="">discover a document where the actual Federation API endpoint is listed. <br class="">(If you all have already discussed about this and then dropped it, then <br class="">I'd be thankful for a pointer in the archives).<br class=""></div></div></blockquote><div><br class=""></div>You’re the first who have commented on this. </div><div>I have no problem with accepting your proposal. In fact I have seen exactly the</div><div>DNS problem you refer to,</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Section 5.4: This looks to me a bit rudimentary. I wonder whether using <br class="">RFC 7807 and the associated media type application/problem+json wouldn't <br class="">be more appropriate to carry problems around. One downside of this, <br class="">though, it's that it hasn't been used so far in the OpenID specs I know <br class="">of: if I used consistency within the spec family as an argument before, I <br class="">should be able to accept some pushback here :-)<br class=""></div></div></blockquote><div><br class=""></div>I definitely wants to follow in the footsteps of the core specs,</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Section 8.1.3: This is underspecified and "fails-to-establish-trust" is <br class="">a place where many things can go wrong. I think the spec should take the <br class="">effort of defining a base set of error codes, the same way for instance <br class="">that the core spec does in section 3.1.2.6. Further, using a catch-all <br class="">"invalid_request" code, which originally was thought as for indicating "<br class="">The request is missing a required parameter, includes an invalid parameter <br class="">value, includes a parameter more than once, or is otherwise malformed" <br class="">(RFC 6749), is a misuse.<br class=""></div></div></blockquote><div><br class=""></div>OK, I’ll work on this.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Nits<br class="">- Section 1.2: Definition of "Trust Chain" uses the expression "trusted <br class="">chain", which is self-referential<br class="">- Section 4: s/polices/policies/<br class="">- Section 4.5: s/parties that wants/parties that want/<br class="">- Section 4.6: Last example, there's a spurious comma after the last JSON <br class="">element<br class="">- Section 5: s/multi-teanant/multi-tenant/ in all URIs<br class="">- Section 5: s/requests to the federation API does/requests to the <br class="">federation API do/<br class="">- Section 5.1.2: the example is kind of useless. I am aware that it must <br class="">be a JOSE and all of that, but it's also truncated, so it can't even be <br class="">decoded. I'd rather have an already decoded positive response to show how <br class="">it should look like (plus a caveat that it will never look like that on <br class="">the wire)<br class="">- Section 5.2.1: the example uses the parameter "op" while the actual name <br class="">is "operation"<br class="">- Section 5.2.2: s/polices/policies/<br class="">- Section 5.3.1: the example uses the parameter "op" while the actual name <br class="">is "operation". Also, the example uses a parameter "type" which isn't <br class="">defined in the text above.<br class="">- Section 6: The sentence that ends with "...and a list of entity IDs of <br class="">trusted trust anchors together with the public version of their signing <br class="">keys". If I get this right the part "together with the public version of <br class="">their signing keys" is not needed, since federation makes heavy use of <br class="">discovery and, strictly speaking, that public key information will be <br class="">dynamically be read from the trust anchors' jwks_uri, right?<br class="">- Section 6.2: Also strictly speaking, the last sentence "no information <br class="">in the chain of statements should be used before the signature chain has <br class="">been validated" directly contradicts with the previous paragraph "an <br class="">implementer MAY therefor chose [sic] to not verify the signature until all <br class="">the other checks have been done".<br class="">- Section 7.2: For the first time appears the term "trust root", and it's <br class="">used a couple of times afterwards. If it's the same as "trust anchor", I'd <br class="">rather consistently stick to the latter.<br class="">- Section 8.1.1: s/authorization request example/authentication request <br class="">example/ for the sake of consistency<br class="">- Section 8.1.1, example: the parameter "state" is twice in the URI. And I <br class="">personally find the usage of "localhost" in the client_id kind of <br class="">distracting.<br class="">- Section 11.1: Replace RFC 5785 with 8615<br class=""></div></div></blockquote><div><br class=""></div>Good points ! I’ll take care of them.</div><div><br class=""></div><div>Thanks Marcos,</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Best regards,<br class="">Marcos<br class=""><br class="">-- <br class="">Dipl.-Ing. Marcos Sanz Grossón<br class="">Leiter Software Engineering<br class=""><br class="">DENIC eG, Kaiserstraße 75 – 77, 60329 Frankfurt am Main, GERMANY<br class=""><a href="mailto:sanz@denic.de" class="">E-Mail: sanz@denic.de</a>, Fon: +49 69 27235-0, Fax: -235<br class=""><a href="https://www.denic.de" class="">https://www.denic.de</a><br class=""><br class="">Angaben nach §25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)<br class="">Vorstand: Martin Küchenthal, Andreas Musielak, Sebastian Röthler, Dr. Jörg <br class="">Schweiger<br class="">Vorsitzender des Aufsichtsrats: Thomas Keller<br class="">Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht <br class="">Frankfurt am Main<br class="">_______________________________________________<br class="">Openid-specs-ab mailing list<br class="">Openid-specs-ab@lists.openid.net<br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></div></blockquote></div><br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">— Roland</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963) </div>
</div>
<br class=""></body></html>