[regext] I-D Action: draft-ietf-regext-rdap-openid-24.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Registration Protocols
Extensions (REGEXT) WG of the IETF.

   Title   : Federated Authentication for the Registration Data Access 
Protocol (RDAP) using OpenID Connect
   Author  : Scott Hollenbeck
   Filename: draft-ietf-regext-rdap-openid-24.txt
   Pages   : 49
   Date: 2023-08-18

Abstract:
   The Registration Data Access Protocol (RDAP) provides "RESTful" web
   services to retrieve registration metadata from domain name and
   regional internet registries.  RDAP allows a server to make access
   control decisions based on client identity, and as such it includes
   support for client identification features provided by the Hypertext
   Transfer Protocol (HTTP).  Identification methods that require
   clients to obtain and manage credentials from every RDAP server
   operator present management challenges for both clients and servers,
   whereas a federated authentication system would make it easier to
   operate and use RDAP without the need to maintain server-specific
   client credentials.  This document describes a federated
   authentication system for RDAP based on OpenID Connect.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-24

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-openid-24

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Hollenbeck, Scott]

From: Murray S. Kucherawy 
Sent: Friday, August 18, 2023 1:54 AM
To: Hollenbeck, Scott 
Cc: regext@ietf.org; AlBanna, Zaid ; 
regext-cha...@ietf.org
Subject: [EXTERNAL] Re: [regext] Publication has been requested for 
draft-ietf-regext-rdap-openid-23



[SAH] [snip]



Sounds good.  Thanks for working through all this with me.  I'll send this to 
Last Call when the new version goes up.

[SAH] -24 was just submitted. Thanks for the review feedback!

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-redacted-13

[Gould, James]

Murray,

Thanks for the review.  My feedback is included embedded below.  We can post 
draft-ietf-regext-rdap-redacted-14 once you agree with the needed updates.

Thanks,

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of "Murray S. Kucherawy" 

Date: Saturday, August 12, 2023 at 7:38 PM
To: "regext@ietf.org" 
Cc: "a...@hxr.us" , Gustavo Lozano , 
"regext-cha...@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Publication has been requested for 
draft-ietf-regext-rdap-redacted-13

AD evaluation:
Thanks, Andy, for a good shepherd writeup.  It would be helpful, even if it 
seems redundant or obvious, to include an answer to the question about why 
Proposed Standard is the right status for this document.

The first paragraph of Section 3 is a bit confusing; it says you MUST NOT use 
any placeholder text as a replacement for a redacted value, and then I read the 
next sentence to suggest that there might actually be valid replacement 
placeholder text although it might not conform to the expected syntax.  But on 
a second read, I think you're telling me that the reason it's MUST NOT is 
because there could be a syntax mismatch which could upset parsers.  If that's 
correct, I suggest combining the sentences with "because" or "since".

JG – You are correct, the format mismatch is one reason for the MUST NOT.  The 
sentences can be combined to read:

“The use of placeholder text for the values of the RDAP fields, such as the 
placeholder text "", MUST NOT be used for redaction, since the placeholder 
text value may not match the format requirements of each of the RDAP fields and 
provides an inconsistent and unreliable redaction signal.”

In Section 3.2, why are these two SHOULDs not MUSTs?  What's the choice being 
offered here, and what guidance should we provide?  Same question for the one 
in Section 3.3.

JG – I don’t see an issue with changing the SHOULDs in Section 3.2 to MUSTs, 
since I don’t see a good alternative approach to what is defined in the draft.

Doesn't the method of Section 3.4 directly conflict with the MUST NOT in 
Section 3 (referenced above)?

JG – No, since the replace value is not pre-defined placeholder text that meant 
to signal redaction, such as the use of the placeholder value “REDACTED”.  The 
replacement value provides a proxy to the real value for privacy reasons.  
Technically, it’s not redacted but the redaction extension is used to signal 
that the real value has been replaced for use in visualization or processing by 
the client.

Also in Section 3.4, s/alternate/alternative/

JG – Thanks, that will be addressed.

In Section 4.2, for "prePath" and "postPath", this is a JSON path expression, 
not a JSON expression, correct?

JG – Yes, you are correct, it is referred to as a JSON path expression with the 
“pathLang”.  We can replace the references of “JSON expression” with “JSON path 
expression”.

In Section 6.2, I suggest being precise: You're talking about the "RDAP JSON 
Values" registry.

JG – Yes, it is represented as the “RDAP JSON Values” registry in IANA 
(https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml), but 
Section 10.2 of RFC 9083 is titled “JSON Values Registry”.  We can change the 
reference to “RDAP JSON Values Registry” instead of “JSON Values Registry” if 
that is better.

Thanks for including Section 7.

-MSK, ART AD



On Mon, Aug 7, 2023 at 7:24 AM James Galvin via Datatracker 
mailto:nore...@ietf.org>> wrote:
James Galvin has requested publication of draft-ietf-regext-rdap-redacted-13 as 
Proposed Standard on behalf of the REGEXT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[James Galvin]

My understanding of this thread so far is that the consensus is moving 
towards allowing for the collection of two email addresses.  I very much 
support this position.


One question I don’t believe we have answered carefully is what it 
means to have both email addresses present or just the internationalized 
email address present.  I have a suggestion to consider.



First, I would propose that the specification state if an 
internationalized email address is present it is required and presumed 
to be functionally equivalent to the baseline email address (whether it 
is present or not).  Whether or not this requirement can be validated is 
outside the scope of this specification.  The extension may be present 
for (subordinate to?) to any existing email address element.


What this gets us is that we don’t have to say what that functionality 
is precisely.  Whatever context in which the EPP protocol is being used 
has a defined purpose for the presence of an email address.  All this 
extension has to say is that whatever the purpose (functional 
requirement) of an email address is, either email address is presumed to 
serve that purpose.


With that, I think the 4 possible cases are pretty straightforward to 
explain.


1. only US-ASCII present - this is covered by the base spec so nothing 
to add here.


2. extension present with a value, no value in the US-ASCII element - 
this is also covered by the base spec since the value present is just 
treated exactly as an email address, just with an expanded syntax.  The 
value can be provided to any client whenever an email address is 
requested because clients SHOULD ignore any extension they do not 
understand.


3. both US-ASCII present and extension present with a value - in this 
case the email addresses are presumed to be functionally equivalent, the 
syntax of each is validated, both are stored by the server, and both are 
always provided whenever an email address is included in a response.  
This works because clients can ignore the extension if they don’t 
understand it.


4. extension present with no value - at the protocol level this should 
be ignored.



That is my suggestion.  The critical point there is the protocol 
presumes functional equivalence.  Conceptually, we are sticking to the 
model of a single email address and simply expanding the syntax.  Some 
day, if we ever seek to update or replace EPP we might do this entirely 
differently.  However, this gets us what we need within the model that 
we have.


Jim



On 8 Aug 2023, at 16:03, Dmitry Belyavsky wrote:


Dear Arnt,

On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen, 
wrote:


Thursday, 3 August 2023 20:14:41 CEST writes:
On Thu, Aug 3, 2023 at 1:23 PM Gould, James  
wrote:


So, rollback to draft-ietf-regext-epp-eai-17 with the concept
of a transition period removed and inclusion of "at least one
of the email values MUST be an ASCII address"?


Doesn't that put us back to requiring two email addresses to support 
EAI?


I was thinking that "if more than one email value is provided, one
MUST be an ASCII address". Therefore the options are:
1) provide an ASCII email address.
2) provide an SMTPUTF8 email address.
3) provide both


There is, of course, the possibility of a hack... "At least one of 
the
contact addresses MUST be an ASCII address. This restriction may be 
lifted

in a future revision of this document."


The draft will still need text such as provided by Arnt to justify

option 2.


And I agree with removing the transition period.


I'll be happy to provide suitable text. Massaging what I wrote to fit 
the

context.



It would be great, many thanks in advance!



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[Gould, James]

Jim,

This moves the protocol too far into policy.  Let policy define when an ASCII 
email is needed.  Based on the back-and-forth with this draft, I believe it’s 
best just to add support for an extra e-mail address field, where both the 
existing and the additional email can be either an ASCII or an SMTPUTF8 address 
that is up to server policy.  Any other rules spelled out in the draft is 
policy that is out of scope for the protocol.  The fact that we can’t come to 
agreement on whether there must be an ASCII email address eternally, there must 
be an ASCII email address during a transition period, or an ASCII email address 
is optional provides the indication that we are defining policy and not 
protocol.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: James Galvin 
Date: Friday, August 18, 2023 at 2:27 PM
To: Dmitry Belyavsky 
Cc: Arnt Gulbrandsen , Andrew Newton , 
James Gould , "Hollenbeck, Scott" 
, regext 
Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai


My understanding of this thread so far is that the consensus is moving towards 
allowing for the collection of two email addresses. I very much support this 
position.

One question I don’t believe we have answered carefully is what it means to 
have both email addresses present or just the internationalized email address 
present. I have a suggestion to consider.


First, I would propose that the specification state if an internationalized 
email address is present it is required and presumed to be functionally 
equivalent to the baseline email address (whether it is present or not). 
Whether or not this requirement can be validated is outside the scope of this 
specification. The extension may be present for (subordinate to?) to any 
existing email address element.

What this gets us is that we don’t have to say what that functionality is 
precisely. Whatever context in which the EPP protocol is being used has a 
defined purpose for the presence of an email address. All this extension has to 
say is that whatever the purpose (functional requirement) of an email address 
is, either email address is presumed to serve that purpose.

With that, I think the 4 possible cases are pretty straightforward to explain.

1. only US-ASCII present - this is covered by the base spec so nothing to add 
here.

2. extension present with a value, no value in the US-ASCII element - this is 
also covered by the base spec since the value present is just treated exactly 
as an email address, just with an expanded syntax. The value can be provided to 
any client whenever an email address is requested because clients SHOULD ignore 
any extension they do not understand.

3. both US-ASCII present and extension present with a value - in this case the 
email addresses are presumed to be functionally equivalent, the syntax of each 
is validated, both are stored by the server, and both are always provided 
whenever an email address is included in a response. This works because clients 
can ignore the extension if they don’t understand it.

4. extension present with no value - at the protocol level this should be 
ignored.


That is my suggestion. The critical point there is the protocol presumes 
functional equivalence. Conceptually, we are sticking to the model of a single 
email address and simply expanding the syntax. Some day, if we ever seek to 
update or replace EPP we might do this entirely differently. However, this gets 
us what we need within the model that we have.

Jim


On 8 Aug 2023, at 16:03, Dmitry Belyavsky wrote:
Dear Arnt,
On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen, 
mailto:a...@gulbrandsen.priv.no>> wrote:
Thursday, 3 August 2023 20:14:41 CEST writes:
> On Thu, Aug 3, 2023 at 1:23 PM Gould, James 
> mailto:jgo...@verisign.com>> wrote:
>>
>> So, rollback to draft-ietf-regext-epp-eai-17 with the concept
>> of a transition period removed and inclusion of "at least one
>> of the email values MUST be an ASCII address"?
>
> Doesn't that put us back to requiring two email addresses to support EAI?
>
> I was thinking that "if more than one email value is provided, one
> MUST be an ASCII address". Therefore the options are:
> 1) provide an ASCII email address.
> 2) provide an SMTPUTF8 email address.
> 3) provide both

There is, of course, the possibility of a hack... "At least one of the
contact addresses MUST be an ASCII address. This restriction may be lifted
in a future revision of this document."

> The draft will still need text such as provided by Arnt to justify option 2.
>
> And I agree with removing the transition period.

I'll be happy to provide suitable text. Massaging what I wrote to fit the
context.

It would be great, many thanks in advance!

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[James Galvin]

I’m not following Jim.

My proposal is simply to state what it means in the protocol when an 
internationalized email address extension is present. My proposal is not 
to say when an internationalized email address extension is required.


Stating the presumption of functional equivalence is making it clear we 
are not changing the semantics of EPP, i.e., we are precisely not 
opening the discussion of policy.  To frame this more concretely, a 
contact object semantically in EPP has a single email address, and even 
if syntactically two are present they are semantically the same thing.


Please help me understand how this is a policy statement?

Jim


On 18 Aug 2023, at 14:39, Gould, James wrote:


Jim,

This moves the protocol too far into policy.  Let policy define when 
an ASCII email is needed.  Based on the back-and-forth with this 
draft, I believe it’s best just to add support for an extra e-mail 
address field, where both the existing and the additional email can be 
either an ASCII or an SMTPUTF8 address that is up to server policy.  
Any other rules spelled out in the draft is policy that is out of 
scope for the protocol.  The fact that we can’t come to agreement on 
whether there must be an ASCII email address eternally, there must be 
an ASCII email address during a transition period, or an ASCII email 
address is optional provides the indication that we are defining 
policy and not protocol.


--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: James Galvin 
Date: Friday, August 18, 2023 at 2:27 PM
To: Dmitry Belyavsky 
Cc: Arnt Gulbrandsen , Andrew Newton 
, James Gould , "Hollenbeck, Scott" 
, regext 
Subject: [EXTERNAL] Re: [regext] Proposed update to 
draft-ietf-regext-epp-eai



My understanding of this thread so far is that the consensus is moving 
towards allowing for the collection of two email addresses. I very 
much support this position.


One question I don’t believe we have answered carefully is what it 
means to have both email addresses present or just the 
internationalized email address present. I have a suggestion to 
consider.



First, I would propose that the specification state if an 
internationalized email address is present it is required and presumed 
to be functionally equivalent to the baseline email address (whether 
it is present or not). Whether or not this requirement can be 
validated is outside the scope of this specification. The extension 
may be present for (subordinate to?) to any existing email address 
element.


What this gets us is that we don’t have to say what that 
functionality is precisely. Whatever context in which the EPP protocol 
is being used has a defined purpose for the presence of an email 
address. All this extension has to say is that whatever the purpose 
(functional requirement) of an email address is, either email address 
is presumed to serve that purpose.


With that, I think the 4 possible cases are pretty straightforward to 
explain.


1. only US-ASCII present - this is covered by the base spec so nothing 
to add here.


2. extension present with a value, no value in the US-ASCII element - 
this is also covered by the base spec since the value present is just 
treated exactly as an email address, just with an expanded syntax. The 
value can be provided to any client whenever an email address is 
requested because clients SHOULD ignore any extension they do not 
understand.


3. both US-ASCII present and extension present with a value - in this 
case the email addresses are presumed to be functionally equivalent, 
the syntax of each is validated, both are stored by the server, and 
both are always provided whenever an email address is included in a 
response. This works because clients can ignore the extension if they 
don’t understand it.


4. extension present with no value - at the protocol level this should 
be ignored.



That is my suggestion. The critical point there is the protocol 
presumes functional equivalence. Conceptually, we are sticking to the 
model of a single email address and simply expanding the syntax. Some 
day, if we ever seek to update or replace EPP we might do this 
entirely differently. However, this gets us what we need within the 
model that we have.


Jim


On 8 Aug 2023, at 16:03, Dmitry Belyavsky wrote:
Dear Arnt,
On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen, 
mailto:a...@gulbrandsen.priv.no>> wrote:

Thursday, 3 August 2023 20:14:41 CEST writes:
On Thu, Aug 3, 2023 at 1:23 PM Gould, James 
mailto:jgo...@verisign.com>> wrote:


So, rollback to draft-ietf-regext-epp-eai-17 with the concept
of a transition period removed and inclusion of "at least one
of the email values MUST be an ASCII address"?


Doesn't that put us back to requiring two email addresses to support 
EAI?


I was thinking that "if more than one email value is provided, one
MUST be an ASCII add

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[Gould, James]

Jim,

I believe defining functional equivalence between an ASCII and SMPTUTF8 address 
is policy and not protocol.  EPP is a provisioning protocol that enables a 
client (registrar) to create and update email addresses in a server (registry), 
where the protocol simply needs to be capable of passing either ASCII or 
SMPTUTF8 addresses.  If a server defines a policy that requires an alternative 
address (ASCII, SMPTUTF8, or either one), then they can do so using the 
extension that supports the policy in the protocol.  My desire is to keep this 
simple and not venture into the policy pandora’s box.  My proposal is to roll 
things back to draft-ietf-regext-epp-eai-17, remove any reference to the 
requirement for an ASCII email address, and remove the concept of a transition 
period.  Leave the decision up to server policy what combination of email 
addresses to allow.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: James Galvin 
Date: Friday, August 18, 2023 at 2:50 PM
To: James Gould 
Cc: "beld...@gmail.com" , "a...@gulbrandsen.priv.no" 
, "a...@hxr.us" , "Hollenbeck, Scott" 
, "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I’m not following Jim.

My proposal is simply to state what it means in the protocol when an 
internationalized email address extension is present. My proposal is not to say 
when an internationalized email address extension is required.

Stating the presumption of functional equivalence is making it clear we are not 
changing the semantics of EPP, i.e., we are precisely not opening the 
discussion of policy. To frame this more concretely, a contact object 
semantically in EPP has a single email address, and even if syntactically two 
are present they are semantically the same thing.

Please help me understand how this is a policy statement?

Jim


On 18 Aug 2023, at 14:39, Gould, James wrote:
Jim,

This moves the protocol too far into policy.  Let policy define when an ASCII 
email is needed.  Based on the back-and-forth with this draft, I believe it’s 
best just to add support for an extra e-mail address field, where both the 
existing and the additional email can be either an ASCII or an SMTPUTF8 address 
that is up to server policy.  Any other rules spelled out in the draft is 
policy that is out of scope for the protocol.  The fact that we can’t come to 
agreement on whether there must be an ASCII email address eternally, there must 
be an ASCII email address during a transition period, or an ASCII email address 
is optional provides the indication that we are defining policy and not 
protocol.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: James Galvin 
Date: Friday, August 18, 2023 at 2:27 PM
To: Dmitry Belyavsky 
Cc: Arnt Gulbrandsen , Andrew Newton , 
James Gould , "Hollenbeck, Scott" 
, regext 
Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai


My understanding of this thread so far is that the consensus is moving towards 
allowing for the collection of two email addresses. I very much support this 
position.

One question I don’t believe we have answered carefully is what it means to 
have both email addresses present or just the internationalized email address 
present. I have a suggestion to consider.


First, I would propose that the specification state if an internationalized 
email address is present it is required and presumed to be functionally 
equivalent to the baseline email address (whether it is present or not). 
Whether or not this requirement can be validated is outside the scope of this 
specification. The extension may be present for (subordinate to?) to any 
existing email address element.

What this gets us is that we don’t have to say what that functionality is 
precisely. Whatever context in which the EPP protocol is being used has a 
defined purpose for the presence of an email address. All this extension has to 
say is that whatever the purpose (functional requirement) of an email address 
is, either email address is presumed to serve that purpose.

With that, I think the 4 possible cases are pretty straightforward to explain.

1. only US-ASCII present - this is covered by the base spec so 

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Murray S. Kucherawy]

On Fri, Aug 18, 2023 at 7:38 AM Hollenbeck, Scott 
wrote:

>
>
> *From:* Murray S. Kucherawy 
> *Sent:* Friday, August 18, 2023 1:54 AM
> *To:* Hollenbeck, Scott 
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication has been requested for
> draft-ietf-regext-rdap-openid-23
>
>
>
> *[SAH] *[snip]
>
>
>
> Sounds good.  Thanks for working through all this with me.  I'll send this
> to Last Call when the new version goes up.
>
> *[SAH] -24 was just submitted. Thanks for the review feedback!*
>

Last call requested.

-MSK
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-redacted-13

[Murray S. Kucherawy]

Thanks, this all looks good.  I'll send it to Last Call when a new version
appears.

-MSK

On Fri, Aug 18, 2023 at 7:48 AM Gould, James  wrote:

> Murray,
>
>
>
> Thanks for the review.  My feedback is included embedded below.  We can
> post draft-ietf-regext-rdap-redacted-14 once you agree with the needed
> updates.
>
>
>
> Thanks,
>
>
>
> --
>
>
>
> JG
>
>
> [image: cid87442*image001.png@01D960C5.C631DA40]
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *regext  on behalf of "Murray S.
> Kucherawy" 
> *Date: *Saturday, August 12, 2023 at 7:38 PM
> *To: *"regext@ietf.org" 
> *Cc: *"a...@hxr.us" , Gustavo Lozano <
> gustavo.loz...@icann.org>, "regext-cha...@ietf.org" <
> regext-cha...@ietf.org>
> *Subject: *[EXTERNAL] Re: [regext] Publication has been requested for
> draft-ietf-regext-rdap-redacted-13
>
>
>
> AD evaluation:
>
> Thanks, Andy, for a good shepherd writeup.  It would be helpful, even if
> it seems redundant or obvious, to include an answer to the question about
> why Proposed Standard is the right status for this document.
>
>
>
> The first paragraph of Section 3 is a bit confusing; it says you MUST NOT
> use any placeholder text as a replacement for a redacted value, and then I
> read the next sentence to suggest that there might actually be valid
> replacement placeholder text although it might not conform to the expected
> syntax.  But on a second read, I think you're telling me that the reason
> it's MUST NOT is because there could be a syntax mismatch which could upset
> parsers.  If that's correct, I suggest combining the sentences with
> "because" or "since".
>
>
>
> JG – You are correct, the format mismatch is one reason for the MUST NOT.
> The sentences can be combined to read:
>
>
>
> “The use of placeholder text for the values of the RDAP fields, such as
> the placeholder text "", MUST NOT be used for redaction, since the
> placeholder text value may not match the format requirements of each of the
> RDAP fields and provides an inconsistent and unreliable redaction signal.”
>
>
>
> In Section 3.2, why are these two SHOULDs not MUSTs?  What's the choice
> being offered here, and what guidance should we provide?  Same question for
> the one in Section 3.3.
>
>
>
> JG – I don’t see an issue with changing the SHOULDs in Section 3.2 to
> MUSTs, since I don’t see a good alternative approach to what is defined in
> the draft.
>
>
>
> Doesn't the method of Section 3.4 directly conflict with the MUST NOT in
> Section 3 (referenced above)?
>
>
>
> JG – No, since the replace value is not pre-defined placeholder text that
> meant to signal redaction, such as the use of the placeholder value
> “REDACTED”.  The replacement value provides a proxy to the real value for
> privacy reasons.  Technically, it’s not redacted but the redaction
> extension is used to signal that the real value has been replaced for use
> in visualization or processing by the client.
>
>
>
> Also in Section 3.4, s/alternate/alternative/
>
>
>
> JG – Thanks, that will be addressed.
>
>
>
> In Section 4.2, for "prePath" and "postPath", this is a JSON path
> expression, not a JSON expression, correct?
>
>
>
> JG – Yes, you are correct, it is referred to as a JSON path expression
> with the “pathLang”.  We can replace the references of “JSON expression”
> with “JSON path expression”.
>
>
>
> In Section 6.2, I suggest being precise: You're talking about the "RDAP
> JSON Values" registry.
>
>
>
> JG – Yes, it is represented as the “RDAP JSON Values” registry in IANA (
> https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml),
> but Section 10.2 of RFC 9083 is titled “JSON Values Registry”.  We can
> change the reference to “RDAP JSON Values Registry” instead of “JSON Values
> Registry” if that is better.
>
>
>
> Thanks for including Section 7.
>
>
>
> -MSK, ART AD
>
>
>
>
>
>
>
> On Mon, Aug 7, 2023 at 7:24 AM James Galvin via Datatracker <
> nore...@ietf.org> wrote:
>
> James Galvin has requested publication of
> draft-ietf-regext-rdap-redacted-13 as Proposed Standard on behalf of the
> REGEXT working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/
> 
>
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Last Call: (Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect) to Proposed Standard

[The IESG]

The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Federated Authentication for
the Registration Data Access Protocol
   (RDAP) using OpenID Connect'
   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
last-c...@ietf.org mailing lists by 2023-09-01. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   The Registration Data Access Protocol (RDAP) provides "RESTful" web
   services to retrieve registration metadata from domain name and
   regional internet registries.  RDAP allows a server to make access
   control decisions based on client identity, and as such it includes
   support for client identification features provided by the Hypertext
   Transfer Protocol (HTTP).  Identification methods that require
   clients to obtain and manage credentials from every RDAP server
   operator present management challenges for both clients and servers,
   whereas a federated authentication system would make it easier to
   operate and use RDAP without the need to maintain server-specific
   client credentials.  This document describes a federated
   authentication system for RDAP based on OpenID Connect.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/



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





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext