Update 52.md

52.md

@@ -9,9 +9,20 @@ Issued Claims
 
 This NIP is currently in draft, and review / comments are sought. May overlap with [NIP-32](https://github.com/nostr-protocol/nips/blob/39bfb2db32899dd2eb4a7c9a313f27103a18409b/32.md).
 
-This NIP defines new event kinds for the issuing of claims. 
+A claim is a statement of fact made by an issuer regarding a subject.
+Example claims include
+- Alice graduated from the Univeristy of Southern California
+- Bob, the control of pubkey 123EED..., also controls Twitter handle tinydancer
+- Charlie is over 21 years of age
 
-It reserves two event kinds (30001, 1001) for immediate use.
+Like Kind 0 metadata, issued claims provide additional data about pubkey, and by extension, the controller of the pukey.
+Unlike Kind 0 metadata, the data is sent by and vouched for by issuers, which is more trusthworthy than self-reported data, provided we trust the issuer. 
+
+The concept of an issuer comes from [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/).
+
+This NIP defines two new event kinds. 
+
+It reserves two event kinds (30001, 1001).
 
 - `30001 - issue claim`
 - `1001 - refresh claim request`
@@ -39,6 +50,27 @@ Sent by a user acting as an issuer, submitting a claim about another user, the c
 }
 ```
 
+For example. issuer nostr.directory with hexPubKey 2a1...234 is claiming that nostr user with hexPubKey 3bf...6w6 also controls twitter handle fiatjaf  
+```json
+{
+  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
+  "pubkey": "2a1...234",
+  "created_at": <unix timestamp in seconds>,
+  "kind": 30001,
+  "tags": [
+    ["p", "3bf...6w6", <recommended relay URL>],
+    ["d", "3bf...6w6:twitteraccount"],
+    ["claim_type", "twitteraccount"],
+    ["is_maintained", true]
+  ],
+  "content": {
+    "twitter_handle": "fiatjaf",
+    "profile_url": "https://twitter.com/fiatjaf"
+  },
+  "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+```
+
 `"d" tag` is required as the event is treated as a parameterized replaceable event [NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md). Issuers issuing more than one type of claim will need to append a claim type identifier to the subject's pubkey hex to prevent overwrites.
 
 The p tag MUST contain exactly one entry, the pubkey of the claim's subject.
@@ -50,21 +82,56 @@ Self-issued claims (issuer is the subject) is specifically allowed.
 
 A claim may change over time. This event allows a user to request the issuer submit an updated issue claim event for the same subject and claim_type.
 
+Refresh Claim Request
 ```json
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
   "pubkey": <32-bytes lowercase hex-encoded public key of the sender>,
-  "created_at": <unix timestamp in seconds>,
+  "created_at": 1674607473,
   "kind": 1001,
   "tags": [
-        ["e", <original issue claim event-id>, <relay-url>]
+        ["e", <kind>:<pubkey>:<d-tag>, <relay-url>]
+  ],
+  "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+```
+
+For example, if issued claim states a user is employed by Microsoft, but is 1 year out of date (1643099996 = Jan 25, 2022), an client may request issue update the issued claim to check if they still work there.
+
+Issued Claim Example
+```json
+{
+  "created_at": 1643099996,
+  "kind": 30001,
+  "tags": [
+    ["p", "37a...100", <recommended relay URL>],
+    ["d", "37a...100:employer"],
+    ["claim_type", "employer"],
+    ["is_maintained", true]
+  ],
+  "content": {
+    "organization_name": "microsoft",
+    "title": "Senior Software Developer"
+  },
+  "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+```
+
+Related Refresh Claim Request Example
+```json
+{
+  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
+  "pubkey": <32-bytes lowercase hex-encoded public key of the sender>,
+  "created_at": 1674607473,
+  "kind": 1001,
+  "tags": [
+        ["e", "30001:37a...100:employer", <relay-url>]
   ],
   "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
 }
 ```
 
 A client SHOULD check that the original event contains "is_maintained": true before sending event to relay
-
 A relay MAY choose to ignore this event if original event does not contain "is_maintained"
 
 Design Notes
@@ -72,7 +139,7 @@ Design Notes
 
 ### Why treat issue claim events as a parameterized replaceable event (NIP-33)?
 
-The intended use for claims is to enable clients to display the latest claim information for a user and for relays to take different actions on an incoming event based on claims.  Treating issue claim events as parameterized replaceable events allows any consumer to get the only latest issue claim event for a user by setting a subscription filter specifying the kind, issuer, the subject as the p tag, and a limit of 1.
+Treating issue claim events as parameterized replaceable events allows any consumer to get the only latest issue claim event for a user by setting a subscription filter specifying the kind, issuer, the subject as the p tag, and a limit of 1.
 
 ### Why is "is_maintained" necessary?
 
@@ -81,62 +148,7 @@ It's optional, and not technically necessary, but is a practical consideration.
 - If adhered to, prevents clients from sending refresh claim request events that are useless, reducing "garbage" events relays have to handle
 - Allows users acting as issuers to periodically send new issue claim events, updating claims for individual users "on demand" only when necessary
 
-### App-specific data tags instead of content?
-
-I considered allowing claim data to be stored in the event tags after reading this [discussion of another NIP](https://github.com/nostr-protocol/nostr/issues/20#issuecomment-913027389). 
-Simple data directly in event tags instead of content may be useful for owners of relays to communicate with each other about pubkeys acting badly (from purely a network point of view). Given throughput and stability is important for relays, reading single values from an event's tags seems faster and safer than parsing an object from content.
-Still unsure if this should be allowed.
 
 Motivation
 ----------
-As a protocol, Nostr is application agnostic, easy to implement, and censorship resistant. While current apps built on Nostr focus on messaging (Twitter, Telegram, etc.) I envision Nostr being the underlying protocol of other social media apps as well (Instagram, LinkedIn, Tinder, etc.). 
-
-Apps that create new relationships between strangers need more user profile information that Nostr currently supports, but how do we do that while still being application agnostic, easy to implement, and censorship resistant?
-
-This NIP attempts to accomplish this by:
-- re-using existing structures from standard Nostr events as much possible
-- allowing any user to act as a issuer, submitting claims about another user without any type of approval
-- separating the protocol for communicating claims from the definition of claim data
-- having all claim data public, allowing for full transparency
-
-As a first attempt, there are many unresolved concerns like how to establish trust for an issuer [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md)?, how to handle profile information that shouldn't be public, and how to define standard profile fields so clients can design attractive profile screens. However, I believe that this NIP has JUST ENOUGH to be useful.
-
-Potential Use Cases
--------------------
-
-### Profile Metadata
-
-A common use case today is linking a Nostr pubkey with other social accounts (e.g. [nostr.directory](https://github.com/pseudozach/nostr.directory)). Apps can act as issuers, sending an Issue Claim event with other account specific claim data (Twitter handle, number of followers, proof link to Twitter message with Nostr pubkey, etc). Clients subscribed to Issue Claim events can then display other social account links provided by multiple issuers in a user's profile page. Ideally, issuers would use the same claim_type when the properties are the same, so client code doesn't have to be re-written.
-
-### Community Pins / Badges
-
-Because any user can act as an issuer, this NIP makes it easy for a community manager to reward their members with pins / badges. For example, the owner of the Damus client could issue a claim with a badge to their users who have made a donation.
-
-### Pukey Behavior
-
-While claims can be associated with the owner of the pubkey, claims can be made against the pubkey itself based on its usage. The first use case that comes to mind is the owner of a relay communicating that a pubkey is acting badly, allowing other relay others to take appropriate actions on that pubkey's events. 
-
-About Privacy
--------------
-
-While additional profile information is needed for apps that create new relationships between strangers, as soon as we start associating information with a person via their pubkey, there are privacy concerns. 
-
-- What happens when an issuer makes a claim about me that is untrue?
-- What happens when an issuer makes a claim about me that is true, but I don't want public?
-- Can the correlation of claims about me reveal my identity?
-
-### Untrue Claims
-
-This NIP uses the term "claim" instead of "credential" or "attribute" to emphasize that the issuer is making a claim, which can be true or untrue. In an censorship resistant application, any person can make any claim about someone else, without their permission, regardless of if it is as a regular Nostr message or as an issue claim event. The issue for this NIP is, does the channel incorrectly convey legitimacy to the claims, or does the display of an issued claim on a client's profile page convey more legitimacy than a message? It probably does.
-
-An immediate solution is to blacklist that issuer's pubkey, a configuration setting that already exists in some Notr relays. An alternate solution is for the wronged users to send their own Issue Claim event against the pukey of the issuer, and use heuristics to automatically blacklist or hide events from bad issuers.
-
-### True Claims that Shouldn't be Public
-
-If an issuer is acting in good faith, once informed, the issue claim event can be deleted [NIP-09](https://github.com/nostr-protocol/nips/blob/master/09.md). However, the same issue exists as Tweets that are taken down, there is no guarantee that it hasn't already been copied, or in Nostr's case, that a relay will respect the deletion event. A client may have to verify the relay properly supports event deletion before sending an issue claim event to that relay.
-
-### Correlation of Identity
-Doxing is an issue. If claims against my pubkey include membership in "Women in Tech", "Atlanta Falcons Fan", and "Autism Support Network", something searching for my real identity knows to look to a woman in Atlanta, likely working for one of the thirteen big tech firms in Atlanta, likely in a photo with wearing Falcons merch, and has an autistic child. That's dangerous.
-
-It takes user education, but one nice thing about Nostr though, it's trivial for a person to create multiple pubkeys, and no single login / wallet. Claims about the same person, but spread across multiple unrelated pubkeys greatly reduces the risk of doxing.
-
+As a protocol, Nostr is application agnostic, easy to implement, and censorship resistant. While current apps built on Nostr focus on messaging (Twitter, Telegram, etc.) Nostr can be the underlying protocol of other social media apps as well (Instagram, LinkedIn, Tinder, etc.). These apps require more profile information than Nostr current supports. Rather than each app implementing its own profile, it would be nice if we can leverage Nostr for decentralized identity.