[44net] Re: Comments and questions welcome: Portal Features Requirements Document

Great work Chris & TAC! Glad to see this document delivered! I see many great points throughout the document and I am really happy they made it there. Just some comments and questions that may be helpful from me, in case you’re interested: 1. Why did you pick GPLv3 as the license? Is this an ARDC requirement or a decision independently made for the Portal? Is there any chance to reconsider and pick a license like MIT, BSD, or Apache 2? I feel like the restrictions that GPL (especially v3) imposes are unnecessary. 2. It would be nice to see an API specification published in a standardized format as well, e.g. OpenAPI, to try to get a gRPC-like automatic client library generation in many languages + automatic mocks / tests for when you are developing a client. That’s a nice-to-have but low effort and high gain. 3. Regarding the ticketing system, perhaps it’s worth to explore integrating with an existing one for some of the use cases to not reinvent the wheel? 4. I would like to see WebAuthn for Security Keys with support of multiple, e.g. 8-16 keys, and not single-key only like some services. The web also seems to be moving to a passwordless future, with support for Passkeys already landed in browsers and OSes in desktop + mobile. Integrating WebAuthn for 2FA and Passkeys for passwordless login is very similar. My colleague Adam has written a very good technical post on how to implement these standards securely in case you’re interested: https://www.imperialviolet.org/2022/09/22/passkeys.html <https://www.imperialviolet.org/2022/09/22/passkeys.html> . I would also try to avoid any insecure practices like security questions to recover an account. I don’t know if I would pick SMS 2FA for a new project, although it’s better than nothing. Just make sure you don’t fall back to SMS e.g. if Security Keys / TOTP doesn’t work. I think with e-mail 2FA support the SMS option isn’t needed. People without a smartphone would still need e-mail access to login, so I don’t think it is excluding people if you do not offer it. Just be careful with WebAuthn: it is domain dependent. The blog post I link to explains this well, and also what happens if the domain of the Portal changes. 5. I agree with the other e-mails about the maidenhead. I know it’s currently a part of the old Portal, but is it really required? I would make it optional personally unless there’s a specific use case. We should practice data minimization and only collect what’s really needed now, and not require fields “just in case they’re useful in the future”. That way you’ll have to convince users they get some value out of supplying you with this information ;) It also makes the Portal more generic: networks like guifi that are not related to amateur radio can also use the software since it’s generic enough. 6. Regarding the LoT, I’d be careful with the retention of the data, as it may not be needed forever, and only during the verification. If I provided some proof only for points, and this info isn’t used anywhere else, for any other reason, maybe there’s not a lot of need in keeping it. 7. I don’t know how deep “View history” goes, but I think audit logging of every (important) action is a good feature to have. If something happens, one can go back to the file and build a timeline of events that led to the situation at hand. This doesn’t have to include PII but enough information to assist in a case. 8. I would like to see the Portal (in the future) be used to generate all the whois responses. The whois server should just serve data from the database directly, as that should be the source of truth (with a cache in the middle of course). The model of RIRs with inet{6,}num objects and person objects, etc. is very helpful to create relations. 9. Can you not delegate $callsign.ampr.org to your own servers anymore? Or is this still done manually via a ticket? 10. Does DS / DNSKEY support mean we’re getting DNSSEC for ampr.org? :) Would be nice to see that, including for rDNS, and of course for delegated zones too! 11. What is the purpose of 3.2.6.4? 12. For 3.6.3.1 I would recommend OWASP’s ASVS ( https://owasp.org/www-project-application-security-verification-standard/ <https://owasp.org/www-project-application-security-verification-standard/> ) as a guideline, and I would aim for Level 2. It doesn’t have to be followed to the letter, but it gives a good idea of a lot of important things to pay attention to. The WSTG is of course also a good resource to use in parallel. 13. I would like to see IPv6 support explicitly mentioned as a requirement, both for the software, as well as the service. The functionality (assignments, allocations) depends on what the plans and needs of ARDC are, but being able to use the Portal fully in an IPv6-only network is something I believe should be there regardless. 14. If ARDC manages to get RPKI, I would like to see the automated provision of ROAs for all BGP networks, e.g. by using the RIPE API, or if it’s self-hosted (why?) an integration with Krill (probably). Obviously something for the future. 15. For 3.6.3.2 I believe it should be “only available”. After all, a lot of modern web features (e.g. WebAuthn) don’t work without it. That’s all, looking forward to the continuing of the development! Antonis