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.

Could we consider other well established forms of trust does as something signed via a valid LOTW certificate, maybe an pre-existing Echolink validation, etc?

--David KI6ZHD

All,

* Is this the same as the 44NGN (no emails either) - was the TAC mailing list closed too? * Does this require those who have verified, use LOTW to connect to AMPR, provided to get a Wiki account, etc. previously - to "verify again"? * Is this live now? * Will I loose my allocation? * Will I loose DNS entries/hosts/services that do not match the new nomenclature?

I volunteered for TAC - was I removed at at some point/some reason?Did the collaboration on TAC via mailing list stop/change?

73,

- Lynwood KB3VWG

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

On 28 Sep 2022, at 08:53, Chris Smith via 44net 44net@mailman.ampr.org wrote:

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

...

On 28 Sep 2022, at 06:13, Jonathan Lassoff via 44net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org> wrote:

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

On Tue, 27 Sept 2022 at 14:37, Rosy Schechter - KJ7RYV via 44net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org> wrote: 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... 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 http://ampr.org/ _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org

---

44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org

Hey Rosy, please find my answers below:

On 29 Sep 2022, at 16:38, Rosy Schechter - KJ7RYV via 44net 44net@mailman.ampr.org wrote:

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.

We're open to different open source licenses. Why would you choose MIT, BSD, or Apache 2 over GPL?

GPL is applying restrictions on the code that prevent certain use. The other licenses listed above actually allow for free use and distribution of the code. They do not pose any significant limitations. With a GPL license, if you’re interested in contributing to the code or making a fork of the software, you can either do it privately, or you’re forced to publish it under the same license. This can lead people into keeping their forks private. Moreover, if a project uses code from a GPL project, even in part, it needs to be released under the GPL as well (unless it includes the code in the form of a library), which can limit reusability of the code by others. (I have seen and heard many stories on that, and it’s not clear to which degree this is true, e.g. if linking the code is okay or not, but it can expose you to risk).

Moreover, for a lot of professionals, especially outside the US, it can be difficult or may require explicit approval from their employer to contribute to such software, or it may not be allowed outside the scope of their work, due to intellectual property rights. Some companies for example allow you to contribute to any OSS under a certain license list, and almost always the three ones above are included, and almost always GPL is explicitly not included.

There’s a large debate about enforceability, and some of these areas are not well understood or defined, and that’s why typically companies that care about the legal risk tend to just avoid any exposure.

A lot of modern programming languages such as Rust and Go try to have a culture of Apache 2 which is the recommended license (and has a very helpful patent provision) and most of the libraries choose a license in the list above (called permissive). This helps ensure GPL-free software which they probably consider an important point.

Here’s an interesting article I just found: https://medium.com/@henvic/opensource-and-go-what-license-f6b36c201854 https://medium.com/@henvic/opensource-and-go-what-license-f6b36c201854 — 87% of Go code on GitHub is licensed under permissive licenses. Around 75% of any software is licensed under permissive licenses. It also covers a lot of important points on why you can choose one vs the other. However, a modern typical practice seems to be a dual Apache 2 + MIT option, but it may be too much for the Portal. Any one of the two is fine. I think there’s some bias in the article, so keep that in mind while reading.. ;)

Of course, it should be mentioned that there are very large and successful projects that are using GPL, but some are too big to be ignored, and this may be the reason. The most popular is Linux, that is licensed with GPL, but even that does not use GPLv3, but GPLv2, as Linus Torvalds expressed a dislike towards the changes introduced in the 3rd version.

My main point, and why I always prefer permissive licenses, is that you remove the potential for legal risk / gray zones, and you release software that is truly free, without imposing restrictions to anyone. This, however, may not be something everyone wants, but I don’t see a reason why we should not do that.

Finally, as something unrelated to the Portal code, but a practice I see more and more lately: software companies release the “Community Edition” under GPL, and the “Enterprise Edition” as a paid license. That way they use the GPL to prevent their competitors from forking the code, or doing any development, and they maintain the sole right to sell this code (that people outside the company may contribute). There’s also a recent trend it seems for a certain Cloud provider to find OSS with permissive licenses, and offer it "as a Service”, directly competing with the company or team behind it, that also attempts to do the same thing. These companies have been forced to restrict their code to remain financially viable, but still chose to stay away from the GPL.

...

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.

Thanks, this is noted. Ideally we provide multiple options for 2FA.

That’s a good and inclusive choice and I support it. I would just want you to avoid the legacy of SMS 2FA in a brand new system :)

...

9. Can you not delegate $callsign.ampr.org http://callsign.ampr.org to your own servers anymore? Or is this still done manually via a ticket?

The items described in the feature requirements doc are not live, so please continue to use existing processes until we make the transition to the new Portal. Ideally this process of transitioning to the new portal, led by our forthcoming Technical Director, will not be abrupt and have sufficient warning for changes. I do not see any major release for the new portal happening until 2023 (ideally early 2023, but no promises + more scoping needed.)

Yes, of course, by “anymore” I was referring to the new system, but it was not clear enough. I was informed that this isn’t possible today anyways, so I apologize for the mistake. It seems that nothing is changing with the new requirements.

...

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.

This may be a whole second project, combined with a longer discussion around whether ARDC should actually manage an IPV6 block. We see cases for and against it, but ultimately, we need to make sure that our existing address space is better managed and utilized before taking on more. That said - your comments are noted.

I agree, and that’s why I’d like to focus on ensuring the portal is accessible over IPv6 at least, regardless of whether or not this project will happen, and whether ARDC will ever have to manage IPv6 addresses. It’s always good to be able to use the current IP version to manage the legacy one ;)

Antonis

Hi Joel,

Thank you so much for your comments. As with those from Antonis, I'll let the TAC / Chris speak to many of them, but my thoughts on some of the items are below.

Thanks for sending this, I'm looking forward to trying the new portal and seeing its improvements.

Glad to do it! And me too.

1. 3.2.1.9: 2FA - can I please request FIDO U2F support?

This is noted. As as mentioned on my last email, ideally multiple forms of 2FA will be available.

6. I wondered if prescribing that all work will be in alignment with

open source best practices --- without defining these --- might provide a point of contention later, if a user doesn't like the way something is being done, and given the proposed public nature of the codebase. Given too that best practices tend to be dynamic and that it may require some additional work to bring the codebase into line with this requirement whenever a change is made, it might be worthwhile to soften this expectation slightly without undermining its intent.

I hear what you are saying here. Ultimately the notion of doing this work in the public causing contention due to disagreement about how things are done, is the main reason why some members of our team (including me at times) have been hesitant to do work in the public in general. The truth is, though, that has to change – we value open source, and we hear the call from 44Net members for increased transparency into what we're doing. Making sure that this codebase is public is part of meeting those needs. I agree that it will likely come with some contention, and we must both expect it and take steps to work through it and keep our work productive.

My hope is that we'll have solid guidelines for engagement around our open code bases designed to minimize contention. As stated in the Rust code of conduct:

"Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer."

https://www.rust-lang.org/policies/code-of-conduct

We'll definitely need to employ this kind of philosophy in whatever work we are doing in the public. And like you say, it may be worth softening our expectation in order to be as productive as possible.

7. Point 2.1.2.1 may have been intended to enumerate accessibility

standards (there is a hanging colon).

There's just a hanging colon :) Thanks for pointing that out.

I may have missed or misunderstood some sections of the document, in which case I beg your pardon if my suggestions are addressed elsewhere in the document or otherwise moot.

I don't see any misunderstandings :)

The requirements document reads very well and it is clear much thought and work has gone into its production. My thanks to the team behind it who are obviously striving to make the Portal an improved experience for all.

Thanks to you for sharing your thoughts here!

All the best, Rosy