Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2020-02-28
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-01-28
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-01-27
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-11-04
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-09-16
17 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-09-16
17 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-09-16
17 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-09-13
17 (System) IANA Action state changed to Waiting on Authors
2019-09-11
17 (System) RFC Editor state changed to EDIT
2019-09-11
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-09-11
17 (System) Announcement was received by RFC Editor
2019-09-11
17 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-09-11
17 Amy Vezza IESG has approved the document
2019-09-11
17 Amy Vezza Closed "Approve" ballot
2019-09-11
17 Amy Vezza Ballot approval text was generated
2019-09-11
17 Roman Danyliw IESG state changed to Approved-announcement to be sent from IESG Evaluation
2019-09-11
17 Roman Danyliw IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2019-08-26
17 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Susan Hares was marked no-response
2019-08-23
17 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss (and Comment!) points!
2019-08-23
17 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-08-23
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-23
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2019-08-23
17 Brian Campbell New version available: draft-ietf-oauth-mtls-17.txt
2019-08-23
17 (System) New version approved
2019-08-23
17 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-08-23
17 Brian Campbell Uploaded new revision
2019-08-22
16 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-08-22
16 Éric Vyncke [Ballot comment]
Thank you for the hard work put into this extensive document.

I second Suresh's COMMENT about IPv6 address representation.

Regards,

-éric
2019-08-22
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-08-22
16 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-08-21
16 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-08-21
16 Warren Kumari
[Ballot comment]
Thank you for a very readable document -- I'd put off reading this because I'd assumed it was going to be really hard …
[Ballot comment]
Thank you for a very readable document -- I'd put off reading this because I'd assumed it was going to be really hard to follow if you are not an expert in this art, but was pleasantly surprised at how approachable it is.
2019-08-21
16 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-08-21
16 Alissa Cooper [Ballot comment]
I did not review this document myself but I'm ballot based on the Gen-ART review.
2019-08-21
16 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-08-21
16 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-08-20
16 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2019-08-20
16 Suresh Krishnan
[Ballot comment]
* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in RFC4291 section 2.2. …
[Ballot comment]
* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in RFC4291 section 2.2. The canonical representation described in RFC5952 makes it easier to compare two IPv6 address strings which is probably something you want to do while doing mutual authentication.
2019-08-20
16 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2019-08-20
16 Suresh Krishnan
[Ballot comment]
* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in [RFC4291] …
[Ballot comment]
* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in [RFC4291] section 2.2. The canonical representation described in RFC5952 makes it easier to compare two IPv6 address strings which is probably something you want to do while doing mutual authentication.
2019-08-20
16 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-08-19
16 Adam Roach
[Ballot comment]

Thanks for the work that everyone did on this document. I have one suggestion
for clarification, followed by a handful of editorial nits. …
[Ballot comment]

Thanks for the work that everyone did on this document. I have one suggestion
for clarification, followed by a handful of editorial nits.

---------------------------------------------------------------------------

§2.1.2:

>  tls_client_auth_san_ip
>    A string representation of an IP address in either dotted decimal
>    notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
>    defined in [RFC4291] section 2.2) that is expected to be present
>    as an iPAddress SAN entry in the certificate, which the OAuth
>    client will use in mutual TLS authentication.

This probably needs some text that clarifies expectations around comparison
and/or normalization. For example, if the iPAddress value in the cert is
"20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's), one
should presume that this would match both tls_client_auth_san_ip values
"2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, then
this document needs to talk about normalization of address representation.


---------------------------------------------------------------------------

§1:

>  Layering on the abstract flow above, this document standardizes
>  enhanced security options for OAuth 2.0 utilizing client certificate
>  based mutual TLS.

Nit: "client-certificate-based"

>  OAuth 2.0 defines a shared secret method of client authentication but

Nit: "shared-secret"

---------------------------------------------------------------------------
§1:

>  This document describes an additional
>  mechanism of client authentication utilizing mutual TLS certificate-
>  based authentication

Nit: "mutual-TLS"

>  Mutual TLS certificate-bound access tokens ensure that only the party

Nit: "Mutual-TLS"

>  Mutual TLS certificate-bound access tokens and mutual TLS client

Nit: "Mutual-TLS... mutual-TLS"

>  Additional client metadata parameters are introduced by this document
>  in support of certificate-bound access tokens and mutual TLS client
>  authentication.

Nit: "mutual-TLS"

The remainder of the document has several other uses of the phrase "mutual
TLS" as an adjective; they should be similarly hyphenated. I will not call
them out individually. (Non-adjectival uses should not contain hyphens, so
this isn't a simple find-and-replace operation.)

---------------------------------------------------------------------------

§5:

>  Authorization servers supporting both clients using mutual TLS and
>  conventional clients MAY chose to isolate the server side mutual TLS
>  behaviour to only clients intending to do mutual TLS, thus avoiding

Nit: "behavior" (or adjust other spellings in the document to be consistently
British).
2019-08-19
16 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-08-19
16 Benjamin Kaduk
[Ballot discuss]
(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send …
[Ballot discuss]
(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake).  The authorization server and client
can indicate their capabilities/preference via the RFC 8414 and RFC 7591
discovery and registration procedures, but I didn't see any discussion
of how an AS might know a RS's capabilities, or how an RS might develop
expectations of the capabilities of the clients accessing it.  A naive
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in
the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators).  Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.

(We may also want some additional text discussing error handling for the
client/AS interaction, e.g., if a request shows up from a client-id that
should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used
the regular token endpoint and not the mtls endpoint alias (if they
differ).)

(2) I can't validate the examples in Appendix A.

Specifically, my reading of the text would put the "x5t#S256" value as
needing 86 characters, but only 43 are provided.  The ones there also do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:

base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64

(Noting, of course, that 'base64' will be producing the non-URL-safe
variant, but expecting it to remain "pretty close".)

I also had some trouble comparing the "y" coordinate from the JWK to the
certificate contents, but that may just be user error.
2019-08-19
16 Benjamin Kaduk
[Ballot comment]
Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are …
[Ballot comment]
Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).

  (C)  The protected resource validates the access token in order to
        authorize the request.  In some cases, such as when the token is
        self-contained and cryptographically secured, the validation can
        be done locally by the protected resource.  While other cases
        require that the protected resource call out to the
        authorization server to determine the state of the token and
        obtain meta-information about it.

nit: "While" is a conjunction but this last sentence only has one
clause.

  Layering on the abstract flow above, this document standardizes
  enhanced security options for OAuth 2.0 utilizing client certificate
  based mutual TLS.  Section 2 provides options for authenticating the

nit: "client-certificate-based" is hyphenated.

  request in step (A).  While step (C) is supported with semantics to
  express the binding of the token to the client certificate for both
  local and remote processing in Section 3.1 and Section 3.2
  respectively.  This ensures that, as described in Section 3,

nit: same thing about "while".

  protected resource access in step (B) is only possible by the
  legitimate client bearing the access token and holding the private
  key corresponding to the certificate.

nit: I guess it is only protected resource access "using this tokwn"
that is only possible as specified.

Section 1.2

We probably want to say something like "in addition to the normal TLS
server authentication with a certificate" -- we need both for it to
properly be "mutual" :)

Section 2.1

  The PKI (public key infrastructure) method of mutual TLS OAuth client
  authentication adheres to the way in which X.509 certificates are
  traditionally used for authentication.  It relies on a validated
  certificate chain [RFC5280] and a single subject distinguished name
  (DN) or a single subject alternative name (SAN) to authenticate the
  client.  Only one subject name value of any type is used for each

I think we might be able to refer to RFC 6125 and call these the "CN-ID"
and "DNS-ID".  That might also let us get out of doing quite as much
referencing to RFC 4514 and specifying string representations "by hand"...


I'm surprised to not see any discussion of trust anchor management or
how to indicate (or decide) which CAs are to be trusted for this
purpose, even if that's just to acknowledge that it must be done but
leave it up to deployments.

Section 2.1.2

Similarly the tls_client_auth_san_uri could be a URI-ID.

  tls_client_auth_san_ip
      A string representation of an IP address in either dotted decimal
      notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
      defined in [RFC4291] section 2.2) that is expected to be present
      as an iPAddress SAN entry in the certificate, which the OAuth
      client will use in mutual TLS authentication.

Do we want to note that this string representation differs from the
actual iPAddress encoding?  I guess by the time you go to actually
implement it, it's probably pretty obvious, though...

Section 2.2.2

  For the Self-Signed Certificate method of binding a certificate with
  a client using mutual TLS client authentication, the existing
  "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
  convey the client's certificates via JSON Web Key (JWK) in a JWK Set
  (JWKS) [RFC7517].  The "jwks" metadata parameter is a JWK Set
  containing the client's public keys as an array of JWKs while the
  "jwks_uri" parameter is a URL that references a client's JWK Set.  A
  certificate is represented with the "x5c" parameter of an individual
  JWK within the set.  Note that the members of the JWK representing

nit: "containing the client's public keys" is a bit of a juxtaposition
with "represented with the "x5c" parameter" (which is certificates).
True, the certificate does contain the public key, so it's not exactly
wrong, but since we focus elsewhere on the certificate, it may not make
sense to focus on the public key here.

Section 3

                Binding the access token to the client certificate in
  that fashion has the benefit of decoupling that binding from the
  client's authentication with the authorization server, which enables
  mutual TLS during protected resource access to serve purely as a
  proof-of-possession mechanism.  Other methods of associating a

I don't think I understand what's meant about "decoupling that binding
from the client's authentication with the authorization server" -- it
seems like the authorization server shouldn't issue a bound token
without some proof of possession, which the client's authentication
thereto performs.

  The protected resource MUST obtain, from its TLS implementation
  layer, the client certificate used for mutual TLS and MUST verify
  that the certificate matches the certificate associated with the
  access token.  If they do not match, the resource access attempt MUST

How does the resource server know it needs to do this?  Is this just
configured as part of the ability to do mutual TLS, or indiated by a
token type, or something else?

Section 3.1

Per BCP 201, we may want to say something about this recommendation
changing over time as cryptographic algorithm preferences change.  RFC
7525
has a decent note to this effect:

  Community knowledge about the strength of various algorithms and
  feasible attacks can change quickly, and experience shows that a Best
  Current Practice (BCP) document about security is a point-in-time
  statement.  Readers are advised to seek out any errata or updates
  that apply to this document.

(obviously the "BCP" part doesn't apply to this document, but most of
the rest should.)  This could of course be coordinated between here and
Section 7.2.

There's only 43 characters of base64 in the "x5t#S256" example; for
SHA-256 output shouldn't there be 86?

Section 3.2

(Same comment about the length of base64 in the example, in Figure 3.)

Section 3.3

We should probably reference RFC 8414 (at least) the first time we talk
about authorizaiton server metadata parameters.

Section 3.4

Similarly, we could reference RFC 7591 here.

Section 5

                                                                Note
  that the endpoints in "mtls_endpoint_aliases" use a different host
  than their conventional counterparts, which allows the authorization
  server (via SNI or actual distinct hosts) to differentiate its TLS
  behavior as appropriate.

nit: Sadly, "SNI" does not appear in
https://www.rfc-editor.org/materials/abbrev.expansion.txt as a
"well-known" abbreviation, so we probably have to say 'TLS "server_name"
extension [RFC 6066]' or similar.

Section 6.1

  In order to support the Self-Signed Certificate method, the
  authorization server would configure the TLS stack in such a way that
  it does not verify whether the certificate presented by the client
  during the handshake is signed by a trusted CA certificate.

This statement doesn't quite follow -- *support*ing self-signed
certificates only requires that you configure TLS to not require a valid
client cert+chain for the handshake to succeed, but it can still try to
validate such a chain.  This would be useful if, for example, you
intended to support both self-signed and CA-signed certificates.
We may also want a specific note to implementors to check validation
results for certificates intended to be CA-signed, if we're going to
include a note about disabling validation for self-signed cert usage.

Section 6.2

Would there be any scenario in which "additional security" might be
gained from having the RS check that the client-presented cert does
chain to a trusted CA?

Section 6.3

Isn't this ignoring the elephant in the room about what to do when the
refresh token is also bound to the (expiring) client certificate?

Section 6.5

There are a couple of active proposals for new, secure, protocols from
load balancer to backend server, but probably not anything quite mature
enough to be worth referencing from here.
(e.g., draft-schwartz-tls-lb and another one that I think was presented
in QUIC but I can't find right now)

Section 7

We could potentially also talk about how the use of jwks_uri requires
a fairly strong level of trust in the service at the target of the URI:
the client has to trust it to faithfully provide the certification
information, and the RS has to trust it to provide valid data for the
client in question, as well as the usual trust in the TLS connection
that identifies it, etc.

Section 7.1

  The OAuth 2.0 Authorization Framework [RFC6749] requires that an
  authorization server bind refresh tokens to the client to which they
  were issued and that confidential clients (those having established
  authentication credentials with the authorization server)
  authenticate to the AS when presenting a refresh token.  As a result,
  refresh tokens are indirectly certificate-bound when issued to
  clients utilizing the "tls_client_auth" or
  "self_signed_tls_client_auth" methods of client authentication.

nit(?): is this "indirectly" or "implicitly" bound?

Section 7.2

I'm not sure why we mention both (first) preimage and second-preimage
resistance, as they're pretty different properties.  I suppose there
could be some registration scenarios where only the thumbprint is
provided and thus an attacker with a DB dump would not have the first
preimage in the form of the actual intended certificate, but even if
they could reconstruct that "real" preimage from the thumbprint they
wouldn't have the corresponding private key.  So second-preimage
probably covers what we need, and we can assume that the "first"
preimage (certificate) is always available to the attacker.

Section 7.4

Maybe we should say "agree out of band" on the set of trust anchors.

Section 7.5

  o  handling of null-terminator bytes and non-canonical string
      representations in subject names;

ASN.1 encodings are going to be using counted strings, so any
NUL terminators will be in implementation languages.  I think we might
want to reword this to indicate that ASN.1 strings cannot be directly
interpreted as native language strings in languages that use NUL
terminators.

  o  handling of wildcard patterns in subject names;

Interestingly, RFC 5280 punts on the semantics of wildcard characters in
SANs, though I think many applications will insist on only a single
wildcard and the leftmost label being just the single wildcard
character.

Section 8

There's perhaps some additional considerations if a client uses the same
certificate across multiple RSes, in that the client certificate
provides an additional mechanism for collaborating RSes to correlate a
single client, in ways that just the access token would not.  This is
not a terribly common threat model in a highly centralized deployment
where all RSes are fairly well trusted, of course, but there can be some
environments where it is relevant, so it probably merits discussion.

Section 9.2

  This specification requests registration of the following value in

nit: "values" plural

Section 10.2

I think that RFC 7517 needs to be normative, since we use the jwks
containers for conveying certificate information.

It also seems like RFCs 7591 and 8414 should probably be normative.

Traditionally we keep RFC 8174 as normative, as part of BCP 14 along
with RFC 2119.
2019-08-19
16 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-08-19
16 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-08-19
16 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-08-19
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-08-19
16 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-08-13
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2019-08-13
16 Brian Campbell New version available: draft-ietf-oauth-mtls-16.txt
2019-08-13
16 (System) New version approved
2019-08-13
16 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-08-13
16 Brian Campbell Uploaded new revision
2019-08-12
15 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup
2019-08-12
15 Cindy Morgan Placed on agenda for telechat - 2019-08-22
2019-08-12
15 Roman Danyliw Ballot has been issued
2019-08-12
15 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2019-08-12
15 Roman Danyliw Created "Approve" ballot
2019-08-12
15 Roman Danyliw Ballot writeup was changed
2019-08-12
15 Roman Danyliw
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10
document since the document defines new mechanisms to enhance the security of
the OAuth protocol that has normative extensions to the interaction between the
OAuth Client and OAuth Authorization Server.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

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:
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.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed this document and feels the document is ready.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd has no concerns with the level of reviews, as the document
was discussed and reviewed by many participants.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Security review is always appreciated.


(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The document shepherd has no such concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html
John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html
Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html
Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No such IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There was a solid WG consensus that included feedback and support from multiple
parties and individuals.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No such threat or discontent.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

Id nits returns that the RFC5246 is obsoleted by RFC 8446.  However, including references to RFC5246 and RFC8446 is intentional.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No such reviews are necessary.


(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document registers new values with existing registries.
The document does not introduce any new registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

The document contains JSON-based examples, and these were validated using JSONLint.

2019-08-12
15 Roman Danyliw
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10
document since the document defines new mechanisms to enhance the security of
the OAuth protocol that has normative extensions to the interaction between the
OAuth Client and OAuth Authorization Server.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

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:
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 Eric Rescorla.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed this document and feels the document is ready.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd has no concerns with the level of reviews, as the document
was discussed and reviewed by many participants.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Security review is always appreciated.


(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The document shepherd has no such concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html
John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html
Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html
Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No such IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There was a solid WG consensus that included feedback and support from multiple
parties and individuals.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No such threat or discontent.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

Id nits returns that the RFC5246 is obsoleted by RFC 8446.  However, including references to RFC5246 and RFC8446 is intentional.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No such reviews are necessary.


(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document registers new values with existing registries.
The document does not introduce any new registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

The document contains JSON-based examples, and these were validated using JSONLint.

2019-08-08
15 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2019-08-01
15 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-08-01
15 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-oauth-mtls-15. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-oauth-mtls-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the JWT Confirmation Methods registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

a single, new registration will be made as follows:

Confirmation Method Value: x5t#S256
Confirmation Method Description: X.509 Certificate SHA-256 Thumbprint
Change Controller: IESG
Reference: [ RFC-to-be; Section 3.1 ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JWT Confirmation Methods have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the OAuth Authorization Server Metadata registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

two, new registrations are to be made as follows:

Metadata Name: tls_client_certificate_bound_access_tokens
Metadata Description: Indicates authorization server support for mutual TLS client certificate-bound access tokens.
Change Controller: IESG
Reference: [ RFC-to-be; Section 3.3 ]

Metadata Name: mtls_endpoint_aliases
Metadata Description: JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints.
Change Controller: IESG
Reference: [ RFC-to-be; Section 5 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the OAuth Authorization Server Metadata have asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the OAuth Token Endpoint Authentication Methods registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

two, new registrations are to be made as follows:

Token Endpoint Authentication Method Name: tls_client_auth
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.2.1 ]

Token Endpoint Authentication Method Name: self_signed_tls_client_auth
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.2.1 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the OAuth Token Introspection Respons registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

a single, new registration is to be made as follows:

Name: cnf
Description: Confirmation
Change Controller: IESG
Reference: [RFC7800][ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fifth, in the OAuth Dynamic Client Registration Metadata registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

six, new registrations are to be made as follows:

Client Metadata Name: tls_client_certificate_bound_access_tokens
Client Metadata Description: Indicates the client's intention to use mutual TLS client certificate-bound access tokens.
Change Controller: IESG
Reference: [ RFC-to-be; Section 3.4 ]

Client Metadata Name: tls_client_auth_subject_dn
Client Metadata Description: String value specifying the expected subject DN of the client certificate.
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.2 ]

Client Metadata Name: tls_client_auth_san_dns
Client Metadata Description: String value specifying the expected dNSName SAN entry in the client certificate.
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.2 ]

Client Metadata Name: tls_client_auth_san_uri
Client Metadata Description: String value specifying the expected uniformResourceIdentifier SAN entry in the client certificate.
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.2 ]

Client Metadata Name: tls_client_auth_san_ip
Client Metadata Description: String value specifying the expected iPAddress SAN entry in the client certificate.
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.2 ]

Client Metadata Name: tls_client_auth_san_email
Client Metadata Description: String value specifying the expected rfc822Name SAN entry in the client certificate.
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.2 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-08-01
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-07-25
15 Vincent Roca Request for Last Call review by SECDIR Completed: Ready. Reviewer: Vincent Roca. Sent review to list.
2019-07-18
15 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-07-18
15 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-07-15
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Vincent Roca
2019-07-15
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Vincent Roca
2019-07-15
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-07-15
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-07-11
15 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-07-11
15 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-08-01):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, …
The following Last Call announcement was sent out (ends 2019-08-01):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Mutual TLS Client
Authentication and Certificate-Bound
  Access Tokens'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes OAuth client authentication and certificate-
  bound access and refresh tokens using mutual Transport Layer Security
  (TLS) authentication with X.509 certificates.  OAuth clients are
  provided a mechanism for authentication to the authorization server
  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-07-11
15 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-07-11
15 Cindy Morgan Last call announcement was changed
2019-07-11
15 Roman Danyliw Last call was requested
2019-07-11
15 Roman Danyliw Last call announcement was generated
2019-07-11
15 Roman Danyliw Ballot approval text was generated
2019-07-11
15 Roman Danyliw Ballot writeup was generated
2019-07-11
15 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-07-03
15 Brian Campbell New version available: draft-ietf-oauth-mtls-15.txt
2019-07-03
15 (System) New version approved
2019-07-03
15 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-07-03
15 Brian Campbell Uploaded new revision
2019-06-22
14 Roman Danyliw Second AD Review: https://mailarchive.ietf.org/arch/msg/oauth/pvUVPea35ML77sWxIkDDG1llMs4
2019-04-11
14 Brian Campbell New version available: draft-ietf-oauth-mtls-14.txt
2019-04-11
14 (System) New version approved
2019-04-11
14 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-04-11
14 Brian Campbell Uploaded new revision
2019-03-27
13 Cindy Morgan Shepherding AD changed to Roman Danyliw
2019-02-25
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-25
13 Brian Campbell New version available: draft-ietf-oauth-mtls-13.txt
2019-02-25
13 (System) New version approved
2019-02-25
13 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-02-25
13 Brian Campbell Uploaded new revision
2019-01-28
13 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2019-01-28
13 Brian Campbell Uploaded new revision
2018-12-21
12 Eric Rescorla Waiting for a new I-D from Brian.
2018-11-04
12 Eric Rescorla https://mozphab-ietf.devsvcdev.mozaws.net/D3657
2018-11-04
12 Eric Rescorla IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2018-10-18
12 Brian Campbell New version available: draft-ietf-oauth-mtls-12.txt
2018-10-18
12 (System) New version approved
2018-10-18
12 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-10-18
12 Brian Campbell Uploaded new revision
2018-10-10
11 Rifaat Shekh-Yusef
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10
document since the document defines new mechanisms to enhance the security of
the OAuth protocol that has normative extensions to the interaction between the
OAuth Client and OAuth Authorization Server.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

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:
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 Eric Rescorla.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed this document and feels the document is ready.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd has no concerns with the level of reviews, as the document
was discussed and reviewed by many participants.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Security review is always appreciated.


(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The document shepherd has no such concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html
John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html
Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html
Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No such IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There was a solid WG consensus that included feedback and support from multiple
parties and individuals.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No such threat or discontent.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

There are no nits with this document.


(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No such reviews are necessary.


(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document registers new values with existing registries.
The document does not introduce any new registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

The document contains JSON-based examples, and these were validated using JSONLint.

2018-08-30
11 Brian Campbell New version available: draft-ietf-oauth-mtls-11.txt
2018-08-30
11 (System) New version approved
2018-08-30
11 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-08-30
11 Brian Campbell Uploaded new revision
2018-08-25
10 Rifaat Shekh-Yusef
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10
document since the document defines new mechanisms to enhance the security of
the OAuth protocol that has normative extensions to the interaction between the
OAuth Client and OAuth Authorization Server.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

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:
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

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 Eric Rescorla.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed this document and feels the document is ready.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd has no concerns with the level of reviews, as the document
was discussed and reviewed by many participants.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Security review is always appreciated.


(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The document shepherd has no such concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html
John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html
Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html
Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No such IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There was a solid WG consensus that included feedback and support from multiple
parties and individuals.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No such threat or discontent.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

There are no nits with this document.


(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No such reviews are necessary.


(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

No.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document registers new values with existing registries.
The document does not introduce any new registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

The document contains JSON-based examples, and these were validated using JSONLint.

2018-08-25
10 Rifaat Shekh-Yusef Responsible AD changed to Eric Rescorla
2018-08-25
10 Rifaat Shekh-Yusef IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-08-25
10 Rifaat Shekh-Yusef IESG state changed to Publication Requested
2018-08-25
10 Rifaat Shekh-Yusef IESG process started in state Publication Requested
2018-08-25
10 Rifaat Shekh-Yusef Changed consensus to Yes from Unknown
2018-08-25
10 Rifaat Shekh-Yusef Intended Status changed to Proposed Standard from None
2018-07-22
10 Rifaat Shekh-Yusef Changed document writeup
2018-07-21
10 Rifaat Shekh-Yusef Changed document writeup
2018-07-21
10 Rifaat Shekh-Yusef Changed document writeup
2018-07-17
10 Brian Campbell New version available: draft-ietf-oauth-mtls-10.txt
2018-07-17
10 (System) New version approved
2018-07-17
10 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-07-17
10 Brian Campbell Uploaded new revision
2018-07-17
09 Rifaat Shekh-Yusef IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2018-07-17
09 Rifaat Shekh-Yusef Notification list changed to Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
2018-07-17
09 Rifaat Shekh-Yusef Document shepherd changed to Rifaat Shekh-Yusef
2018-06-04
09 Brian Campbell New version available: draft-ietf-oauth-mtls-09.txt
2018-06-04
09 (System) New version approved
2018-06-04
09 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-06-04
09 Brian Campbell Uploaded new revision
2018-05-07
08 Brian Campbell New version available: draft-ietf-oauth-mtls-08.txt
2018-05-07
08 (System) New version approved
2018-05-07
08 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-05-07
08 Brian Campbell Uploaded new revision
2018-01-30
07 Brian Campbell New version available: draft-ietf-oauth-mtls-07.txt
2018-01-30
07 (System) New version approved
2018-01-30
07 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-01-30
07 Brian Campbell Uploaded new revision
2018-01-15
06 Brian Campbell New version available: draft-ietf-oauth-mtls-06.txt
2018-01-15
06 (System) New version approved
2018-01-15
06 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2018-01-15
06 Brian Campbell Uploaded new revision
2017-11-12
05 Brian Campbell New version available: draft-ietf-oauth-mtls-05.txt
2017-11-12
05 (System) New version approved
2017-11-12
05 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2017-11-12
05 Brian Campbell Uploaded new revision
2017-10-12
04 Brian Campbell New version available: draft-ietf-oauth-mtls-04.txt
2017-10-12
04 (System) New version approved
2017-10-12
04 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2017-10-12
04 Brian Campbell Uploaded new revision
2017-07-28
03 Brian Campbell New version available: draft-ietf-oauth-mtls-03.txt
2017-07-28
03 (System) New version approved
2017-07-28
03 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2017-07-28
03 Brian Campbell Uploaded new revision
2017-06-29
02 Brian Campbell New version available: draft-ietf-oauth-mtls-02.txt
2017-06-29
02 (System) New version approved
2017-06-29
02 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2017-06-29
02 Brian Campbell Uploaded new revision
2017-05-26
01 Brian Campbell New version available: draft-ietf-oauth-mtls-01.txt
2017-05-26
01 (System) New version approved
2017-05-26
01 (System) Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley
2017-05-26
01 Brian Campbell Uploaded new revision
2017-05-09
00 Rifaat Shekh-Yusef This document now replaces draft-campbell-oauth-mtls instead of None
2017-05-09
00 Brian Campbell New version available: draft-ietf-oauth-mtls-00.txt
2017-05-09
00 (System) WG -00 approved
2017-05-09
00 Brian Campbell Set submitter to "Brian Campbell ", replaces to draft-campbell-oauth-mtls and sent approval email to group chairs: oauth-chairs@ietf.org
2017-05-09
00 Brian Campbell Uploaded new revision