I do wonder though if you ought also say a bit about, or point at a reference describing, the possible bad outcomes if one of these URLs goes bad. The new text I think assumes that the developer will get how bad that can be, but I'm not sure if they would or not.
It can get as bad as the web, which is pretty bad, but I hope we don't have to point that out in great detail in every RFC that deals with the web. :) I think the drive-by-download malware example is a good one, and we could add another concrete one if you've got an idea, but I think the advice we have is sound and actionable and we should avoid having this spec be a catalogue of "bad things what can happen on the web". If there is such a reference, I'm happy to point to it!
-- Justin On 4/24/2015 7:52 AM, Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-dyn-reg-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) cleared (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there. We had some mail discussion on this but I'd like to continue that a bit more to understand if the changes in -28 address the issue. I'll send mail. (3) cleared ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My previous DISCUSS point (1) is below. That has been handled via new text in section 5 (on p27). I do wonder though if you ought also say a bit about, or point at a reference describing, the possible bad outcomes if one of these URLs goes bad. The new text I think assumes that the developer will get how bad that can be, but I'm not sure if they would or not. (1) General: there are many URIs sent to the AS from the client here. Nothing prevents the client messing about with the content served from those later, after registration. What mechanism holds clients accountable for such misbehaviours? (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5 does say that the AS "SHOULD check" but does not say what "checking" means, nor what to do if the check fails. I think a bit more security considerations-like text here, reflecting what is (or ought;-) actually be done would be good. Do you agree? --- OLD COMMENTS, I didn't check if they'd been handled - s2, software_version: what is the impact if the s/w is updated twice a day, every day? - 3.2.1 - why is the response status 201? That may be correct, but seems to subtle if so to only state in an exmaple. - s5, last para - "be very particular" is not good spec language - what do you actually mean that can be implemented? - thanks for section 6 - it's great to see thought being devoted to these issues. - Did the secdir review [1] get a response? And I think I quite agree with Charlie's point#2 about versions. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
