clarified current server behaviour

[aricart]

No description provided.

[bruth]

Attempted to simplify, hopefully I interpreted this correctly.

Suggested change

	it will utilize the connected account. The request will be a signed
	`AuthorizationRequest` JWT signed by the server's nkey and can be encrypted if
	configured.
	it will utilize the connected account. The `AuthorizationRequest`, representing a JWT,
	will be signed by the server's configured public nkey and optionally encrypted by a
	configured xkey.

[bruth]

Again, hopefully interpreting correctly...

Suggested change

	The response to the request is a `AuthorizationResponse` JWT. If the callout is
	set to encrypt, the response will be encrypted for the server's nkey. The
	decoded JWT will be issued by auth account nkey as configured in the server. In
	operator mode, it is possibly for the `AuthorizationResponse` to be issued by an
	a signing key for the auth account.
	The expected response to the request is an `AuthorizationResponse` JWT. If encryption
	is configured, the response must be encrypted by the server's configured xkey. The
	embedded JWT is expected to be issued by the nkey configured on the server.
	In operator mode, an alternate issuer to the JWT within `AuthorizationResponse` can
	be a signing key of the configured nkey.

[bruth]

Suggested change

	auth callout can return an error. Or a `jwt` field. In configuration mode, the
	auth callout can return an error or a `jwt` field. In configuration mode, the

[bruth]

Suggested change

	user will be issued by the configured auth account key, and the placement for
	user will be issued by the configured auth account key, and the placement of

[bruth]

My mental model of this is not fully formed and I think there is still some more room to clarify, but I am going to review the auth callout tests and then offer some more feedback.

[ripienaar]

@aricart do you plan to finish this one? Else we close it