Yeah, great idea! When you say selective disclosure, do you mean selectively disclosing the badge to a specific party?
Verifiable parts of the badge to specific parties. We can't do this on the current version of Nostr, but BBS+ signatures allow you to remove data from a signed payload and adjust the signature before sending that information forward. You could change the event to show only the bits you want to show while keeping completely verifiable with the original signer's keys.
Nice. As for publicly available verifiable information, I’ve been thinking that the kind 0 event could contain any verifiable information that needs to be public. Right now it is being used for a nostr profile but it can be easily extend to include additional metadata. Similar in nature to the DNS SOA (start of authority) record.
Kind 0 is hard, because its a replaceable event. Every single client has to implement Kind 0 correctly, otherwise data is lost when a client publishes the event with only the data it cares about. I think badges are better, and the data is seperated into different events signed by the issuer who is "attesting" the information is true.
AKAProfiles extends NIP58 events to support adding data to badge awards. (see https://www.akaprofiles.com/docs/reference/nostr-events) To support private data, I would add "private" as an option on the "field" tag added to the Badge Definition Event. On the badge award event, for private fields, instead of returning the private value using the "data" tag, I'd return a URL/URI which can fetch the data, being agnostic in how URL authorization is performed. I believe that any data a user isn't comfortable with being widely published should never be published to relays, unless decryption requires their own private key, as the risk of accidental disclosure due to a key comprise is too high.