[Openid-specs-ab] Issue #1513: [Federation] request authentication at other endpoints (openid/connect)

[Takahiko Kawasaki]

New issue 1513: [Federation] request authentication at other endpoints
https://bitbucket.org/openid/connect/issues/1513/federation-request-authentication-at-other

Takahiko Kawasaki:

Request authentication can be performed by means of the following, too.

**CIBA** \([Client-Initiated Backchannel Authentication](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html)\)

* Client authentication methods at the backchannel authentication endpoint; The backchannel authentication endpoint always requires client authentication. \(In other words, “public” clients cannot use CIBA.\)
* Request object passed to the backchannel authentication endpoint \([CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) [Section 7.1.1](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1.1)\); Use of request object is optional, but [the FAPI-CIBA profile](https://openid.net/specs/openid-financial-api-ciba.html) requires it.

**Device Flow** \([RFC 8628](https://www.rfc-editor.org/rfc/rfc8628.html)\)

* Client authentication methods at the device authorization endpoint; Client authentication is required only when the client type is “confidential”.

The explanation and example about `request_authentication_methods_supported` in [Section 4.2 OP Metadata](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.4.2) of [OpenID Connect Federation 1.0](https://openid.net/specs/openid-connect-federation-1_0.html) should be updated to make sure that they don’t conflict with request authentication methods at the backchannel authentication endpoint and the device authorization endpoint listed above.

One concern is that the example value of `request_authentication_methods_supported` uses `ar` and `par` for the authorization endpoint and the pushed authorization request endpoint like below.

```json
"request_authentication_methods_supported": {
    "ar": [
        "request_object"
    ],
    "par": [
        "private_key_jwt",
        "self_signed_tls_client_auth"
    ]
}
```

Because a rule on how to shorten endpoint names is not defined, sooner or later, we’ll have to discuss how to shorten names of “backchannel authentication endpoint” and “device authorization endpoint”.

Considering forward compatibility into account, official names \(such as ones registered in [the OAuth Authorization Server Metadata section](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata) in [the IANA OAuth Parameters registry](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml)\) should be used like below.

```json
"request_authentication_methods_supported": {
    "authorization_endpoint": [
        "request_object"
    ],
    "pushed_authorization_request_endpoint": [
        "request_object",
        "private_key_jwt",
        "tls_client_auth",
        "self_signed_tls_client_auth"
    ],
    "backchannel_authentication_endpoint": [
        "request_object",
        "private_key_jwt",
        "tls_client_auth",
        "self_signed_tls_client_auth"
    ],
    "device_authorization_endpoint": [
        "private_key_jwt",
        "tls_client_auth",
        "self_signed_tls_client_auth"
    ]
}
```

‌