SER on Nostr: This is the idea behind NIP-39, isn't it? Except that 39 is unfortunately specific; ...
This is the idea behind NIP-39, isn't it? Except that 39 is unfortunately specific; naming service-specific schemes in a NIP is restrictive (how do I verify self-hosted gitlab? Sourcehut? Whatever replaces github?), and also oddly enshrines & sanctifies a small set of services. If NIP-39 were abstracted, and ideally store attestations in notes as you suggest, it would be less tightly coupled.
I was thinking about this issue from a different direction: an attestation mechanism for use in authorization -- kerberos-in-nostr. It'd be a combination of NIP-03, NIP-40, and possibly NIP-06. Keyoxide covers a lot of use cases, so there's overlap. Both assert an (ownership) relationship between two accounts, but one additionally has an attestation from one of the service owners.
I was thinking about this issue from a different direction: an attestation mechanism for use in authorization -- kerberos-in-nostr. It'd be a combination of NIP-03, NIP-40, and possibly NIP-06. Keyoxide covers a lot of use cases, so there's overlap. Both assert an (ownership) relationship between two accounts, but one additionally has an attestation from one of the service owners.