Subject: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

From: Roman Danyliw <[email-masked]>
Date: Sat, 22 Jun 2019 18:28:56 +0000

Hi!

I conducted as second AD review of draft-ietf-oauth-mtls per the AD hand-off.  I have the following additional feedback:

** Per ekr's earlier review at https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
-- Section 2.1.2, How is these metadata parameters being obtained?
-- Section 3.2, Figure 3.  In this example, what new information is the auth server providing to the relying party here?

** Section 2.0.  What is the expected behavior if the presented certificate doesn't match expected client_id?  How is this signaled?

** Section 2.2.  Per the sentence "As pre-requisite, the client registers its X.509 certificate ... or a trusted source for its X.509 certificates ... with the authorization server.
-- Editorial: s/As pre-requisite/As a prerequisite/
-- What's a "trusted source" in this case?  Is that just a jwks_uri?  If so, maybe s/a trusted source/a reference to a trust source/.  If not, can you please elaborate.

A few editorial nits:
** Section 2.2.2.  Typo.  s/sec 4.7/Section 4.7/

** Section 3.1  Cite DER encoding as:
    [X690]     ITU-T, "Information Technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, 2015.

** Section 5.  Typo. s/metatdata/metadata/

** Section 6.  Typo.  s/The the/The/

** Section 7.2. Typo.  s/the the/the/

** Appendix. Cite the figures numbers (#5 - 7) in the text describing the contents of the section.

The shepherd write-up is in good shape.  Thank you.

Regards,
Roman

---

From: Brian Campbell <[email-masked]>
Date: Mon, 24 Jun 2019 11:17:25 -0600

Thanks for the additional review, Roman. I feel lucky, it's not often one
gets *two* AD reviews :)  Please see below for replies inline with a few
followup questions.

On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
> I conducted as second AD review of draft-ietf-oauth-mtls per the AD
> hand-off.  I have the following additional feedback:
>
> ** Per ekr's earlier review at
> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:

The authorization server can obtain client metadata via the Dynamic Client
Registration Protocol [RFC7591], which is referenced in the top of that
section. Also the metadata defined by RFC7591, and registered extensions to
it, implies a general data model for clients that is used by most
authorization server implementations even when the Dynamic Client
Registration Protocol isn't in play. Such implementations typically have
some sort of  user interface available for managing client configuration.

Dose that answer your question? Do you believe more should be said in the
document to better explain or clarify that?

-- Section 3.2, Figure 3.  In this example, what new information is the
> auth server providing to the relying party here?
>

The new info here (and in Section 3.1 too) is the hash of the client
certificate to which the access token is bound, which is in the "cnf"
confirmation method at the bottom as the "x5t#S256" member.

>
> ** Section 2.0.  What is the expected behavior if the presented
> certificate doesn't match expected client_id?  How is this signaled?
>

With a normal OAuth 2.0 error response using the "invalid_client" error
code per https://tools.ietf.org/html/rfc6749#section-5.2

Do you think that needs to be stated more explicitly in this document?

>
> ** Section 2.2.  Per the sentence "As pre-requisite, the client registers
> its X.509 certificate ... or a trusted source for its X.509 certificates
> ... with the authorization server.

done

> -- What's a "trusted source" in this case?  Is that just a jwks_uri?  If
> so, maybe s/a trusted source/a reference to a trust source/.  If not, can
> you please elaborate.
>

Yes, it's just a jwks_uri. I'll change that.

> ** Section 2.2.2.  Typo.  s/sec 4.7/Section 4.7/

fixed

>               (DER)", ITU-T Recommendation X.690, 2015.

will do

> ** Section 5.  Typo. s/metatdata/metadata/

yup

> ** Section 6.  Typo.  s/The the/The/

got it

> ** Section 7.2. Typo.  s/the the/the/

done

> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the

will do

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 24 Jun 2019 20:14:14 +0000

Hi Brian!

My response is inline ...

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, June 24, 2019 1:17 PM
To: Roman Danyliw <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

Thanks for the additional review, Roman. I feel lucky, it's not often one gets *two* AD reviews :)  Please see below for replies inline with a few followup questions.

[Roman] *chuckle*

On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

The authorization server can obtain client metadata via the Dynamic Client Registration Protocol [RFC7591], which is referenced in the top of that section. Also the metadata defined by RFC7591, and registered extensions to it, implies a general data model for clients that is used by most authorization server implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations typically have some sort of  user interface available for managing client configuration.

Dose that answer your question? Do you believe more should be said in the document to better explain or clarify that?

[Roman]  It does clear it up.  Thanks.  I think it’s worth a short statement about how the AS would get the fields.

The new info here (and in Section 3.1 too) is the hash of the client certificate to which the access token is bound, which is in the "cnf" confirmation method at the bottom as the "x5t#S256" member.

[Roman]  Makes sense.  To make the example clearer, I’d call out this out in the prose introducing the example.

With a normal OAuth 2.0 error response using the "invalid_client" error code per https://tools.ietf.org/html/rfc6749#section-5.2

[Roman] Yes, I’d explicit state it with that citation, especially since Section 3 discusses of how errors are returned.

done

A few editorial nits:

fixed

will do

yup

got it

done

will do

Regards,
Roman

[Roman] Thanks for all of the above.

Roman

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 24 Jun 2019 15:04:01 -0600

Thanks Roman, I'll work to incorporate those suggestions into the next
revision before the impending I-D submission cutoff date.

On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw <[email-masked]> wrote:

> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Monday, June 24, 2019 1:17 PM
> *To:* Roman Danyliw <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
>
>
>
> [Roman]  It does clear it up.  Thanks.  I think it’s worth a short
> statement about how the AS would get the fields.
>
>
>
>
>
> [Roman] Yes, I’d explicit state it with that citation, especially since
> Section 3 discusses of how errors are returned.
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>