two rounds of client
	authentication are required, and setting this flag allows the credential
	helper to implement the multistage authentication step.  This flag should
	only be sent if a further stage is required; that is, if another round of
	authentication is expected.
+
This value should not be sent unless the appropriate capability (see below) is
provided on input.  This attribute is 'one-way' from a credential helper to
pass information to Git (or other programs invoking `git credential`).

`wwwauth[]`::

	When an HTTP response is received by Git that includes one or more
	'WWW-Authenticate' authentication headers, these will be passed by Git
	to credential helpers.
+
Each 'WWW-Authenticate' header value is passed as a multi-valued
attribute 'wwwauth[]', where the order of the attributes is the same as
they appear in the HTTP response. This attribute is 'one-way' from Git
to pass additional information to credential helpers.

`capability[]`::
	This signals that Git, or the helper, as appropriate, supports the capability
	in question.  This can be used to provide better, more specific data as part
	of the protocol.  A `capability[]` directive must precede any value depending
	on it and these directives _should_ be the first item announced in the
	protocol.
+
There are two currently supported capabilities.  The first is `authtype`, which
indicates that the `authtype`, `credential`, and `ephemeral` values are
understood.  The second is `state`, which indicates that the `state[]` and
`continue` values are understood.
+
It is not obligatory to use the additional features just because the capability
is supported, but they should not be provided without the capability.

Unrecognised attributes and capabilities are silently discarded.

[[CAPA-IOFMT]]
CAPABILITY INPUT/OUTPUT FORMAT
------------------------------

For `git credential capability`, the format is slightly different. First, a
`version 0` announcement is made to indicate the current version of the
protocol, and then each capability is announced with a line like `capability
authtype`. Credential helpers may also implement this format, again with the
`capability` argument. Additional lines may be added in the future; callers
should ignore lines which they don't understand.

Because this is a new part of the credential helper protocol, older versions of
Git, as well as some credential helpers, may not support it.  If a non-zero
exit status is received, or if the first line doesn't start with the word
`version` and a space, callers should assume that no capabilities are supported.

The intention of this format is to differentiate it from the credential output
in an unambiguous way.  It is possible to use very simple credential helpers
(e.g., inline shell scripts) which always produce identical output.  Using a
distinct format allows users to continue to use this syntax without having to
worry about correctly implementing capability advertisements or accidentally
confusing callers querying for capabilities.

GIT
---
Part of the linkgit:git[1] suite