Add a ability to differentiate security contacts between parts of an application / scope of security.txt

[spidererrol]

Is your feature request related to a problem? Please describe.
An application, particularly a web application, may be made of multiple components supported by different entities. For example the main application might be a PHP application but runs on a web server run by a hosting company and maybe even has a cloud-based database run by yet someone else.

Describe the solution you'd like
I would propose an optional, repeatable "SeeAlso" field (not a great name, but the best I could come up with), with 2 values per entry: "scope" and a URI. This should not alter the requirements of the rest of the file which should act as "default" information for if the researcher cannot identify an individual component at fault. The scope should not be strictly controlled but there should be some well-known values (such as "Web Server", "Database", and "Application"). The SeeAlso should not imply any restriction on the Expiry of the current or target security.txt files (as they may be maintained by different authorities).
Eg:
SeeAlso: "Web Server" https://www.hostingexample.com/.well-known/security.txt
SeeAlso: "Application" https://www.webdevexample.com/.well-known/security.txt

Describe alternatives you've considered
I can see 3 alternatives:

1. Make no changes, there will be only one point of contact (or at least no method to distinguish contacts). The down side of this is that it may take longer to deal with problems as they have to be shuffled around the the correct place and there is always a risk of "oh X will be dealing with it" if there are multiple persons receiving the notice.
2. Use extra unspecified fields or additional markup(comments) in the file to indicate purpose of contacts. This will lead to files diverging from the specification and varying instance-to-instance and automated tools possibly not seeing the additional information.
3. Add some optional markup to Contact to distinguish scopes. Given that Contact already allows multiple entries this will further increase the number of contact entries and make reading the list harder and make it more likely that a creator of the security.txt forgets to add "default" contact information or a researcher will accidentality send to the wrong contact (think sending to a hosting provider when it is the php application at fault - at best it will delay resolution and it could even just get discarded).

Counter argument
The downside of this is that it makes identifying the appropriate contact more difficult for the researcher. I personally thing that this is sufficiently mitigated by not removing the requirements for Contact fields in files that use SeeAlso so if a researcher is unsure (or has insufficient time, etc) they can use that information and just ignore the SeeAlso entries.

Additional context
N/A

[nightwatchcyber]

I think a lot of this can be taken care of via other means - via the "Poilicy" directive or multiple security files. Because this is a request for a new field, we can look at this once the core standard is approved and this field can added via an IANA registry.