Hi Soni, Thanks for the time and energy put into the BoF presentation. Thinking about the draft and presentation a bit more, I think it may be possible to tease apart the issues a bit.
Part of the discussion was about the historical use of "userinfo" and whether or not it was or should be deprecated. There are clearly differences of opinion there, and it would take time and care to come to a consensus around them. One way to do that would be to write an applicability statement. If you haven't seen one of those in the IETF context before, it's a particular kind of RFC which lays out when a particular protocol element or approach is beneficial and when it is problematic. RFC 6815 is one example; it clarifies that the methods in RFC 2544 are intended for test environments only and not for production environments. An applicability statement on "userinfo" would not deprecate it completely, simply update the community's understanding of its utility. That may well be worth doing, but it is distinct from the question of what should be done in the cases where the use of userinfo is problematic. The second part of the discussion was around the proposed scheme, "auth". While the draft describes this as a meta-scheme, it is syntactically a standard URI scheme in which the elements are composed of the scheme name, a method, and a set of query elements, at least one of which is itself a URI. From my perspective, there are a few issues which would need to be addressed: 1) The scheme name is very generic and it would likely be appropriate to update that to something more specific. 2) The document is not yet clear on the set of methods, in part because the BNF: auth-method-nm-char = ALPHA / DIGIT / "-" / "_" appears unbounded but the IANA considerations reference an assignment policy of IETF review. Is that for the methods, or was that referencing the URI scheme registry itself? 3) There is normative language specifying the behavior of operating systems: When one program attempts to open an auth URI, the operating system MUST NOT open another program to handle the auth URI. That's very difficult to enforce, and a different approach should likely be discussed. There is similar language throughout the draft discussing the syntax as a way to avoid link recognition systems. As part of a security considerations section, it would be good to work through what happens when those are updated with an understanding of this new scheme; there appears to be a strong risk that they would be updated to parse the embedded URI. Addressing these and requesting provisional registration would be fairly lightweight, but seeking a permanent registration would likely need some additional work and a demonstration that there are likely to be implementations of the scheme. In the web context, browser interest in particular would be a useful sign of future adoption. I look forward to additional discussion on the list, best regards, Ted Hardie On Tue, Jul 23, 2024 at 11:59 PM Soni "It/Its" L. <[email protected]> wrote: > hello, > > draft link: https://datatracker.ietf.org/doc/draft-soni-auth-uri/ > > we discussed this in the DISPATCH session, and the outcome was that we > should discuss it here. > > so, to re-state our goal, we want to get rid of userinfo altogether, not > just in http but in... just about everything really. but we know we > can't "just" do that, we have to acknowledge where it's still used, > provide alternatives, and all that stuff... (particularly databases and > ORMs, whose connect method often just takes a single string where you're > supposed to just embed authentication details...) > > and there were comments saying we can't get rid of it. we like to think > that's not entirely true, but it would take a lot of work, and some > churn, to get there. importantly, the inconsistencies we brought up > (or... we'd rather call them footguns especially for those working on > new URI schemes) don't just apply to individual apps but also to > interactions between apps (granted, our proposal is also pretty explicit > about getting in the way of interactions between apps, but at least you > can't attempt to repurpose our proposal because - unlike userinfo - one > of the things it does is decouple the concepts of authentication from > the target URI scheme). > > we do see that our proposal can't actually restrict userinfo in the > embedded URI, at least as per RFC 8820, section 2.2 > https://www.rfc-editor.org/rfc/rfc8820#name-uri-authorities (not to be > confused with section 2.1 (we feel sorry for the correspondent on the > ART list who kept telling us to look at section 2.1 in increasing > frustration...)), and... well, browsers are certainly not complying with > that because they absolutely do strip userinfo from arbitrary > (non-http(s)) URIs. but aside from that it just means we might have to > change either our proposal, BCP 190, or maybe RFC 3986? not entirely > sure about that last one. > > (also, we just realized, looking over RFC3986 again... it only > deprecates "user:password", despite the clear acknowledgement of > semantic attacks involving just the username portion (the provided > example doesn't use the "user:password" format). why is that?) > > thanks! (and apologies for the delay, anxiety is hard) > > (p.s.: so if we're understanding correctly WIT is for URIs as in the > generic syntax, and ART is for URI schemes? we would appreciate > clarification on this.) > > -- > plural system (tend to say 'we'), it/she/they, it instead of you > > -- > Witarea mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- Witarea mailing list -- [email protected] To unsubscribe send an email to [email protected]
