well-known-uri-ref-engine-discovery: Drop 'auth*' params from the Docker example

[wking]

Docker registries should include both of these in their WWW-Authenticate response, and Docker's registry does:

$ curl -I -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull"
Date: Fri, 26 Jan 2018 04:58:02 GMT
Content-Length: 157
Strict-Transport-Security: max-age=31536000

The WWW-Authenticate header is specified in RFC 7235, and the Bearer token is specified in RFC 6750. RFC 7235 defines realm and allows for per-scheme extensions:

The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme.

But RFC 6750 has nothing to say about its semantics, so interpreting it as the auth-server URI seems to be a Dockerism. Similarly, the service parameter seems to be a Dockerism, with no mentions of service in RFC 6750. scope is covered in RFC 6750, which delegates the definition to RFC 6749.

RFC 6749 covers supplying the scope to the auth-server as a query parameter. It also covers client_id, which Docker also mentions. RFC 6749 requires auth-requests to include response_type=code, which Docker does not mention; but Docker accepts the RFC value:

$ curl -s 'https://auth.docker.io/token?response_type=code&client_id=testing&service=registry.docker.io&scope=repository:library/docker:pull' | jq -S .
{
  "access_token": "…",
  "expires_in": 300,
  "issued_at": "2018-01-26T05:35:56.860615325Z",
  "token": "…"
}

Docker does not seem to implement RFC 6749's recommended state parameter.

With both “use realm as the auth server” and “pass through service as an auth query parameter” as Dockerisms, the RFCs are not sufficient in themselves to specify Docker's current auth protocol. These are not vanilla bearer tokens. But the information we previously supplied via authUri and authService is in the intial resource response, so we can stop supplying those ourselves.