Original text:
provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. <del> A URI from which a list of authorizations submitted by this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del>  6.1.3. request is a stub registration object containing only the "contact" field. <del> The server MUST ignore any values provided in the "key", "authorizations", and "certificates" fields in registration bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. </del>  The server creates a registration object with the included contact information.  The "key" element of the registration is set to the If the client wishes to update this information in the future, it sends a POST request with updated information to the registration <del> URI.  The server MUST ignore any updates to the "key", "authorizations, or "certificates" fields, and MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the registration. </del>  For example, to update the contact information in the above registration, the client could send the following request:

Reviewer comments:
In the "applications" field of the registration resource is described in great detail. This is confusing for two reasons: both the text and the example registration object are still using the "authorization" term that applications replace. the text is written as if the applications should be directly embedded in the registration object returned. This PR addresses both issues by describing the "applications" field as an array of application URIs that the client can fetch. The example "registration" object is updated accordingly. The note indicating a server SHOULD include pending applications and SHOULD NOT include invalid applications remains as-is. The note indicating a server MAY return an incomplete list is removed - it is more complicated and with only URIs being returned, likely an unneeded optimization. Finally, in there are three fields that must be ignored by the server in a registration body: key, authorizations and certificates. This should be "key" and "applications" and is updated accordingly.
NAME feedback addressed, and conflicts w/ master resolved. Thanks for the :eyes: !

Revised text:
provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms.  <ins> A URI from which an array of URIs for application objects submitted by this account can be fetched via a GET request. 6.1.2.1. Each registration object includes an applications URI from which a list of applications created by the registration can be fetched via GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of URIs, each identifying an applications belonging to the registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid in the array of URIs.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </ins> 6.1.3. request is a stub registration object containing only the "contact" field.  <ins> The server MUST ignore any values provided in the "key", and "applications" fields in registration bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. </ins> The server creates a registration object with the included contact information.  The "key" element of the registration is set to the If the client wishes to update this information in the future, it sends a POST request with updated information to the registration  <ins> URI.  The server MUST ignore any updates to the "key", or "applications" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the registration. </ins> For example, to update the contact information in the above registration, the client could send the following request: