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 . 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?
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
The Level of Trust is a means to ensure that the person is a genuine, licensed radio amateur. It starts when you first register by verifying your email address, which earns you the lowest level. You then have various easy options, like adding a mobile/cellphone and verifying that to earn a few additional points, you can also verify your postal address (Google style postcard with PIN).
The next stage would be to get your licence and ID verified, this would typically be done by either a physical meeting, if someone is close enough, or (more likely) via a video meeting. The idea is that the more verification processes you go through, the higher your level of trust. So when you apply for resources all the verification is already in place. This is especially important for BGP requests as it currently takes some time to go through that process.
The ultimate goal would be to become a verifier yourself and help verify others - It’s the same model as the CA-Cert Web Of Trust.
73,
Chris - G1FEF
Thanks for sharing this work with the community.
Reading through it, some thoughts and questions come up:
- I'm delighted to see that accessibility and WCAG is considered.
- What is the intent of the Level Of Trust value? Is this about allowing some centralized administrative actions, or does this represent something that community members can earn and level up?
- In addition to GDPR compliance considerations, you might also consider California's similar CCPA.
- What is the intention of requiring maidenhead locators? I'm mostly just curious how the information gets used, though I suspect it would be useful to map country-granularity call signs to actual geographic areas where the subnets are assigned.
In general, this seems like a really straightforward list of requirements that all make sense in context.
Looking forward to experimenting and trying out something new.
Cheers and 73,
jof / K6BGP
Hello 44Net!
For quite some time, y'all have heard rumblings of a new portal, which
Chris has been working on bit by bit. Realizing that it's likely a
larger project than we initially thought, earlier this year the TAC took
on the task of writing a feature requirements document. This has been
the bulk of their work this year so far, and I'm really proud of the
results, which were completed just a couple weeks ago.
I'm writing on behalf of the TAC to share this document with you and to
request comments and comments:
https://www.ampr.org/wp-content/uploads/2022-09-Portal-Features-Requirements-Doc.pdf
Ideally, please share your thoughts in this channel rather than emailing
directly, though of course we will read any feedback you send. Pierre,
the TAC Chair, will be watching the list and answering any questions
that may come up.
Note that this document is a feature requirements document - which
outlines the features that the portal needs to have before it's
considered "done." By definition, it's *not* an engineering document;
we've purposefully not specified the exact technology we'll use to build
this out. We have, however, specified that it will be released as an
open source project as soon as we have a functional version, likely
without all features present. Ultimately this will be a project managed
by our new Director of Technology (who starts on Monday; will introduce
after he starts) and the team he assembles to carry out the build. Thus,
information like timelines, project plans, and database specifications,
etc., will follow his review of this document and any comments from this
group.
And with that, I say - happy reading! And thank you so much for your
thoughts and questions.
Looking forward,
Rosy
--
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
_______________________________________________
44net mailing list -- 44net@mailman.ampr.org
To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________
44net mailing list --
44net@mailman.ampr.orgTo unsubscribe send an email to
44net-leave@mailman.ampr.org
_______________________________________________
44net mailing list --
44net@mailman.ampr.orgTo unsubscribe send an email to
44net-leave@mailman.ampr.org