OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
draft-ietf-oauth-mtls-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, The IESG <iesg@ietf.org>, rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens' to Proposed Standard (draft-ietf-oauth-mtls-17.txt)

The IESG has approved the following document:
- 'OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
   Access Tokens'
  (draft-ietf-oauth-mtls-17.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

Ballot Text

Technical Summary

	This document describes OAuth client authentication and certificate bound access 
	tokens using mutual Transport Layer Security (TLS) authentication with X.509 
	certificates.  OAuth clients are provided a mechanism for authentication to the 
	authorization sever using mutual TLS, based on either self-signed certificates 
	or public key infrastructure (PKI).  OAuth authorization servers are provided a
	mechanism for binding access tokens to a client's mutual TLS certificate, and 
	OAuth protected resources are provided a method for ensuring that such an access 
	token presented to it was issued to the client presenting the token.

Working Group Summary

	There is consensus on the contents of this document.  

        This work was motivated by a request from OpenBanking UK to allow the OAuth 
	Client and OAuth Authorization Server establish a mutually authenticated 
	channel.

Document Quality

	A number of people reviewed the document over several rounds of reviews and 
	provided feedback during meetings and on the mailing list, with no blocking
	comments.

	Implementations:
	Ping Identity has implemented one of the two methods, PKI-based method.
	Ping Identity also supports the certificate bound access token.

	Authlete has an implementation of this document.
	https://www.authlete.com/

	ConnectId has an implementation.
	https://connect2id.com/blog/connect2id-server-6.13

        oidc-provider:
        https://github.com/panva/node-oidc-provider


	References:
	OpenBanking UK reference this document 
	https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2

	OpenID WG reference
	https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default

	OpenID Foundation FAPI WG ref to MTLS
	https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default

        Berlin Group‘s Nextgen PSD2 Spec:
        https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

Personnel

	The document shepherd is Rifaat Shekh-Yusef. 
	The responsible Area Director is Roman Danyliw.

RFC Editor Note