re: Link vs the actual thing (@id)
i am not sure Link objects is the way to go. it makes more sense to me to just use the actual @id because then you can make descriptive statements about that thing out-of-band and load them into your processor.
re: registries
if you are establishing a registry then it would be useful to have precise definitions for precise identifiers. it is unclear what exactly https://datatracker.ietf.org/doc/html/rfc9421 entails, and https://datatracker.ietf.org/doc/html/rfc9421#name-eddsa-using-curve-edwards25 hints toward “eddsa using curve edwards25519”, but that is a similarly incomplete definition – it tells you how to sign some input, but not what that input should be. you would want to know the full parameters that might make up a full auth-scheme that can be signaled with the HTTP WWW-Authenticate header in cases of authentication, or included in HTTP Accept-Signature in case of inbox OPTIONS or on a failed POST.
implications for FEP process?
tangentially to this: should the FEP process have any affordances for registries? it could complicate things like “what FINAL status means” and “how to count implementers”, so it’s worth considering. i think individual FEPs can declare their own “capability identifiers” as well, since individual FEPs have the ability to contain subresources (like term definitions and so on) and act as their own namespaces.
canonical or equivalent identifiers
also tangentially, the datatracker.ietf.org URIs used are not canonical for the actual RFCs. there are several equivalent identifiers that could refer to the same thing (owl:sameAs):
doi:10.17487/RFC9421(the DOI)https://doi.org/10.17487/RFC9421(the DOI resolver)https://dx.doi.org/10.17487/rfc9421(another DOI resolver)
https://www.rfc-editor.org/info/rfc9421(what the actual DOI resolves to)urn:ietf:rfc:9421(the URN for the IETF RFC)urn:issn:2070-1721(the URN for the ISSN)https://www.ietf.org/rfc/rfc9421(an alternate resource)https://www.ietf.org/rfc/rfc9421.html(in text/html)https://www.ietf.org/rfc/rfc9421.xml(in text/xml)https://www.ietf.org/rfc/rfc9421.txt(in text/plain)
it may be wise to use a canonical identifier and also have it actually be an identifier so that equivalences can be defined and recognized wherever they might be used. see Service Discovery Identities and Service Discovery Features for prior art.
RFC 9421 actually defines an IANA registry for this in Section 6.2: HTTP Message Signature – maybe use this to form a canonical identifier? something like #alg/ed25519 or #alg:ed25519 could work, maybe even just #ed25519 if you expect there to never be a conflict between algorithm names and parameter names. you could also define something specific in a FEP, though.