Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
draft-ietf-regext-rdap-openid-27

Thank you for the work on this document.

Many thanks to Valery Smyslov for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/DRjDxp02bsCru-Q6wL-EA-WByaQ/, and thanks to the author for addressing Valery's comments.

Thanks for addressing my concern. I've updated my ballot to No Objection.

Thank you to the authors for reaching out to the OAuth WG when this document was first being drafted.

Thank you to Justin Richer for providing a timely review of this work from the OAuth WG perspective.  See https://mailarchive.ietf.org/arch/msg/oauth/33Ci5v7EHDLRC7pvvK85uarXutY/.

I appreciate the patience of the WG given my deferral of this document to this telechat.

Thanks for resolving my COMMENTs and DISCUSS feedback.

I am deeply conflicted on this ballot -- I was planning on Abstaining, but the document needs more "Yes" or "No Objection" ballots to pass, and so I'm balloting No Objection.

My unease comes not from the document itself (which I view as well written, correct, and complete), but rather because I'm concerned that people will assume that this actually "solves" the differentiated access issues. The technical mechanism itself works (and works well!), but relies on creation of a federation which has very poorly defined parameters. 
These are not issues with the document itself, but rather a set of external policy and political issues -- and I don't see how they can be solved...

So, while I'm concerned that people will mis-interpret what this document does, the document itself is good, and so I'm balloting NoObj....

Thank you very much to the authors and WG for the work - please don't interpret my unease as being with your work...

# Éric Vyncke, INT AD, comments for draft-ietf-regext-rdap-openid-25

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nits.

Special thanks to Zaid AlBanna for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Long lines

The text contains several long URL folded in two lines and it seems that RFC 8792 is not used to represent those folded URL (this may be a user agent issue though).

## Federated ?

Is this really about "federated authentication" or simply to "OpenID" ?

## Section 1.2

s/by a recognized provider/by a trusted identity provider/?

Please provide a reference to OpenID at first use.

## Section 3

Isn't mentioning 'access control' in a list that also includes 'identity, authentication, and authorization' a repetition ? Or does 'access control' covers more ?

## Section 3.1.3

The reader will probably wonder about the choice of 'farv1' name... Explain it :-) (guessing federated authentication rdap).

## Section 3.1.5.1

Should part of this section be more relevant in the IANA considerations section 9.3 ?

## Section 3.1.5.2

Isn't the 'do not track' feature inherently relying on the good will of the RDAP server (and associated proxies)? I suggest to mention this part in section 11 (security considerations)

## Section 10

While I appreciate that the author is clear about the non-compatibility of implementations of pre-09, I find strange (or even confusing) to list two incompatible implementations. 

# NITS

## Abstract

s/access control decisions/access-control decisions/ ?

# GEN AD review of draft-ietf-regext-rdap-openid-25

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/mS2UefXapDTAjcRYHkcT0-sP7WY).

## Comments

### Section 1.2, paragraph 0
```
  1.2.  Proposal
```
Should this section be re-titled now this is being published as an RFC?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`
 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### URLs

These URLs in the document did not return content:

 * https://testprovider.rdap.verisignlabs.com/
 * https://auth.viagenie.ca
 * https://rdap.verisignlabs.com/

These URLs in the document can probably be converted to HTTPS:

 * http://openid.net/specs/openid-connect-discovery-1_0.html
 * http://openid.net/specs/openid-connect-registration-1_0.html
 * http://curl.haxx.se/
 * http://openid.net/connect/
 * http://www.verisignlabs.com/
 * http://openid.net/specs/openid-connect-core-1_0.html

### Grammar/style

#### Section 5.3, paragraph 5
```
ely, an RDAP server MAY attempt to logout from the OP using the "OpenID Conn
                                   ^^^^^^
```
Did you mean the verb "log out" instead of the noun "logout"?

#### Section 6.1, paragraph 1
```
sues, DNS resolution failures, and web site functional issues. -----END FORM-
                                   ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 6.4, paragraph 1
```
f use cases around informing the general public. -----END FORM----- 10. Imple
                                 ^^^^^^^^^^^^^^
```
Consider using only "public" to avoid wordiness.

#### Section 9.3, paragraph 4
```
te for a fully authorized client. Currently supported identity providers incl
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool