Add access control mechanisms

This commit is contained in:
Abhay Raizada 2024-05-13 10:44:39 +05:30
parent 9dda0ad291
commit ddee4e8167

42
101.md
View File

@ -19,7 +19,7 @@ Event `30168` describes a form with `field` tags that contain the description of
["field", "<fieldId>","<input-type>","<label for the field>","<Options (for option type)>", "<stringified JSON settings>"],
["field", "<fieldId>", "option", "label for options field",
JSON.stringify([["<optionId1>", "option label", "<optionId2>", "option label"]]),
"<stringified JSON settings>"})
"<stringified JSON settings>"
]
],
"pubkey": "<Author of the form>"
@ -36,10 +36,6 @@ The different tags used to describe the form are described as:
|field| Contains the following values<table><tr><th>index</th><th>name</th><th>description</th></tr><tbody><tr><td>1</td><td>FieldId</td><td>an id that uniqely identifies a field in the forn</td></tr><tr><td>2</td><td>input-type</td><td>A field that describes the type of value that can be expected as a response to this field, values can be: `text`, `option` or `label`</td></tr><tr><td>3</td><td>label</td><td>A label for the field</td></tr><tr><td>4</td><td>options</td> <td>Only used for input-type option, is a Json stringified array of strings containing [`<OptionId`>, <`label`>, `<optional config>`] </td> </tr><tr><td>5</td><td>fieldSettings</td><td>An optional JSON stringified object that contains settings specific to the field, for example `renderElement`, a setting which indicates what UI element to render to the client </td></tr>
</tbody></table>
## Sharing and Private forms.
`<TBD>` similar to the sharing of spreadsheets as described in the proposed [NIP](https://github.com/nostr-protocol/nips/pull/1189).
## Responses - Public
@ -69,7 +65,39 @@ for option fields, the response is the id of the option selected. In case of mul
}
```
## Responses - Private
## Access Control
In general access is granted by signing the event and encrypting the content with different keys.
the mechanism to share the keys is by encrypting the keys and adding it to the p-tag of the event.
The p-tag for `kind:30168` events, should look like.
`["p","<pubkey for the user>", "<optional relays>", "<Encrypted-View-Key>", "<Encrypted-Signing-key>"]`
`View-key` : generated during form-creation, this key should used to encrypt/decrypt the `".content"` string in the form template.
`Edit-key/Signing-Key`: Is the key which is used to sign the 30168 event.
Encryption should be via [nip-44](./44.md) using the conversation key derived from the p-tags pubkey and the signing-key.
### Public Forms Public Responses
Both the form and the responses are kept in that `tags` array and signed by the respective users. Useful for cases like polls.
### Encrypted Responses.
Response tags are added to the `.content` field of the event and encrypted as per the spec in [nip-44](./44.md) by the responders private key and the form authors public key.
### Private Forms only viewable by a group.
Form fields should be placed in the `.content` key, nip-44 encrypted by the view-key, and the form-authors public-key. The selected responders can decrypt the form using the view key. The `tags` array is used to keep track of the allowed-responders identities.
### Public forms editable by a group.
A signing key is generate for the group.
Form fields are in the tag array, and the signing-key is encrypted in the p-tag like:
`["p", "<pub-key with edit access>", "<relays>","","<encrypted signing key>"]`.
The key should be the same that the `30168` event is signed with.
The pubkeys with edit access, will also be able to view the form responses.
### Private forms editable by a group.
Form fields should be placed in the `.content` key, encrypted by a `view-key`, which is shared in the 3rd index of the p-tag for the viewers.
The signing key is encrypted and placed in the 4th index of the p-tag for the editors.
response tags are added to the ".content" field and encrypted as per the spec in [nip-44](./44.md)