Issue 163 - add field to configuration data indicating expected subject behavior for new streams (#168)

* Issue 163 - add field to configuration data indicating expected subject behavior for new streams

* Add default_subjects to example

* Fix language based on PR feedback

* Clarify language

* Fix spacing

Author: FragLegs

openid-sharedsignals-framework-1_0.md

@@ -587,6 +587,19 @@ authorization_schemes
   security considerations, make the authorization_schemes attribute
   publicly accessible without prior authentication.
 
+default_subjects
+
+> OPTIONAL. A string indicating the default behavior of newly created streams. If present,
+  the value MUST be either "ALL" or "NONE". If not provided, the Transmitter behavior in
+  this regard is unspecified.
+>  - "ALL" indicates that any subjects that are appropriate for the stream are added to
+    the stream by default. The Receiver MAY remove subjects from the stream via the
+    `remove_subject_endpoint`, causing events for those subjects to _not_ be transmitted.
+    The Receiver MAY re-add any subjects removed this way via the `add_subject_endpoint`.
+>  - "NONE" indicates that no subjects are added by default. The Receiver MAY add subjects
+    to the stream via the `add_subject_endpoint`, causing only events for those subjects
+    to be transmitted. The Receiver MAY remove subjects added this way via the
+    `remove_subject_endpoint`.
 
 TODO: consider adding a IANA Registry for metadata, similar to Section 7.1.1 of
 {{RFC8414}}. This would allow other specs to add to the metadata.
@@ -719,7 +732,8 @@ Content-Type: application/json
       {
         "spec_urn": "urn:ietf:rfc:8705"
       }
-    ]
+    ],
+  "default_subjects": "NONE"
 }
 ~~~
 {: #figdiscoveryresponse title="Example: Transmitter Configuration Response"}
@@ -2158,7 +2172,7 @@ multiple Receivers would lead to unintended data disclosure.
 {: title="Example: SET with array 'aud' claim" #figarrayaud}
 
 ### The "txn" claim {#txn-claim}
-Transmitters SHOULD set the "txn" claim value in Security Event Tokens (SETs). If the value is present, it MUST be unique to the underlying event that caused the Transmitter to generate the Security Event Token (SET). The Transmitter, however, may use the same value in the "txn" claim across different Security Events Tokens (SETs), such as session revoked and credential change, to indicate that the SETs originated from the same underlying cause or reason. 
+Transmitters SHOULD set the "txn" claim value in Security Event Tokens (SETs). If the value is present, it MUST be unique to the underlying event that caused the Transmitter to generate the Security Event Token (SET). The Transmitter, however, may use the same value in the "txn" claim across different Security Events Tokens (SETs), such as session revoked and credential change, to indicate that the SETs originated from the same underlying cause or reason.
 
 ### The "events" claim {#events-claim}
 The "events" claim SHOULD contain only one event. Multiple event type URIs are