Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Aug 21, 2019 at 03:21:23PM -0600, Brian Campbell wrote:
> Thanks Ben, I attempt (over the course of many hours) to respond to your
> comments and discuss your discuss inline below.
> 
> On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker <
> [e-mail]> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-mtls-16: Discuss
> >
> > ----------------------------------------------------------------------
> > 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.
> >
> 
> Is there some text that you can propose?
> 
> Whether or not to ask for or require MTLS and how to determine when is
> going to be a deployment decision of the RS. I don't think what you
> describe as the naive conclusion is all that naive at all. But maybe that

Well, I think it was naive when I wrote it, because I didn't think very
hard.  But it's possible to be naive and be correct at the same time...

> just makes me naive:) In implementations/deployments that I've seen thus
> far, a particular RS decides (or is dictated by some policy) that its stuff
> is high value enough that it needs cert-bound access tokens so it always
> sends a CertificateRequest to the client during the TLS handshake. Such an
> RS that also wants to allow access via non cert-bound access tokens might
> just let the TLS connection proceed even if the client doesn't offer a
> certificate or it might offer its stuff on a different host and/or port
> that is just regular TLS. I don't want to preclude the use of renegotiation
> or post-handshake authentication but (other than some past pain with
> renegotiation) I'm not really qualified to discuss or make recommendations
> about using them.
> 
> Note also there is not something like RFC 8414 and RFC 7591 for RSs and
> (for good reasons I think) the WG has balked at working on something like
> that. So the requirements/capabilities/preferences of an RS will need to be
> communicated or configured out-of-band. And that's the case in general for
> RSs independent of this document.

Sure, and I don't really see that changing anytime soon.

In terms of proposed text, it looks like after the first paragraph of
Section 3 would be a reasonable place, perhaps:

In order for a resource server to use certificate-bound access tokens, it
must have advance knowledge that mtls is to be used for some or all
resource accesses.  In particular, the client ID or access token itself
cannot be used as input to the decision of whether or not to use mtls,
since from the TLS perspective those are "Application Data", only exchanged
after the TLS handshake has been completed, and the initial
CertificateRequest occurs during the handshake, before the Application Data
is available.  Although subsequent opportunities for a TLS client to
present a certificate may be available, e.g., via TLS 1.2 renegotiation
[RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document
makes no provision for their usage.  It is expected to be common that a
mtls-using resource server will require mtls for all resources hosted
thereupon, or will serve mtls-protected and regular resources on separate
hostname+port combinations, though other workflows are possible.  How
resource server policy is synchronized with the AS is out of scope for this
document.

And then the following paragraph could start "Within the scope of an
mtls-protected resource-access flow,"

> (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).)
> >
> 
> The end of sec 2
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2
>  says what to do in the case of a certificate mismatch in client auth:
>    "If the presented certificate doesn't match that
>    which is expected for the given "client_id", the authorization server
>    returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749
>    [RFC6749] with the "invalid_client" error code to indicate failed
>    client authentication."
> 
> And my intent and assumption was that a mismatch covered the case where no
> certificate was presented (i.e. null cert doesn't match expected cert just
> as different cert doesn't match). But perhaps that particular case should
> be made more explicit?  The second to last paragraph of sec 3

It probably should; "if the presented certificate" as a predicate could
fairly be easily read as to ignore the case where no certificate is
presented.

> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar
> guidance for error handing in the case of mismatch during resource access.
> 
> The case of a so called public client that has
> tls_client_certificate_bound_access_tokens metadata of true that shows up
> at the token endpoint without having done MTLS is a bit more nuanced and I
> think it's untimely a policy decision for the AS at that point as to
> whether to error or issue an unbound token.

Do you have any feelings about whether or not you want to mention that case
explicitly as being up to local policy at the AS (vs. leaving it implicit
as is presently being done)?

> 
> 
> >
> > (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".)
> >
> 
> Here's a quick back of the napkin calculation that gives 43 characters: SHA
> 256 produces a 256 bit output, which is 32 bytes. Base64url encoding 32
> bytes gives 43 bytes/characters of output (the ratio of output bytes to
> input bytes is 4:3 with base64 encoding).
> 
> I am not *nix skilled enough to troubleshoot that command pipeline but I
> suspect that the sha256sum output is in hex which represents each byte of
> the hash output with two charterers and thus double the resultant size.

Please excuse me while I wipe the egg off my face.
Yes, that sha256sum output is in hex, and I should have counted the bits
directly.  I hope you did not waste too much time on this (and now I can
get the thumbprint to agree).

> I don't believe this particular example has been validated by other folks
> but it was produced using code that has produced consistent results with
> other implementers. Also it's code from an existing JOSE/JWT library (
> https://bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing
> support for the x5t / x5t#S256 parameters in JWS and JWK.

Thanks for the heads-up about how the example was generated; it's
reassuring.

> 
> 
> >
> >
> > ----------------------------------------------------------------------
> > 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).
> >
> 
> That was intentional and meant to show that access token validation can
> happen locally (in the box) or by introspection call-out to the AS (the
> arrow). Maybe this could be done a bit differently, with I dunno sub items
> of C1 and C2 or something, that would be more clear?

Hmm.  With the explanation, it makes sense.  It's possible that C1/C2 might
be more clear, though, but don't  feel obligated to do that.

> 
> 
> >
> >    (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.
> >
> 
> Will remove.
> 
> 
> >
> >    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.
> >
> 
> ok
> 
> 
> >
> >    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".
> >
> 
> ok
> 
> 
> >
> >    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.
> >
> 
> I kinda felt like that was implied at this point. But I can add "using this
> token" there, if you think it's needed or helpful?

Or perhaps "using a certificate-bound token".  I think it's just barely
worth adding, since this section is largely reiterating the general OAuth
flow, and this helps emphasize that the "and holding the private key" is
the important/new part.

> 
> >
> > 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" :)
> >
> 
> ok
> 
> 
> >
> > 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"...
> >
> 
>  RFC 6125 "Representation and Verification of Domain-Based Application
> Service
>  Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
>      Certificates in the Context of Transport Layer Security (TLS)" came up
> at one point but given that certificate usage in this draft aren't about
> Domain-Based Application Services I was unable to see the applicable or how
> using it might help.

Okay, if it was already considered and rejected I don't want to rehash old
ground.

> 
> 
> >
> > 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.
> >
> 
> It's gotta be done (unless using the self-singed method) and it is
> definitely up to deployments as I wouldn't even pretend to know where to
> begin on providing general guidance nor would I think it appropriate.
> 
> I felt like this was pretty well implied and touched on in security
> considerations too. But please suggest some specific text, if you think
> it's needed or would be useful.

Maybe a couple lines at the end of Section 7.3, "TLS certificate validation
(for both client and server certificates) requires a local database of
trusted certificate authorities (CAs).  Decisions about what CAs to trust
and how to make such a determination of trust are out of scope for this
document, but such policy must be consistent between AS and RS for reliable
operation."?

> 
> 
> > Section 2.1.2
> >
> > Similarly the tls_client_auth_san_uri could be a URI-ID.
> >
> 
> Similar to the above I'm really not seeing how or why this would be done or
> useful.
> 
> 
> 
> >
> >    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...
> >
> 
> I don't know, to be honest. The text in question came as a suggestion from
> someone on the WG list and it seemed good enough to me.  I sort of thought
> it would probably be pretty obvious too. However the other IESG ballot
> positions have also had similar(ish) comments (see
> https://mailarchive.ietf.org/arch/msg/oauth/PbpygP8an-e80dDolo97Q5cBdd4 and
> https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so
> it seems something more or different is needed with respect to this
> tls_client_auth_san_ip thing. The suggestion from Suresh around RFC 5952
> seems promising but I need to look further into it than just reading the
> title. Which I'll do. But also trying to be somewhat timely in responding
> to these reviews.
> 
> I've also never been able to think of a case where tls_client_auth_san_ip
> is actually needed so maybe removing it all together is an option as well.

That all sounds reasonable to me; I'm happy to leave this topic to the
other ballot threads (or remove the option entirely).

> 
> 
> >
> > 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.
> >
> 
> That juxtaposition arises out of the way JWK is primarily about bare public
> keys and certificates are an optional additional JSON member.
> 
> 
> >
> > 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.
> >
> 
> What it is trying to say is that the AS does what the AS does in terms of
> client auth including dealing with trust anchors and what type of subject
> name or allowing for self singed auth matching against explicitly
> configured certs. But, because the token is bound to the hash of the cert,
> the RS need not concern itself with any of that and can treat the client
> TLS certificate as only a proof-of-possession mechanism for using the
> access token. Does that help your understanding or just confuse things
> further?

I think it helps my understanding, thanks.
Perhaps it is the RS's verification of proof-of-possession that is
decoupled from the client's authentication to the AS, then?

> 
> >
> >    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?
> >
> 
> Configured and/or based on the presence of the cnf claim with x5t#S256
> method in the access token.

Okay.
(I think this may have been the part of my notes that was a precursor to
the Discuss point; sorry if it was underdeveloped or unclear.)

> 
> 
> >
> > 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.
> >
> 
> Makes sense. I'll incorporate some text borrowed from 7525 in 3.1 and/or
> 7.2.
> 
> 
> >
> > There's only 43 characters of base64 in the "x5t#S256" example; for
> > SHA-256 output shouldn't there be 86?
> >
> 
> see previous explanation of why 43 seems right based on my math and code
> 
> 
> >
> > Section 3.2
> >
> > (Same comment about the length of base64 in the example, in Figure 3.)
> >
> 
> same same
> 
> 
> >
> > Section 3.3
> >
> > We should probably reference RFC 8414 (at least) the first time we talk
> > about authorizaiton server metadata parameters.
> >
> 
> Yeah, that's an oversight on my part. Will fix.
> 
> 
> >
> > Section 3.4
> >
> > Similarly, we could reference RFC 7591 here.
> >
> 
> RFC 7591 has been referenced several times already at this point.

Okay.

> >
> > 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.
> >
> 
> Shoot, okay. Will do.

Thanks.  Though I do wonder whether "we" should ask to have it added ... I
wonder how well-known it is outside the security area.

> 
> >
> > 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.
> >
> 
> I take your point but the text (which I did not write FWIW) was meant to be
> practical guidance based on an understanding of how the most common web
> servers work (problem in chain validation terminates the handshake) and the
> options they provide (can turn off cert chain validating) and what they
> surface about the handshake results (AFAIK not the kind of info that would
> allow the distinction you mention so the whole process of chain validation
> would maybe have to be deferred to the application layer). I can try and
> add or amend some text along the lines of your comment. But I worry I'd do
> more harm than good in doing so.

I sympathize with your concern; please don't feel obligated to take any
action here on this non-blocking comment.

> 
> 
> > 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?
> >
> 
> I'm sure there is some such scenario out there. But this is meant as
> implementation considerations or guidance for the general or common cases.

Okay; we definitely don't have to cover such things in this document.

> 
> >
> > 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?
> >
> 
> The only time a refresh token is bound directly to the client certificate
> is for public clients (
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-4 and
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-7.1) and
> public clients can only use self signed certificates for which the
> expiration isn't all that meaningful and can be made to be far enough in
> the future.

Oh, I think I was misunderstanding what the "indirectly certificate-bound"
meant in 7.1.  Okay, this seems less worrisome now.

> 
> >
> > 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.
> >
> 
> I understand what you are saying but don't know what I would actually write
> and kinda think that anything along those lines should have been in RFC
> 7591 anyway because it's applicable there and not just in the context of
> this narrow document.

I guess in some sense this is already done in RFC 3986 (Section 7.1), too,
which 7591 unfortunately does not cite directly.

> 
> >
> > 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?
> >
> 
> I guess it's both? But "indirectly" seemed right to me. The word "implicit"
> also has some meaning and connotations in the general word of OAuth, which
> are unrelated but I was trying to avoid it just the same.

Per your clarification above, I think I misunderstood the meaning here.
My new suggestion would be "indirectly certificate-bound by way of the
clientID and the associated requirement for (certificate-based)
authentication to the AS", if that's not too unwieldly.

> 
> >
> > 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.
> >
> 
> okay
> 
> 
> >
> > 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.
> >
> 
> I am not equipped with the knowledge to do that rewording. Please suggest
> some specific text, if you'd like to have it reworded.

How about:

o handling of embedded NUL bytes in ASN.1 counted-length strings, and
non-canonical or non-normalized string representations in subject names


> 
> >
> >    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.
> >
> 
> Also there is no allowance anywhere in this draft for using wildcards in
> subject names for the client certificate. This whole section came as a
> suggestion doing WGLC that was taken to get through WGLC. But it's not
> entirely contextually relevant. This bullet in particular. Maybe it'd be
> better to remove it?

I'd leave it in.  I don't think I had any specific change in mind here, and
was just making an observation.

> 
> >
> > 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.
> >
> 
> I have balked at adding any such discussion and will continue to do so
> because there is likely so much correlateble info in an access token
> already that the client has no control over and might well not even know
> about. I don't know how to write what you're suggesting in a meaningful way
> and without giving the impression that using a different certificate
> provides privacy benefits that are not really there.

Okay.  You're much closer to what access tokens look like in practice than
I am, and this is a fairly theoretical scenario anyway.

> 
> >
> > Section 9.2
> >
> >    This specification requests registration of the following value in
> >
> > nit: "values" plural
> >
> 
> Will fix and also found and will fix the same thing in 9.3
> 
> 
> >
> > Section 10.2
> >
> > I think that RFC 7517 needs to be normative, since we use the jwks
> > containers for conveying certificate information.
> >
> 
> okay
> 
> 
> >
> > It also seems like RFCs 7591 and 8414 should probably be normative.
> >
> 
> I was on the fence with these two as i didn't think they are strictly
> necessary but am happy to move them to normative. 7519 and 7662 probably
> too.
> 
> 
> >
> > Traditionally we keep RFC 8174 as normative, as part of BCP 14 along
> > with RFC 2119.
> >
> 
> I think I knew that but somehow got it wrong here. Will fix.

Thanks for all the updates!

-Ben