Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[kowalik]

Hi James,

Likely I missed this part about splitting in the meeting - sorry for 
that. Can you be more specific? It is the mechanism described in 4.  
Transition Considerations? Shall it be only referring to jscontact or 
contact representation or to any transition of output representations?


Here we also have draft-newton-regext-rdap-x-media-type-01 which would 
fulfil the same purpose, wouldn't it?


Kind Regards,

Pawel


Am 13.11.23 um 16:53 schrieb James Galvin:

Following up from last week’s REGEXT meeting, there was consensus in the room 
that the document:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact-16/

Should be split into two documents: the signaling function and the extension.

The signaling function draft would be put on the standards track and the 
extension draft would be put on the experimental track.

With this message the Chairs are asking the broader working group to confirm 
this action.  If you have questions or concerns please reply to this message by 
Monday, 20 November 2023.  If you need more time please ask on the list and the 
Chairs will consider an extension.

Although we had consensus in the meeting room, the Chairs would appreciate a 
“+1” reply if you agree with this action.

Thanks,

Antoin and Jim

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


smime.p7s
Description: Kryptografische S/MIME-Signatur
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D draft-latour-pre-registration

[kowalik]

Hi Jack,

Skimming through the document I have 3 questions / observations:

1) why you decided to break the flow into 2 commands with create and 
validate? What shall happen afterwards to the object(s) created in the 
first step? In this context the approach in draft-ietf-regext-validate 
to have temporary objects created implicitly with check:validate 
command, even if the process is asynchronous, seems more plausible to me.


2) The draft tells a lot about ML/AI, while actually it can be any type 
of validation. It can be static, rule based or even manual if you wish. 
I would not narrow down the use-case just to ML/AI.


3) Section 8 is for me too deep into policy setting/suggesting and not 
in the area of technical protocol. The protocol shall define whether the 
result is discrete value (with maybe IANA repository) or continuos score 
and the number format, but not going beyond that. Note that the same 
protocol could be also used for other purposes other than abuse, like 
eligibility check based on other criteria.


Kind regards,

Pawel

Am 15.11.23 um 16:56 schrieb Jacques Latour:


Hi all,

At the ICANN78 meeting and other venues, there were quite a lot of 
discussion on AI/ML abuse detection related discussions and presentations.


  * Example:

https://static.sched.com/hosted_files/icann78/de/4%20%2020231023-TechDay-AI%20at%20EURid.pdf

But this is after the fact, after a registration is completed, so we 
thought of a new extension to allow the registrar to ask the registry 
that have this real time capabilities to analyse the pre-registration 
information and return a quality score to better inform the process.


draft-latour-pre-registration-00 - EPP Pre-Registration Verification 
(ietf.org) 



Have a read,

Jack


CLASSIFICATION:CONFIDENTIAL


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

smime.p7s
Description: Kryptografische S/MIME-Signatur
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-jasdips-regext-rdap-geofeed

[kowalik]

I support adoption and I am willing to review.

Pawel

Am 20.11.23 um 15:36 schrieb Antoin Verschuren:

This is a formal adoption request for An RDAP Extension for Geofeed Data:

https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT and comment to this message on the list, clearly stating your view.
Optionally indicate if you are willing to contribute text, review text, or be a 
document shepherd.

This Call For Adoption will close on Monday 4 December.

If there are no objections, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin




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


smime.p7s
Description: Kryptografische S/MIME-Signatur
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] RDAP-X draft adoption

[kowalik]

Hi Jasdip,

Do you mean by adopting RDAP-X draft the WG shall include the 
requirements of all the said drafts when it comes to extensions and 
versions signalling and negotiation, or only keep the current scope and 
define extension points so that the other drafts can be based on the 
same method?


Some of those requirements, not yet covered by RDAP-X:

- Versioning and JSContact have requirements included for signalling 
when certain extensions/versions start/end being available.


- Versioning introduces all the semantics of versions, which is not 
(yet) existing in the RDAP RFCs where I agree that if introduced shall 
base on the same concepts of content negotiation.


Kind Regards,

Pawel

Am 15.11.23 um 00:26 schrieb Jasdip Singh:


Hello Antoin, Jim,

Given the ongoing discussion on how to negotiate extensions between 
RDAP clients and servers (using HTTP headers versus query parameters), 
be it for SimpleContact [1], JSContact [2], or versioning in RDAP [3], 
Andy and I want to request a call for WG adoption of the RDAP-X draft 
[4]. We believe that the HTTP headers-based approach could help unify 
extensions negotiation across the RDAP ecosystem.


Thanks,

Jasdip & Andy

[1] 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/


[2] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/

[3] https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/

[4] 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/



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

smime.p7s
Description: Kryptografische S/MIME-Signatur
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption

[kowalik]

+1

Am 12.12.23 um 12:14 schrieb Jasdip Singh:


+1

Jasdip

*From: *Mario Loffredo 
*Date: *Tuesday, December 12, 2023 at 3:09 AM
*To: *"Gould, James" , 
"gal...@elistx.com" , Jasdip Singh 
*Cc: *"regext-cha...@ietf.org" , 
"regext@ietf.org" , Andy Newton 

*Subject: *Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption

Agreed.

Mario

Il 11/12/2023 15:24, Gould, James ha scritto:

Jim and Antoin,

I support having an interim meeting to discuss.  I see distinct
problems being solved by the three drafts
draft-gould-regext-rdap-versioning,
draft-newton-regext-rdap-extensions, and
draft-newton-regext-rdap-x-media-type.  I highlight them below to
prime the discussion:

 1. draft-newton-regext-rdap-extensions – Provide clarification of
the creation of RDAP extensions, where we can address much of
the clarification issues that we’ve struggled with on the
mailing list.
 2. draft-newton-regext-rdap-x-media-type – Provide an alternative
mechanism to the use of a query parameter that does not pose
an issue with RDAP redirection servers.
 3. draft-gould-regext-rdap-versioning – Provide support for an
extensible set of RDAP extension versioning types with Opaque
Versioning and Semantic Versioning initially defined that will
work in unison with draft-newton-regext-rdap-extensions and
draft-newton-regext-rdap-x-media-type.

Thanks for catching up on the thread and setting up an interim
meeting.

-- 


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 James Galvin
 
*Date: *Monday, December 11, 2023 at 9:09 AM
*To: *Jasdip Singh  
*Cc: *"regext-cha...@ietf.org" 
 ,
"regext@ietf.org"  
, Andy Newton 

*Subject: *[EXTERNAL] [regext] ACTION REQUESTED: Re: RDAP-X draft
adoption

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

The Chairs have caught up on this thread and have the following
proposal for the working group

We suggest that the working group take on the problem space of
considering negotiation, signaling, and versioning in RDAP.

To properly consider this problem space we should adopt as working
group documents the following three drafts, all of which address
at least part of this problem space:

https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/


(-02 just posted)
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/



https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/



In general, our goal as a working group is to have one solution on
the standards track to a problem. After we have adopted these
documents the working group will have to answer at least two
questions:

1. Is there one problem to be solved or more than one?
2. Is there one solution or, if there are multiple problems, do we
need multiple solutions?

These are technical questions based on use cases that have been
discussed. The Chairs also suggest that we have an interim
meeting, perhaps in late January or early February, during which
we have a focused discussion

Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp

[kowalik]

Hi,

I support the adoption.

I think this is the right group to work on this issue, however a close 
sync and thorough review by dnsop shall be assured.


One comment/question to the document: my understanding is that it 
presents a mix of existing and not yet existing or proposed new 
practices for handling of the issue. Chapter 5 is not specific in the 
respect which methods are existing and which are proposed. Only chapter 
6 makes it more clear, at least for those methods proposed as best practice.


Also, are methods 5.2.2.4. and 5.2.2.5. already covered in the existing 
EPP specifications, or new extensions are required to cover them?


Kind Regards,

Pawel

On 29.01.24 16:17, Antoin Verschuren wrote:

This is the formal adoption request for Best Practices for Deletion of Domain 
and Host Objects in the Extensible Provisioning Protocol (EPP):

https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT and comment to this message on the list, clearly stating your view.
Andy Newton already volunteered to be a document shepherd this item will be 
adopted.

This Call For Adoption will close on Monday 12 February.

If there are no objections, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-gould-regext-rdap-versioning draft-newton-regext-rdap-extensions draft-newton-regext-rdap-x-media-type

[kowalik]

+1

On 05.02.24 15:37, James Galvin wrote:

This is the formal adoption request for the following package of Internet 
Drafts:

Versioning in the Registration Data Access Protocol (RDAP)
https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/

RDAP Extensions
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/

An RDAP With Extensions Media Type
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/


Please review these drafts to see if you think they are suitable for adoption 
by REGEXT and comment to this message on the list, clearly stating your view.

This Call For Adoption will close on Monday, 19 February.

If there are no objections, the chairs will consider these documents adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[kowalik]

Hi Scott,

On 20.03.24 05:56, Hollenbeck, Scott wrote:

-Original Message-
From: Francisco Obispo
Sent: Wednesday, March 20, 2024 12:32 AM
To: Hollenbeck, Scott
Cc:regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery


This is a neat idea,

Is there a reasoning or use case for such need?

[SAH] [snip]

During today's WG meeting we discussed three proposals for non-TCP EPP 
transport. If any of them become standards and are implemented and deployed, a 
client will not be able to assume that tcp/700 is the only available transport. 
It will need to discover which transport is supported by every server it 
communicates with. That's the need.


[PK] I think the registries are pretty good these days in communicating 
such changes to their registrars *at the point in time of new feature 
introduction*. If a registrar would like to switch on a new transport at 
a later stage, when say X registries already offer it, it would have no 
other choice than digging through documentation of all of them 
(including those not yet supporting). So I see some use of a discovery 
at some point.


There is also discovery of other features built in EPP, like extensions 
supported, but I would be interested what is the current practice - 
would registrar automatically start using an extension just because it 
got announced? My past experience is that anyway it is off-band + read 
the doc.


But having a repository to refer to similar to RDAP may be useful for 
the first use case I outlined. But I don't have super strong feelings 
about it. There is no such repository for EPP server addresses and it 
seems to be no problem.


Kind Regards,

Pawel


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Re-chartering REGEXT?

[kowalik]

Thank you George. This working group should be the venue for such 
discussion and if re-chartering is the only clean way forward I'd be 
also supportive here.


Kind Regards,

Pawel

On 16.04.24 01:14, George Michaelson wrote:

I don't think the new protocol is just a new transport *LAYER* but I
also do support re-charter to include consideration of this protocol
suite.

My reasoning is that we're the people who are going to wind up having
to talk about it. Of course it's irritating from a perspective of RDAP
and EPP proponents to see more work jammed into this WG and I actually
generally dislike charter extension, but the context is clear:

The protocol is in the registry-registrar and client-registrar
interaction space we work on.

G

On Tue, Apr 16, 2024 at 3:37 AM Gould, James
 wrote:

Andy,

REPP is not a transport, but a new provisioning protocol that is not supported 
in the existing charter.  If you believe REPP is a transport, please describe 
how it complies with section 2.1 of RFC 5730.

Thanks,

--

JG



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


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

Verisign.com 




On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)" mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us > wrote:


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.


Maarten,


I think proposing some charter text is a good idea.


And I support this if the charter is to be used to exclude some
proposals for EPP transports but not others, as has been argued.


-andy


On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink
mailto:40sidn...@dmarc.ietf.org>> 
wrote:

Hello everyone,

The REGEXT WG charter seems to be limited to only allow work on EPP extensions?

The WG preliminary consensus is that updating the charter for new transports 
(requires RFC5730, sec 2.1 compliance) is not required.
Because a new transport is regarded as a type of extension, so for anything 
else we would need to update the charter?

This means there is no defined process anywhere, currently, for EPP related 
work, such as RESTful EPP (or anything else that is not a extension),
which according to some in this WG is not a transport but something else.

RESTful EPP does not require modification of the EPP RFCs, it does include 
support for alternative data representations such as JSON.

The participants of this WG are the experts in this area, and the right people 
to also work on improvements and/or enhancements of the EPP protocol and new 
work such as RESTful EPP.

Therefore, I propose that we expand the charter of this WG to also include the 
above-mentioned activities e.g. not strictly limiting the WG to extensions only.

I’m willing to help in updating the charter if this something we agree on doing.

Best,

Maarten

--
ps:

The previous version of the charter included text, that did allow work on more 
than extensions only:

“The working group may also, in consultation with its responsible area
director, take on work related to the operation of Internet identifier
registries, beyond the EPP and RDAP protocols.”

See: 
https://secure-web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAONiX2WujSy1_vkXH6R3dC-XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y39QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4p0HCiWXl_U-V5l_hWGXcSEavgzX-crhYmdNvhH-u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6Xw63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F
 


This was modified for the current charter, but still not very specific and may 
allow for work on RESTful EPP?

"The working group may also take on work to develop specifications that
describe the following types of information exchanged between entities
involved in Internet identifier registration that are using the RDAP or
EPP protocols:
• Uniform representation formats for publishing local policy or
configuration options regarding EPP and RDAP use.
• Data formats for files exchanged between registration entities that
need insertion in or extraction from EPP or RDAP.
• Technical guidance for registration processes that are supported by
EPP or RDAP.”


___
regext mailing list
regext@ietf.org 
https://secure-web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakvQ61DRHxQLVjdwPbxzo5BV1i

Re: [regext] Re-chartering REGEXT?

[kowalik]

Hi Mario,

On 16.04.24 09:39, Mario Loffredo wrote:
However, let me just say that it appears a bit inconsistent to me that 
we have almost finished to turn RDAP from stateless into stateful and 
we are now planning to start a discussion about how to make EPP to go 
opposite !?!


You mean the "session" variant of draft-ietf-regext-rdap-openid? I would 
not name it "turning RDAP into stateful". First there is a token variant 
which is same stateless as REPP can be, second it's an extension, which 
optionally extends the protocol not fundamentally changes it.


And one addition, as Maarten mentioned REPP does not have an intention 
to make changes to the base EPP, so even if REPP would be stateless it 
should not mean that we turn EPP to stateless by doing that.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Re-chartering REGEXT?

[kowalik]

+1.

Even better if this milestone and discussion would be possible to take 
place within the current charter or within the re-chartering process.


Kind Regards,

Pawel


On 16.04.24 17:12, Marc Blanchet wrote:

It appears to me that we are putting the carriage before the horse in this 
discussion. I would suggest to write a milestone like “a RESTy EPP” but not too 
much details to leave room for what it will finally be, and leave the 
discussion on how it is implemented,  how much it is really an EPP transport or 
not, to the wg mailing list, meetings, and documents.

Regards, Marc.


Le 16 avr. 2024 à 11:02, Hollenbeck, Scott 
 a écrit :

I think there's a basic question to be answered first: what's the goal?

If the answer is "a RESTful API for EPP", it might be possible to do that 
within the confines of the existing charter if it can be done without changing any of the 
existing core EPP RFCs. There's an old axiom about the IETF not standardizing APIs, but 
we've already done RDAP. Maybe this is similar.

If the answer is "specify a web service that's EPP-ish", I agree that 
rechartering is probably necessary.

Scott


-Original Message-
From: regext  On Behalf Of George Michaelson
Sent: Monday, April 15, 2024 7:15 PM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Re-chartering REGEXT?

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 don't think the new protocol is just a new transport *LAYER* but I also do
support re-charter to include consideration of this protocol suite.

My reasoning is that we're the people who are going to wind up having to talk
about it. Of course it's irritating from a perspective of RDAP and EPP
proponents to see more work jammed into this WG and I actually generally
dislike charter extension, but the context is clear:

The protocol is in the registry-registrar and client-registrar interaction 
space we
work on.

G

On Tue, Apr 16, 2024 at 3:37 AM Gould, James
 wrote:

Andy,

REPP is not a transport, but a new provisioning protocol that is not

supported in the existing charter.  If you believe REPP is a transport, please
describe how it complies with section 2.1 of RFC 5730.

Thanks,

--

JG



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

B4BA42740803/jgould@Verisign.c

om>

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

Verisign.com





On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)"

mailto:regext-boun...@ietf.org> on behalf of
a...@hxr.us > wrote:


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.


Maarten,


I think proposing some charter text is a good idea.


And I support this if the charter is to be used to exclude some
proposals for EPP transports but not others, as has been argued.


-andy


On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink

> wrote:

Hello everyone,

The REGEXT WG charter seems to be limited to only allow work on EPP

extensions?

The WG preliminary consensus is that updating the charter for new

transports (requires RFC5730, sec 2.1 compliance) is not required.

Because a new transport is regarded as a type of extension, so for anything

else we would need to update the charter?

This means there is no defined process anywhere, currently, for EPP
related work, such as RESTful EPP (or anything else that is not a extension),

which according to some in this WG is not a transport but something else.

RESTful EPP does not require modification of the EPP RFCs, it does include

support for alternative data representations such as JSON.

The participants of this WG are the experts in this area, and the right people

to also work on improvements and/or enhancements of the EPP protocol and
new work such as RESTful EPP.

Therefore, I propose that we expand the charter of this WG to also include

the above-mentioned activities e.g. not strictly limiting the WG to extensions
only.

I’m willing to help in updating the charter if this something we agree on

doing.

Best,

Maarten

--
ps:

The previous version of the charter included text, that did allow work on

more than extensions only:

“The working group may also, in consultation with its responsible
area director, take on work related to the operation of Internet
identifier registries, beyond the EPP and RDAP protocols.”

See:
https://secure-

web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8i

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[kowalik]

Hi,

I think the issue of JSONPath not being easy/possible to interpret in 
case of removed paths was brought up on the mailing list and the 
conclusion was to key off the "redacted name" rather than base on 
JSONPath [1].


This is also what has been covered in 5.1.1 with a clear recommendation 
for the client implementers. Not enough?


[1] 
https://mailarchive.ietf.org/arch/msg/regext/nP9BZFbwhOkgiMim9s5upRqCYRs/


Kind Regards,

Pawel


On 11.06.24 06:28, Jasdip Singh wrote:


Hi.

It is a bit unfortunate for us as a WG that we missed the fundamental 
shortcomings of the JSONPath usage for redaction, as highlighted in 
the draft below. Especially, the “prePath” portion where a client 
would have no idea about how to apply that expression to the response 
in hand. Though the JSONPath use is optional in RFC 9537, that does 
not help escape the fact that portions of this extension are 
inherently incorrect. Not sure what the path forward is from here but 
IMO it would help to address the highlighted issues; either as RFC 
9537 bis, or an entirely new approach that does not depend on JSONPath.


Jasdip

*From: *Andrew Newton (andy) 
*Date: *Wednesday, May 29, 2024 at 6:51 AM
*To: *regext@ietf.org 
*Subject: *[regext] Fwd: New Version Notification for 
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt


Hi all,

Over the past several months, we have been implementing the RDAP 
redaction extension, RFC 9537.


This I-D describes the issues we have encountered.

-andy



 Forwarded Message 

*Subject: *



New Version Notification for 
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt


*Date: *



Wed, 29 May 2024 03:45:43 -0700

*From: *



internet-dra...@ietf.org

*To: *



Andy Newton  



A new version of Internet-Draft
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt has been
successfully submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-considerations-on-rfc9537
Revision: 00
Title: Considerations on RFC 9537
Date: 2024-05-29
Group: Individual Submission
Pages: 12
URL: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537



Abstract:

This document discusses client implementation issues relating to RFC
9537, “Redacted Fields in the Registration Data Access Protocol
(RDAP) Response”. The considerations in this document have arisen
from problems raised by two separate teams attempting to implement
RFC 9537 in both an RDAP web client and an RDAP command line client.
Some of these problems may be insurmountable, leaving portions of RFC
9537 non-interoperable between clients and servers, while other
problems place a high degree of complexity upon clients.



The IETF Secretariat


___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: [Ext] [Technical Errata Reported] RFC9083 (7985)

[kowalik]

If Figure 28 is not intended to be a full example, then it should likely 
use the "..." notation to indicate that better. This notation is used 
for example in Figure 21 or Figure 25 however it is not consistently 
used in all examples.


Kind regards,

Pawel

On 14.06.24 15:15, Gavin Brown wrote:

Hi Scott,


On 14 Jun 2024, at 13:38, Hollenbeck, Scott  wrote:


-Original Message-
From: Gavin Brown
Sent: Friday, June 14, 2024 8:32 AM
To: Hollenbeck, Scott
Cc:rfc-edi...@rfc-editor.org;a...@hxr.us;superu...@gmail.com;
orie@transmute.industries;gal...@elistx.com;i...@antoin.nl;regext@ietf.org
Subject: [EXTERNAL] Re: [Ext] [Technical Errata Reported] RFC9083 (7985)

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.

Hi Scott,


On 12 Jun 2024, at 17:42, Hollenbeck, Scott

wrote:

I'm inclined to reject this report. The example cited in Figure 28 is described

in the text as a "common response body", not a complete RDAP response. The
error response body is described in the context of a complete RDAP response
in Figure 29, which includes an rdapConformance data structure. As such, the
examples in the two figures are fine as-is.

I'm puzzled by this. What is actually meant by "common response body", and
in what way does the stipulation in Section 4.1 not apply to it?

[SAH] It was intended to describe a set of elements, not a complete response, 
that would be commonly returned to identify an error condition. A complete 
response that includes those elements, and an rdapConformance element, is 
described in the very next figure.

Thanks, this is helpful to understand the intent of the text. My impression now 
is that Figure 28 isn't intended to be an example of a complete error response, 
rather it is intended to illustrate the additional properties that could be 
overlaid on top of a standard RDAP response (which would include 
rdapConformance, notices, etc). Is that correct?


--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[kowalik]

Hi,

In the course of the actual discussion on the clarity of documents we 
produce, especially related to implementation maturity of the solutions 
I would need to repeat the remark I brought up during the call for 
adoption [1].


I think the document, being a BCP, should be very specific about which 
methods have already been field proven and which are kind of 
experimental with unknown implementation or operational impact.


[1] 
https://mailarchive.ietf.org/arch/msg/regext/lDkYhEak6_JehglG-YuqxBpwgrw/


Kind Regards,

Pawel

On 03.06.24 16:56, James Galvin wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Best Current 
Practice:

Best Practices for Deletion of Domain and Host Objects in the Extensible 
Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 17 June 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Andy Newton.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Simple Redaction

[kowalik]

Hi Andy,

Taking into account that this proposal is a result of considerations on 
rfc9537 I think this draft takes the issue too simplified or easy, just 
by removing the difficult part of the problem in rfc9537.


Actually it dictates allowed methods how redaction is done by the 
server, practically eliminating the possibilities foreseen in rfc9537 
which lead to removal of properties, objects or array elements (mainly 
"Redaction by Removal" and one mode of "Redaction by Replacement 
Value"). If you'd remove these methods from rfc9537, you'd actually fix 
the issues with prePath as well because prePath would never occur.


The group consensus was however that these methods exist and are in use 
by the servers, so not taking them into account in rfc9537 would have 
too much of an implication on the servers. This would result in servers 
still doing the same thing (ergo removing properties, objects or array 
elements) and not having a way to signal it.


postPath does not pose such an issue, because even if more than one path 
is selected it is clear which elements of the response have been 
redacted any why. If an overlap happens the client can display both 
reasons fo the redaction.


A feature that your proposal adds is a possibility to mark exactly which 
part of partial redaction have been replaced. It didn't appear to me as 
a goal for rfc9537 to have information specific to that extend, 
especially in an unstructured data. The clients processing such response 
may still mark the whole field as redacted leaving the interpretation to 
the user. If this feature is deemed to be important it can be still 
added on top of rfc953, using a method you've proposed or any other 
suitable mean.


Kind Regards,

Pawel

On 17.06.24 15:12, Andrew Newton (andy) wrote:

Hi all,

I spent some time thinking about how to make the redaction problem 
less complex by focusing on the places where redaction is most likely 
to to be found, in "personal data". Within RDAP, that appears to 
always be conveyed in JSON strings. Reducing the scope reduces the 
complexity, at least in my opinion.


Included is an example with the ICANN redaction policies, which are 
the only published redaction policies that I know of. If others are 
published, please send me a link and I'll see about working up an 
example.


Anyway, I am curious what people think.

-andy



 Forwarded Message 
Subject: New Version Notification for 
draft-newton-regext-rdap-simple-redaction-00.txt

Date: Mon, 17 Jun 2024 05:51:39 -0700
From: internet-dra...@ietf.org
To: Andy Newton 



A new version of Internet-Draft
draft-newton-regext-rdap-simple-redaction-00.txt has been successfully
submitted by Andy Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-simple-redaction
Revision: 00
Title: RDAP Simple Redaction
Date: 2024-06-17
Group: Individual Submission
Pages: 19
URL: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-redaction/
HTML: 
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-redaction-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-redaction



Abstract:

This document defines a simple redaction extension for the
Registration Data Access Protocol (RDAP).



The IETF Secretariat


___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Simple Redaction

[kowalik]

Hi Andy,

On 21.06.24 16:44, Andrew Newton (andy) wrote:


On 6/21/24 09:32, kowa...@denic.de wrote:

Hi Andy,

Taking into account that this proposal is a result of considerations 
on rfc9537 I think this draft takes the issue too simplified or easy, 
just by removing the difficult part of the problem in rfc9537.


If you are saying that this draft is the result of experience with rfc 
9537, I 100% agree. I did not think of it until after realizing that, 
with few exceptions, the redaction methods in 9537 can only apply to 
strings.


I would say otherwise, that rfc 9537 is indeed not very specific what 
some of redaction methods mean if the value is not string (as your draft 
mentioned - what is the empty value of boolean or number) and maybe rfc 
9537 could have been more specific about nonsense or impossible 
combinations, however in my opinion rfc 9537 is enough to describe all 
real life combinations of redaction, so in the end the rest is about 
handling of the cases which will practically never happen. So you may 
say the client won't be wrong no matter what the handling would be.


An errata to rfc 9537 may be helpful make the life easier, indeed 
however I wouldn't name rfc 9537 not possible to implement justifying a 
brand new approach.




Actually it dictates allowed methods how redaction is done by the 
server, practically eliminating the possibilities foreseen in rfc9537 
which lead to removal of properties, objects or array elements 
(mainly "Redaction by Removal" and one mode of "Redaction by 
Replacement Value"). If you'd remove these methods from rfc9537, 
you'd actually fix the issues with prePath as well because prePath 
would never occur.


If redaction by removal was instead redaction by placeholder, then the 
items being redacted could be identified by JSONPath (assuming 
JSONPath is usable). I believe you proposed placeholder values but the 
9537 authors rejected it.
My argument was indeed to still cover for placeholder values in order to 
handle not redaction aware clients, accounting for no content 
negotiation possibility for the server to know if the client would 
understand the extension. I think in practice we might see redaction by 
replacement value misused for this purpose. This would be rather only 
happening to the common fields, but removal might be equally happening 
for other kind of fields, like events.


The group consensus was however that these methods exist and are in 
use by the servers, so not taking them into account in rfc9537 would 
have too much of an implication on the servers. This would result in 
servers still doing the same thing (ergo removing properties, objects 
or array elements) and not having a way to signal it.


I am struggling to understand the logic that a server has the adequate 
knowledge to redact by empty value or redact by partial value but 
cannot substitute values for keys.
I think lack of redaction by removal would be more of an issue in your 
proposed approach.




postPath does not pose such an issue, because even if more than one 
path is selected it is clear which elements of the response have been 
redacted any why. If an overlap happens the client can display both 
reasons fo the redaction.


Overlaps are problematic to clients (and users) when they are signaled 
by multiple redaction methods. I cannot think of a compelling reason 
why they should be allowed.


The starting point is the server policy. If the server would have 
overlapping policies, say: policy 1: remove all handle-IDs due to 
security, policy 2: remove all handles of person type, then those would 
overlap.


So either the server would have to handle that and build redaction 
description of overlapping objects which cover those 2 policies, or it 
can inform the client which can handle it like much better in terms of 
display to the user.




A feature that your proposal adds is a possibility to mark exactly 
which part of partial redaction have been replaced. It didn't appear 
to me as a goal for rfc9537 to have information specific to that 
extend, especially in an unstructured data. The clients processing 
such response may still mark the whole field as redacted leaving the 
interpretation to the user. If this feature is deemed to be important 
it can be still added on top of rfc953, using a method you've 
proposed or any other suitable mean.


Being able to differentiate the parts of a string that are redacted is 
particularly acute when it comes to things like unstructured postal 
addresses (see section 4.1 of my draft) and tel URIs (see section 2.2 
of my draft).


as mentioned, this may be handled as extension of rfc9537 if it is 
important.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[kowalik]

+1

Kind Regards,

Pawel

On 24.06.24 15:26, James Galvin wrote:

The Chairs have decided to extend this WGLC last call for two weeks, one more 
week from the date of this message.  There has only been on indication of 
support and two different threads discussing some minor changes.  We would like 
these discussion to resolve and for there to be more indications of support for 
this document.

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 July 2024.

Thanks,

Antoin and Jim


On 3 Jun 2024, at 10:56, James Galvin wrote:


The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Best Current 
Practice:

Best Practices for Deletion of Domain and Host Objects in the Extensible 
Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 17 June 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Andy Newton.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

[kowalik]

Hi,

I would not see it that black and white.

Scott expressed perfectly yesterday, what I think should be a firm 
design goal for a RESTful approach, that data representations and 
protocol interactions should allow for easy and stateless translation 
layer from/to RFC5730 EPP. I would add that this should include also the 
extension framework supporting all current and potentially future 
extension without double standardisation effort needed for EPP and REPP.


This is not greenfield approach, where such boundaries would not apply. 
This is also a bit broader than the definition of incremental approach.


And it's an achievable goal. I know of at least 2 registries that 
actually have done it. EPP is not going anywhere so this is a reasonable 
approach to assume the implementers would take.


Actually it is even expressed in Design Considerations section of 
draft-wullink-restful-epp already, just maybe not that straightforward 
and got lost in the discussion.


Kind Regards,

Pawel

On 25.07.24 04:57, Gould, James wrote:


I view two options for meeting the goals of REPP, which I believe is 
to have a more Cloud-friendly provisioning protocol:


 1. Incremental Approach
 1. Implement incremental changes to EPP that make it more
Cloud-friendly, which does need to be fully compliant with the
EPP RFCs.  This includes adding support for the HTTP transport
that is handled by EoH, support for client-side state that can
be handled via an EPP command response extension (e.g.,
leverage something like JWT, extend the login command and
login response to create the token, and have the extension
pass the token with each EPP command to propagate the state)
that can be used with any EPP transport (EoT, EoH, and EoQ),
and create an EPP URL routing layer that optimizes the routing
decisions to the EPP services.  This is certainly not REST but
it would be fully compliant with the EPP RFCs and would not
require a rebuild of the existing EPP services, since the
extensions are optional.  This work could be done by REGEXT,
where the only question mark is the definition of the EPP URL
routing layer in the existing charter.  Other aspects of REPP
could be considered for the Incremental Approach, where this
list is what I’ve thought of thus far.
 2. Greenfield Approach
 1. Define a new provisioning protocol that does not attempt to
extend EPP, but instead takes the lessons learned from RDAP
for REST and the lessons learned from EPP for the data model
and extensibility to define a new RESTful provisioning
protocol.  EPP is more than RFC 5730 but includes all the
extensions that have been created over the past 20 years, so
creating a new provisioning protocol that can support a
similar set of features will be a very large undertaking. 
This large task is best suited for a new working group with a
defined set of requirements.  Attempting to do this work in
REGEXT would need to de-prioritize the extension work, since
it will consume most if not all the focus.  All the EPP
services and extensions would need to be re-implemented and
transitioned from EPP.  I personally worked on the development
of EPP and the transition from RRP, and the effort and impact
should not be underestimated.

What is currently defined in REPP is more Greenfield but is attempting 
to maintain some compatibility with EPP.  I would go with the fully 
compatible Incremental Approach or a pure Greenfield Approach.


--

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: *Orie Steele 
*Date: *Wednesday, July 24, 2024 at 9:00 PM
*To: *Maarten Wullink 
*Cc: *Registration Protocols Extensions 
*Subject: *[EXTERNAL] [regext] Re: RESTful EPP Charter side meeting 
Thursday 13:00


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


Hi,

I said that we heard 2 paths forward:

- recharter / expand existing charter

- new working group

If you feel strongly about this topic, I welcome any comments on this 
list or to me or the chairs privately.


There seems to be energy to do this work, I'll work with you all to 
find the right approach.


Thanks to the authors and chairs for the presentation in today's meeting.

Regards,

OS, ART AD

On Wed, Jul 24, 2024, 3:35 PM Maarten Wullink 
 wrote:


Hi All,

Thank you all, for the comments and suggestions during our
discussion earlier today about RESTful EPP.

The Area Director suggested we create a new working group for this
and similar work.

If you are interested in joining us, to disc

[regext] Re: [Ext] DSYNC in EPP

[kowalik]

Correct, the resellers would want to use it this way and likely they are 
not reflected in the data model of a registry.


DENIC is using such approach for General Contact/Abuse Contact where 
either registrar default setting applies or a specific one can be 
assigned for the domain through the provisioning protocol.


If an EPP extension is to be drafted I would rather generalise it to 
support more than just DSYNC.


In the DELEG WG discussion there is also a proposal of 
example._deleg.com. 3600 IN SVCB … [1]


The use case of registrar/reseller discovery will be also very 
interesting for Domain Connect. A TXT Record like 
example._domainconnect.com. can potentially be an answer.


I would be happy to work on this draft.

[1] 
https://datatracker.ietf.org/meeting/120/materials/slides-120-deleg-not-at-the-zone-cut


Kind Regards,

Pawel

On 30.07.24 10:09, Q Misell wrote:
> You would only need an EPP extension in the scenario where different 
domains under the sponsorship of the same registrar would need 
different DSYNC information.


This would very much be the case with resellers, or even a registrar 
using one ICANN accreditation for multiple somewhat operationally 
distinct brands.


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[kowalik]

I am a bit concerned about this draft. We finished WG LC with version 
-05, then both -06 and -07 appeared without any discussion on the 
mailing list.


It would be ok if there would be just nits, but -06 changed normative 
language and -07 now reshaped the recommendation section effectively 
putting all practices into the same bucket. I think it was correct in 
the previous version to make a clear distinction that only the first 
practice is clear to have "minimal undesired side effects". The other 
two are proposed practices, which are neither implemented nor tested by 
anyone, therefore IMHO shall be clearly marked as such.


Kind Regards,

Pawel

On 31.07.24 15:22, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-regext-epp-delete-bcp-07.txt is now available. It is
a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.

Title:   Best Practices for Deletion of Domain and Host Objects in the 
Extensible Provisioning Protocol (EPP)
Authors: Scott Hollenbeck
 William Carroll
 Gautam Akiwate
Name:draft-ietf-regext-epp-delete-bcp-07.txt
Pages:   22
Dates:   2024-07-31

Abstract:

The Extensible Provisioning Protocol (EPP) includes commands for
clients to delete domain and host objects, both of which are used to
publish information in the Domain Name System (DNS).  EPP also
includes guidance for deletions that is intended to avoid DNS
resolution disruptions and maintain data consistency.  However,
operational relationships between objects can make that guidance
difficult to implement.  Some EPP clients have developed operational
practices to delete those objects that have unintended impacts on DNS
resolution and security.  This document describes best current
practices and proposes new potential practices to delete domain and
host objects that reduce the risk of DNS resolution failure and
maintain client-server data consistency.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-delete-bcp-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-delete-bcp-07

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


___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[kowalik]

Comments inline

On 31.07.24 17:20, Andrew Newton (andy) wrote:

[...]

These changes are a result of the shepherd review in checking 
normative references and normative language (see my other email, which 
was likely sent when you sent this :) ).


Yes, E-mails crossed.

I am still not sure how useful it is to have normative language as such 
in BCP, especially if it's only used in the section 6, which refers to 
other sections like 5.1.4.3 which in turn does not contain any normative 
language at all. Whether it's a MUST or SHOULD is likely a secondary 
concern and here at least I would like to learn the logic behind the change.




Would you be satisfied if the first recommendation was labeled with 
"This practice has been observed in use." and the other two 
recommendations are labeled with "This practice has not been observed 
in use."?


This is already stated with each single practice and it would be 
logically inconsistent the way Section 6 is written now ("MUST implement 
one of the following practices...").


For me the BCP shall tell like "SHOULD implement practice 1 if existing 
and operationally proved practices are preferred or MAY consider 
experimenting with practice 2 or 3 in the future".


Repeating in this section, that people using practices highlighted as 
"This practice MUST NOT be used" shall stop and use any of above instead 
may be also an idea.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[kowalik]

Just on this one topic.

On 31.07.24 19:30, Andrew Newton (andy) wrote:
Would you be satisfied if the first recommendation was labeled with 
"This practice has been observed in use." and the other two 
recommendations are labeled with "This practice has not been 
observed in use."?


This is already stated with each single practice and it would be 
logically inconsistent the way Section 6 is written now ("MUST 
implement one of the following practices...").


For me the BCP shall tell like "SHOULD implement practice 1 if 
existing and operationally proved practices are preferred or MAY 
consider experimenting with practice 2 or 3 in the future".


I don't understand this. A SHOULD and MAY means a practitioner can say 
they adhere to the BCP without doing anything. Also "the future" is 
subjective. 


Yes, "the future" is subjective. That's right. However touches on one 
important point.


If the goal is to eliminate those bad existing practices in a 
foreseeable near future, then practice 1 is the only that is practicable 
and can be implemented by only one party - the clients. This is by the 
way also an inconsistency in the current text - it tells now that EPP 
MUST servers implement practices, which is not right for this one. At 
least the description does not mention any of server changes needed. For 
others both servers and clients must implement collectively.


Practice 2 has a lot of moving parts that needs to change both by 
servers and the clients, so nothing one party can implement on the spot 
to improve the situation in any way. It maybe recommended as a target 
picture, but will take loads of time to implement. Is it then an equal 
recommendation referring to the goal?


Practice 3 also require both servers and clients to change, but likely 
is easier to implement. Easier does not mean easy, as clients tend to be 
reluctant to solutions that work only with selection of registries, so 
servers would have to move first and allow for sacrificial.invalid or 
alike. I'm not an expert in ICANN policies, but maybe it's even needed 
to change those. Also quite broad tests are likely required if with all 
those conditions mentioned in 5.1.4.3 are indeed fulfilled in the wild.


So I don't feel right to put an equal mark within Best Current Practice 
document for those three. Whatever "current" means.


Kind Regards,

Pawel Kowalik



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

[kowalik]

Hi Andy,

On 31.07.24 22:16, Andrew Newton (andy) wrote:

Pawel,

The issues you have raised about changes necessary for either or both 
the EPP client and EPP server appear to me to go beyond normative 
language. Given this type of language  is not in any version of the 
draft, does this mean you are not supportive of this document 
regardless of the -05 or -07 version?


-andy 


-05 and -06 were fine and I'm supportive of those. If it's SHOULD or 
MUST or we remove normative language entirely would not be substantial 
change IMHO.


-07 restructured the section 6 so that the 2 issues appeared:

    1) removed preamble and paragraphs so that current and proposed 
practices were set as equal choice to implementers


    2) added normative text which means the changes are only to be 
implemented by servers


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: New draft draft-kowalik-regext-domainconnect-00

[kowalik]

Hi Marco,

Thank you for this remark. It was addressed in 
https://datatracker.ietf.org/doc/draft-kowalik-domainconnect/00/.


Kind Regards,

Pawel

On 13.09.24 10:38, Marco Davids (IETF IMAP) wrote:

Hi Pawel,

Op 31-07-2024 om 12:04 schreef Pawel Kowalik:

As mentioned there is a renewed draft. I would appreciate more 
feedback from the working group on the content of the document 
itself, even if not adopted.

https://datatracker.ietf.org/doc/draft-kowalik-regext-domainconnect/


While reading through the document, I noticed that the IANA 
considerations sections is empty.


However, I believe it should refer to RFC8552 and/or 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names


Thanks.



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

[kowalik]

Hi Jasdip,

I think "re-using" wouldn't be the right statement. To me it seem that 
relation search is actually defining a certain extension functionality 
of an existing search path segment /domains. This is however only 
implicit, because rfc9082 is actually not defining if a path segment 
below /domains hast to be related to /domains or not. From the 
implementation standpoint it might be an useful property, being able for 
example to route requests for certain top level paths to specific 
subsystems responsible for certain resource types. Also 2.3.1 of 
draft-ietf-regext-rdap-extensions does not offer clarity if path 
segments are added to existing path segments.


From this perspective whether the path is extended with /rirSearch1 or 
/rs_rirSearch1 does not really make a difference for interoperability, 
if this implicit assumption would have been clear in the draft.


The ambiguity seems to be also there because /domains path segment is 
used the same in both context of RIR and domain name registry. The draft 
puts however RIR in focus. This poses an interesting question - if a 
domain name registry would like to define relation type of search as in 
this draft, is it ok to signal this extension and just support 
'domains/rirSearch1//' path, or would it be 
expected to support all the paths defined, meaning in practice this 
extension would not be able to be used at all and an extension would 
have to be defined separately for this use case?


Section 6 seems to imply that a partial implementation is not an 
intention of authors (even though I did not find any normative language 
around that:


"[...] that is not meant to imply that a server can support only a 
portion of the functionality defined in this document."


Kind Regards,

Pawel

On 11.10.24 20:55, Jasdip Singh wrote:


Hi Scott,

It is the latter. “domains/rirSearch1//” 
re-uses the “domains” path segment from RFC 9082 and then adds child 
path segments.


This is also how we do in reverse search (RFC 9536). For example, 
“/domains/reverse_search/entity?handle=CID-40*&role=technical”.


Jasdip

*From: *Hollenbeck, Scott 
*Date: *Friday, October 11, 2024 at 8:19 AM
*To: *mario.loffredo=40iit.cnr...@dmarc.ietf.org 
, Jasdip Singh 
, a...@hxr.us , regext@ietf.org 

*Subject: *RE: Re: [regext] Re: Extension Identifiers in 
draft-ietf-regext-rdap-rir-search


*From:*Mario Loffredo 
*Sent:* Friday, October 11, 2024 2:44 AM
*To:* Hollenbeck, Scott ; jasd...@arin.net; 
a...@hxr.us; regext@ietf.org
*Subject:* [EXTERNAL] Re: [regext] Re: Extension Identifiers in 
draft-ietf-regext-rdap-rir-search


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


Hi Scott,

sorry  but didn't undenstand your example about collisions.

From a conceptual perspective, any path "/domains/" is a subpath 
(we can consider it as an extension) of "/domains" but,  
programmatically, they are different as AFAIK a full path is parsed 
and processed altogheter.


For example, in .it RDAP server, I have leveraged the feauture 
provided by a Java framework to specify paths and their subpaths in 
order to easily map an incoming request onto but, at the end of the 
parsing phase, only one full path is selected.


*/[SAH] Mario, my concern about a possible collision arose because 
“domains” (from RFC 9082) === “domains” (from the draft). I’m not sure 
if the draft is specifying a new “domains” path segment (in which case 
the names do collide), or if the draft is extending the 9082 path 
segment by adding additional elements to the path. My confusion exists 
because the draft isn’t using prefixed extension identifiers. The 
situation would be unambiguous if the draft used something like 
“rs_domains”, or “domains/rs_rirSearch1”. The prefix is a clear 
indicator of what’s being extended. In my exchange with Jasdip I did 
note that there’s no operational issue here even if there is a 
collision because a properly formed query will contain other 
information that enables a server to correctly process both 9082 
queries and RIR search queries, though I’d prefer that the information 
included an extension identifier prefix./*


*/I also noted that I’d like to for the shepherd writeup include text 
noting that the proposed extension identifiers don’t comply with 
Standard 95, and we don’t have consensus on whether or not that’s an 
issue./*


*/Scott/*


___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

[kowalik]

Hi Tom,

On 21.10.24 23:57, Tom Harrison wrote:

Hi Pawel,

On Mon, Oct 21, 2024 at 09:29:49AM +0200,kowa...@denic.de wrote:
[...] In the absence of any text
permitting partial implementation, this text requires implementers to
implement the whole document ("the functionality specified in this
document"). [...]
Thanks for clarification.Did the authors consider putting using RFC2119 
language for that?

As far as the forward domain use case is concerned, the
"/domains/rirSearch1/..." specification text can't be relied on as-is,
because it's all in terms of reverse domains, and depends on their
correspondence with internet number resources.  If somebody wanted
similar link relation searches for forward domains, then I think it
makes more sense to define that in a separate document, rather than
trying to generalise this document to support that use case as well.


This is I guess a bit the problematic part. Relation search seems to be 
as generic use case as reverse search and having a second specification 
on forward zones looks a potential burden for a generic client 
implementations. If the path part for the relation search would have 
been kept generic, like /domains/relsearch/ it could be extended by 
other documents to other relation types not specified in rir document. 
This brings me also to a conclusion, that an extension prefix would be 
rather harmful as it would pin the functionality and the path segment to 
rir extension, even if it would allow further extensions and as client 
one would expect the path to remain same.


Kind Regards,

Pawel




smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09

[kowalik]

Hi Jim and Antoin,

It's a bit confusing, as the mail subject relates to 
draft-ietf-regext-rdap-rir-search and the content to 
draft-ietf-regext-epp-eai.


May you please clarify which document is starting WGLC now?

Kind Regards,

Pawel

On 11.11.24 09:13, James Galvin wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard 
and thus this message begins a working group last call (WGLC):

Use of Internationalized Email Addresses in the Extensible Provisioning 
Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/22/

This document has been through WGLC previously and was submitted to the IESG at 
that time.  It was reverted back to the working group to resolve comments 
received during the IETF Last Call and IESG review processes.  These comments 
have been addressed.  Because the changes made in response to the comments are 
considered to be technically material, the additional WGLC is required.

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a reply of “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 25 November 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Jody Kolker.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: RDAP versioning draft feedback

[kowalik]

Hi Jim,

To recap on what we discussed in Dublin and to also have input from the 
working group.


Jasdip stated a very valid question. Reading through the draft in more 
detail I also have a feeling that we are trying to use a sledgehammer to 
crack a nut.


The problem to solve was that RDAP was lacking of clear way of 
signalling that there is a different version of the same extension, so 
the client would know that foo1 and foo99 are indeed version of the same 
extension and not different unrelated extensions.


What the draft proposes is very feature reach, but does not tell a lot 
about why clients and servers should spend time implementing all of its 
features. Do we expect an RDAP extensions to have tens or hundreds of 
versions, so that the clients would need to apply a logic of semantic 
versioning to work on ranges of versions and distinguishing major and 
minor versions? If we talk about extensions from IETF control this is 
not likely to happen, just because of how IETF process works. Why do we 
need extensibility to even support more versioning semantics (Versioning 
Type)?


What we expect clients to do with all the related lifecycle information 
(start/end/default)? I can make some usefulness for the "end" attribute 
(like warning about using deprecated interface), but mandating the 
server (normative MUST) to remove the support exactly at this time seems 
like a void requirement, as operationally quite hard to fulfil unless 
the server would implement special logic for management of versions of 
extensions. A bit of overhead for very little gain if you ask me. 
"start" is something with even less usefulness as we are talking about 
future version. Here there are a lot of assumptions that the server 
deploys a future version and only activates it later at a given point in 
time. Again a logic not really needed. The client will learn about new 
version when it's there and supported by client anywhere.


I would double what Jasdip stated below, that opaque versioning - with 
just adding semantics to one symbol "-" splitting extension identifier 
into name and version would do the same good job and be a way simpler.


If someone would like to release a new version of their extension every 
month (as sais likely outside of IETF), another semantic for versioning 
would be good for it and within the opaque version part. But then it 
might be a part of their particular specification and would only concern 
clients dealing with this particular extension.


K.I.S.S.

Kind Regards,

Pawel

On 03.11.24 22:50, Gould, James wrote:


Rationale for versioning:

Section 1 says, “The RDAP Conformance values are identifiers with no 
standard mechanism to support structured, machine-parseable version 
signaling by the server.” It’d be good to elaborate with usage 
scenarios where such structured versioning is a value-add for clients 
beyond what the opaque (no inner meaning) extension identifiers from 
STD 95 afford. Let’s say an extension is “foo1”, then “foo99”, and 
later “foo2” in terms of “versions”. The server announces its support 
for these non-structured extensions, say, on its web site or through 
the “rdapConformance” member in a /help response, and the clients can 
then negotiate a particular non-structured version of this extension 
using the standard HTTP content negotiation methodology (e.g., using 
the RDAP-X media type). In the spirit of what-not-to-do, it is fair 
for a client to ask: Why should I go through the overhead of 
processing the “versioning_help” member? What value-add does it get 
me? Is it in some way a better discovery and/or negotiation method for 
RDAP extensions? Would be good to beef up the rationale for structured 
versioning.


JG – We need to ensure that RDAP-X supports the extension version 
identifier as well, so there should be no variance between the 
versioning extension and the RDAP-X extension.  We can add more 
rationale in Section 2 “Semantic Versioning”, where a server could 
support multiple versions of an extensions that are signaled as 
related.  For the versioning extension itself, there have been 
multiple versions of it that are not structurally different and not 
backward compatible, with the latest version being “versioning-0.3”.  
Other RDAP extensions could leverage semantic versioning during 
development to encourage implementation with version isolation and 
with clear relationship between the extension version identifiers. Do 
you believe that we should look to add the concept of relationships 
between opaque version identifiers?



Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: WGLC: draft-ietf-regext-epp-eai

[kowalik]

+1

On 18.11.24 15:17, James Galvin wrote:

My apologies folks, I got the subject line wrong.

The document in WGLC is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/22/


Please also take this message as a reminder to indicate your support or any 
question or concerns you might have.

I have changed the subject line on this message.


Thanks,

Antoin and Jim


On 11 Nov 2024, at 6:56, kowa...@denic.de wrote:


Hi Jim and Antoin,

It's a bit confusing, as the mail subject relates to 
draft-ietf-regext-rdap-rir-search and the content to draft-ietf-regext-epp-eai.

May you please clarify which document is starting WGLC now?

Kind Regards,

Pawel

On 11.11.24 09:13, James Galvin wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard 
and thus this message begins a working group last call (WGLC):

Use of Internationalized Email Addresses in the Extensible Provisioning 
Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/22/

This document has been through WGLC previously and was submitted to the IESG at 
that time.  It was reverted back to the working group to resolve comments 
received during the IETF Last Call and IESG review processes.  These comments 
have been addressed.  Because the changes made in response to the comments are 
considered to be technically material, the additional WGLC is required.

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a reply of “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 25 November 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Jody Kolker.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback (on rdap-x media type)

[kowalik]

Hi,

A sub-thread just on this one aspect of media type to be used in rdap-x, 
or generally content negotiation.


On 12.11.24 21:46, Andrew Newton (andy) wrote:

responding to both Mario and JGould in line...

On Mon, Nov 4, 2024 at 5:50 AM Mario Loffredo
 wrote:




Section 3 "Using The RDAP-X Media Type"

My initial thought upon re-review of this section was to reuse the existing "application/rdap+json" media 
type by adding the optional parameter "extensions", or better "rdapx" to the media type 
registration, but then I got to Appendix B.1 that makes a good point with the language in RFC 6838.  I really don't 
want to include RDAP-X in the content-type header of the response, since it duplicates the rdapConformance member, and 
requires updating RFC 7480 with no real positive value.  Updating RFC 7480 may also trigger the need to bump 
rdap_level_0 to rdap_level_1, which is certainly not desired.  We should re-evaluate the language of RFC 6838 in its 
application to an RDAP extension.  How about adding support for RDAP-X in the accept header of the request and to have 
the response content-type header remain using the existing media type of "application/rdap+json"?  This would 
meet the need of the client providing the RDAP extension hints without the negative side effects of updating RFC 7480 
and bumping rdap_level_0 to rdap_level_1.


This is an interesting idea and I think it simplifies things. Thanks.


I would very much support extending application/rdap+json with an 
additional optional parameter of requested extensions instead of adding 
application/rdap-x at all. A new artificial media type seems to be a 
tempting approach to maintain back compatibility, but maybe it is not 
needed at all?


There was an argument, that it would likely break the servers if 
unexpected parameters appear. I decided to check in reality how big the 
problem would be.


With help of small script [1] I queried all RDAP servers listed in IANA 
bootstrap list to get some stats how they behave with different Accept 
header.


The results [2] show, that 99.65% of the servers would deliver the same 
answer for 'application/rdap+json;extensions="rdap_level_0 rdapx foo"' 
as they do for 'application/rdap+json'.


What with the remaining 0.35%? It seems they are so wrongly implemented, 
that they would also break if an additional media type rdap-x appears in 
the request. 99.47% works with rdap-x as a second media type and 99.29% 
if you change order and put rdap-x first.


My conclusion is, that rdap-x will break a marginal portion of wrongly 
written servers, no matter if we keep same media type or define a new one.


Defining a new media type would mean, that application/rdap-x+jsonwould 
remain with us forever, as it will never replace application/rdap+json, 
but will become eventually a common practice to support. Extending of 
application/rdap+json seems to me less of pollution to the protocol on 
the long run.




Appendix B.1 "Not Reusing the Existing Media Type"

This section helped me out since my thought was to reuse the existing "application/rdap+json" media 
type instead of defining the new RDAP-X media type.  The language in RFC 6838 is clear and adding the 
capability of providing hints of the RDAP extensions is new functionality, but I really don't see that it's 
adding new functionality for the media type itself. We could define the existing 
"application/rdap+json" media type optional parameters as a form of extension in the extensions 
draft, where it will become an extension point without adding new functionality specific to the media type 
itself.  The response is still RDAP using JSON independent of the mix of extensions that are used.  If use of 
an optional media type parameter of the existing "application/rdap+json" media type cannot be done, 
can RDAP-X be used in the accept header and not returned in the content-type header to get the value of 
RDAP-X without the negative side effect of updating RFC 7480 and bumping rdap_level_0 to rdap_level_1?

[ML] Think it's worth investigating if this soultion could be feasible.


I think so. We'll look into it. See above.


Also supportive of this one. Just extend the media type registration 
that parameters are to be expected provided by extensions (with usual 
prefix logic of RDAP etc.). New parameters will be then added in 
extensions themselves and update media type registration with detailed 
parameters.


The registration tells there are no *required* parameters to the media 
type, which remains true so in my opinion neither update to rfc7483 or 
rfc7480 would be required nor would we need to bump to rdap_level_1.



[1] https://github.com/pawel-kow/RDAP-tests/

[2] 
https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.md


https://github.com/pawel-kow/RDAP-tests/blob/main/rdap_help_responses_20241114_IANA_bootstrap_list.csv

Kind Regards,

Pawel




smime.p7s
Description: S/MIME Cryptographic Signature
__

[regext] Re: Extensions: Clarify redirects #55

[kowalik]

Hi Jasdip, Tom, Andy,

On 03.01.25 22:58, Jasdip Singh wrote:


https://github.com/anewton1998/draft-regext-rdap-extensions/issues/55

>> Section 3.1, paragraph 1

>> account for transfers of resources between RIRs.  Section 4.3 of 
[RFC7480] instructs servers to ignore unknown query parameters.  As it 
relates to issuing URLs for redirects, servers MUST NOT blindly copy 
query parameters from a request to a redirect URL as query parameters 
may contain sensitive information, such as security credentials, not 
relevant to the target server of the URL. Following


> The issue with this recommendation is that "unknown query parameter" 
is also undefined. I think there is a difference between unknown and 
unsupported parameters.


[JS] Of course. But the term “unknown query parameter” is 
self-explanatory and inherently distinguishable from “unsupported 
query parameter” (known but not supported/implemented). The focus of 
this recommendation is on the former.


[TH] I think clarifying this per Pawel's comment would be a good idea, 
even though the most reasonable reading is per your response here.



[PK] Thanks


> A parameter included in the RDAP Extensions Registry may be known to 
server and still can be unsupported if the server does not implement 
given extension.


[JS] Sorry, what does “A parameter included in the RDAP Extensions 
Registry” mean?


[PK] Sorry for the shortcut. I meant "Extension Identifier" registered 
in "RDAP Extensions" registry, which turns out to be used as query 
parameter (for example "paging").


> Following this line all parameters which are registered extension 
identifiers or prefixed with register extension identifiers would be 
safe to forward unless the nature of the parameter is either 
confidential or only related to the context of the origin server. An 
example for the latter could be page/sort/cursor from the rfc8977. It 
would be even better if


registration of extension identifiers would specify if they are safe 
to be forwarded with redirect. This would also solve the issue with 
versioning eventually.


[JS] That seems like a good idea.

>> Section 3.1, paragraph 0

>>  the advice in [RFC7480], servers SHOULD only place query 
parameters in redirect URLs when it is known by the origin server (the 
server issuing the redirect) that the target server (the server 
referenced by the redirect) can process the query parameter and the 
contents of the query parameter are appropriate to be received by the 
target.


> As far as this may seem to be a valid recommendation I'm having hard 
time to see how it would be practically implementable if the target of 
a redirect is an RDAP server in other authority domain.


[JS] This recommendation helps safely allow versioning parameter for 
search scenarios between a registry and a registrar that know each 
other well. As we know, redirects typically factor in for lookups.



[PK]


[AN] That's correct. It is difficult to implement and therefore not 
recommended.


[PK] SHOULD means the opposite, doesn't it? Or you agree with Tom 
(below) to drop this recommendation?


> Does it mean that the origin server would have to negotiate between 
what the client requested


and what the target server can support in terms of extensions etc. in 
order to generate a valid request with the query parameters that the 
server can process? Or, as consequence of 7480 4.3 shall we assume 
that the target server MUST ignore any unknown parameter so it is safe 
to assume that any parameter can be actually safely forwarded, even if 
related to unsupported extension?


[TH] The points he raises here make me think that possibly the last 
sentence should be omitted altogether, since it could lead to 
divergent server behaviour and more problems for clients.  In the 
unusual case where a query parameter should be included in a redirect, 
that could be documented as part of the relevant extension.  Suggested 
updated text:


```

   [RFC7480] describes the use of redirects in RDAP.  Redirects are

   prominent in the discovery of authoritative RIR servers, as the

   process outlined in [RFC9224], which uses IANA allocations, does

   not account for transfers of resources between RIRs.

   Servers SHOULD NOT copy request query parameters from a request to

   a redirect URL, except where that is required or permitted by the

   specification or extension that defines the query parameter.  This

   reduces the risk of exposure of authorisation credentials and

   similar.

```

[AN] A server MUST only copy a request parameter to a server in 
another authority if it knows that server is the proper target for the 
information of the query parameter, regardless of the extension. 
Otherwise sensitive data may leak.


[PK] I like the proposal from Tom. "proper target for the information" 
is for me covered by "required or permitted", but to be clear it may be 
expanded with "required or permitted by the specification or extension 
that defines the query pa

[regext] Re: Extensions: Clarify profile extensions #39

[kowalik]

Hi Jasdip, Tom,

On 03.01.25 22:37, Jasdip Singh wrote:


https://github.com/anewton1998/draft-regext-rdap-extensions/issues/39

>> Section 2.1.1, paragraph 1

>> While the RDAP extension mechanism was created to extend RDAP 
queries and/or responses, extensions can also be used to signal server 
policy (for example, specifying the conditions of use for existing 
response structures).  Extensions that are primarily about signaling 
server policy are often called "profiles".


> For a profile extension it is needed to define what is it supposed 
to do.


> Here some initial list of what such list might consist of:

> - mark some specific extensions (and versions thereof) as required

> - mark some specific optional fields/url segments/object classes as 
required


> - limit value space of specific fields (for example enumeration of 
values or a pattern for a text field, narrowed down enum, value range 
for numeric fields etc.)


[JS] Good idea.

> I would also not mention "server policy" as in the end such profile 
puts down certain technical requirements on a server which a client 
can rely on.  So it increases technical interoperability.


[JS] OK

[TH] I think this is fine, but I also think we are probably in 
agreeance with Pawel on this point already, in that the extension 
itself is what is documenting the relevant server policy here.  (I 
might be misunderstanding Pawel's last statement here, though.)



[PK] the understanding is correct. Thanks.


> Interesting aspect is, whether a profile may be an alias for a 
certain configuration of extensions when doing requests. So for 
example if profile1 would define it requires extension foo to be 
supported and included in the answer, then would it be enough for the 
client to request profile1 and be sure that extension foo is always 
included in the response? It may be an interesting property if a list 
of extensions (and their versions) defined in a profile would be long.


[JS] Interesting idea. The NRO RDAP Profile [1] has something similar 
where it includes the “cidr0” extension.


[1] 
https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt


[TH] In a strict sense, including the original identifier is not 
necessary, because clients that understand the profile will know what 
to do, and clients that don't will simply ignore the unknown members.  
I do think it makes sense to say that profile extensions SHOULD 
include the original identifiers in a case like this, though.



[PK] Yes, this was the point. Thanks.


> Finally it would be worth mentioning if it's either/or between 
profile extensions and regular extensions or it is OK for a regular 
extension to define profile as well (with all the properties explained 
above).


[JS] Interesting point. Nothing should preclude a regular extension 
from profiling, but it typically is more focused on a narrower problem.


[PK] Yes, this is a matter of practice but this would help the reader to 
be clear that it is allowed. A case when it would happen would be when 
an extension would build on top of other extension. In this sense it 
would implicitly require it, defining a profile in a sense.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Extension identifier case-insensitivity #50

[kowalik]

Hi,

On 03.01.25 22:52, Jasdip Singh wrote:


https://github.com/anewton1998/draft-regext-rdap-extensions/issues/50

>> Section 2.2, paragraph 4

>> [RFC7480] does not explicitly state that extension identifiers are 
case-sensitive.  This document updates the formulation in [RFC7480] to 
explicitly note that extension identifiers are case-sensitive, and 
extension identifiers MUST NOT be registered where a new identifier is 
a mixed-case version of an existing identifier. For example, if 
"lunarNIC" is already registered as an identifier, a new registration 
with "lunarNic" (note the lowercase if "ic" in "Nic") would not be 
allowed.


> In the first reading of it, it seems inconsistent why one would want 
to have case-sensitive handling and on the other side forbid 
registering case-insensitive variants.


[JS] We meant to note “extension identifiers are case-insensitive”.

> It would be good to consider if defining them case-insensitive makes 
any  harm and if yes state it here. Then forbidding registration of 
case-insensitive variants would only have a meaning of avoidance of 
potential miscommunication, but not


necessarily any technical rationale. Technical systems deal with it 
pretty well to make a difference and none of the places where 
extension identifiers are used (JSON elements, path segments, query 
parameter names) are case-insensitive in


nature. And if only human communication is concerned, the question 
remains why someone sane would ever try to do it. And if he tries 
maybe the reasons are valid ones, like re-thinking the naming strategy 
of the same extension from lunarNIC to lunarNic? Then maybe worth 
softening MUST NOT to SHOULD NOT?


[TH] I think any potential benefits of SHOULD NOT here are extremely 
marginal, such that MUST NOT is fine.


[PK] I do not have very hard feelings about changing this MUST NOT but 
there will be consequences, that MUST NOT will block those extremely 
marginal  but VALID cases (like the one I mentioned above, but maybe 
some others that do not come to mind now) creating possibly more harm, 
like a very new identifier instead of an editorial case correction. 
Possible harm of "strong" and narrow defined SHOULD NOT seems to be 
less. This goes through DEs review anyway, so they can definitely make 
the right call.


Kind regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: CALL FOR ADOPTION: draft-yao-regext-epp-quic and draft-loffredo-regext-epp-over-http

[kowalik]

A clear +1 for adoption of DoH.

For DoQ I share the opinions expressed in the room in IETF 119 session, 
that benefits from adding this transport are not clear, so I don't think 
we should spend cycles on this draft until this is better answered. 
Adding this new transport on a Standard track would mean that EPP will 
have two standard transports without telling why someone should decide 
for one instead of the other.


Kind Regards,

Pawel

On 03.02.25 15:05, James Galvin wrote:

Continuing our potential adoption of new documents, as previously discussed the 
next two documents will be taken together.  The suggestion is to advance them 
together, although if these are adopted the working group can choose to advance 
them separately.

This is a formal adoption request for both:

Extensible Provisioning Protocol (EPP) Transport over QUIC
https://datatracker.ietf.org/doc/draft-yao-regext-epp-quic/

Extensible Provisioning Protocol (EPP) Transport over HTTPS
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/

Please review these drafts to see if you think they are suitable for adoption 
by REGEXT and reply to this message on the list, clearly stating your view.  
Optionally indicate if you are willing to contribute text, review text, or be a 
document shepherd.

This Call For Adoption will close on Sunday, 16 February 2025.

If there are no objections, the chairs will consider these documents adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: some feedback on draft-ietf-regext-rdap-versioning

[kowalik]

Hi,

Inline 2 comments on problem to solve and query params vs. headers.

On Mon, Nov 18, 2024 at 1:14 PM Gould, James > wrote:

2. In section 1, the sentence on RDAP conformance values is
misleading. I propose:


OLD:


The RDAP Conformance values are identifiers with no standard mechanism
to support structured, machine-parseable version signaling by the
server.


NEW:


The RDAP Conformance values are identifiers that are by default opaque
in nature.

[JG] I believe it's important to leave this sentence as is. The language is based on the chairs proposal 
on slide 6 
ofhttps://secure-web.cisco.com/1koiI5WyX_hZHcVm3IdqFWND-OqAVTD7peEsW4eAJ1P1v0eo-dDA7OVmhmvUS1UWMrmaxWoBs6AoPn9x2FgeEyWfVg-XI_hnWExm6Y7CVkeyIFk4P-GPCTYBiOUB1EvpvlWtDzmUokeQJ7pBiel93RCZAAWQ59fj2OjmpB_WRgBMj084nzJKlWIYl0qr4278dulNIV0NMWQQ4wA6FH4VFPXlRSnXFiwjRbqj-aM9_RUD4wt0MK_RhY7eGERSkU14rts6-yHNRs_9IgX0ext2VhzgCyUpT3DGY6k4cI3fCo-w/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F114%2Fmaterials%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance
 
,
 where "explicit support for version is not an integral part of the extension mechanism" and 
"Certainly, you can choose to include version inside the specification for your extensions, but in 
the context of the base protocol an extension is either supported or its not, and when supported it 
simply means there is a shared understanding of what is to be done between the client and server". 
We need to clear the issue the versioning extension is addressing, which is to provide support for a 
structured, machine-parseable version signal.

I don't see the connection between your text and those slides.


But your text does not accurately describe the issue. rdapConformance
is a JSON array of JSON strings, where each string contains an
extension identifier. That array and those strings are machine
parsable and it is easy for a client to distinguish one string from
another. There is no structure to the value of those strings making
them opaque, but a client can certainly distinguish one from another
meaning a client can know the difference between "foo0" and "foo99".

[JG2] - You are correct that a client can parse the extension identifiers in 
the rdapConformance, but there is no structured, machine-parseable version 
signal in the extension identifier values.  The chairs proposal supported that 
versioning is not an integral part of the extension mechanism, which is what 
the versioning extension is looking to solve.  Versioning is not explicitly 
signaled via the rdapConformance, so we need to be clear about the purpose of 
the versioning extension.


[PK] The only problem that we are solving is the situation where a 
server would implement a new version of an extension which is not known 
to the client but compatible with the version supported by the client.


Without versioning signal - the client will see "foo99" and would not be 
able to tell that it is a new back-compatible version of "foo0" which it 
understands.


In any other case there is no difference.

If "foo0" and "foo99" are incompatible - the client would need to abort 
- no matter if versioning information is available or not. It can tell 
it also based on rdapConformance.


If the client supports both "foo0" and "foo99" then it also does not 
matter. The client knows the logic behind and the relation of the 2 
extension version.



[JG] I don’t agree with including a preference between the two methods. The 
extension supports both with a requirement for the server to implement both and 
the client to choose what best meets their requirements. I don’t believe the 
versioning extension should replicate the reason for the X-Media extension 
considering that the X-Media extension is a normative reference.

Are you saying client implementers should not be given notice that one
of these methods has potential problems? And shouldn't the one with
problems be depreffed in favor of the other?

[JG2] The X-Media extension is a normative reference, so client implementers 
should be fully aware of what is described in there.  I don't believe there is 
any need to provide a preference for one of the options.  There is plenty of 
use of the query parameters in RDAP.  The clients will be made aware of the 
negatives of query parameters in the extensions draft and the X-Media drafts, 
which are both normative references in the versioning draft.


[PK] We are discussing in other thread about downsides of forwarding or 
not (unknown) query parameters. The fact

[regext] Re: Extensions: Clarify search results naming #41

[kowalik]

Hi Jasdip, Tom,

On 03.01.25 22:41, Jasdip Singh wrote:


https://github.com/anewton1998/draft-regext-rdap-extensions/issues/41

>> Section 2.4.4, paragraph 1

>> As described in [RFC9082] and Section 2.3, an extension may define 
new paths in URLs.  If the extension describes the behavior of an RDAP 
query using the path to return a new RDAP search result, the JSON name 
of the search result MUST be prepended with the extension identifier 
(to avoid collision with search results defined in other extensions).  
If the search result contains object class instances


> I think this requirement is harmful for the protocol. Let's say I 
want to create extension "fuz" that would offer a new way of searching 
through objects. Let's call it fuzzySearch. I would define a new query 
parameter "fuzzy" and append it to a path segment according to the 
object class I would like to search through. So if I query 
/domains?fuzzy=foo I expect as a client to still be able to process 
the response as per rfc7483 from domainSearchResults JSON element 
rather than special handling for fuz_domainSearchResults.


[JS] Agreed. This prepending is only for newly defined RDAP search 
result members and when a bare extension identifier is not used to 
name such a new member. As a contrary example, the reverse domain 
search in the RIR Search draft leverages the existing 
“domainSearchResults” member.


[TH] I think this is right, but that it may be worth spelling it out 
in more detail.  Something like:


```

    As described in [RFC9082] and Section 2.3, an extension may define

    new paths in URLs.  If the extension describes the behavior of an

    RDAP query using the path to return an RDAP search result for a

    new object class, the JSON name of the search result MUST be

    prepended with the extension identifier (to avoid collision with

    search results defined in other extensions).

```



[PK] Thanks. The proposed text covers my concern.

Kind Regards,

Pawel




smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Referrals handling #56

[kowalik]

Hi Jasdip,

On 03.01.25 22:59, Jasdip Singh wrote:


https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56

>> Section 4.2, paragraph 3

>> Extensions MUST explicitly define any required behavioral changes 
to the processing of referrals.  If an extension does not make any 
provision in this respect, clients MUST assume the information 
provided by referrals requires no additional processing or 
modification to use in the dereferencing of the referral.


> Similar to the comment in 4.1 the same applies here. If the referral 
is to be treated as redirect, so that no processing of href is 
expected from the client, then anything in the href must fulfill the 
same requirements as redirect URL. In this case it is up to the server 
to assure compatibility of the request with the link target. An 
alternative scenario would be if media type application/rdap+json is 
an indicator of RDAP resources and in this case the responsibility 
shall be put on client to construct a valid RDAP request compatible 
with the target server and client's capabilities. In this case one 
would need to define this default processing expected from the client.


[JS] Sorry, missing your point. That’s what this para is asking of an 
extension; to guide the client in case anything beyond the default 
“don’t touch the referral URL” scenario.



[PK] It was rather an question with 2 possible outcomes - just pick one. 
The current text does not account for a situation that eventual 
post-processing may be a result from a different extension than the one 
specifying the referral.


First option is that the servers (thus extension authors) shall assure 
referral links are valid and complete RDAP links and undergo exactly the 
same scrutiny as redirects, inkl. addition of query parameters based on 
the request from the client (like versioning parameter). If this option 
would be chosen some language around it would be helpful.


Second option is that the client is always expected to post-process 
application/rdap+json referral links, because server will never add 
query parameters based on how the request from the client looks like. If 
this is the option adding some text would be needed as well.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Current non-compliant extensions #44

[kowalik]

Hi Andy,

On 14.01.25 17:46, Andrew Newton (andy) wrote:

On Fri, Jan 10, 2025 at 1:25 PM  wrote:

On a side note - forbidding registration will also block the original authors 
from registering them to make their registration compliant. A bit of paradox.


Are you talking past each other? Section 5 lists extensions that are
already registered. Why would the authors need to re-register them?


[PK] This discussion is about the extension identifiers fred_version_0, 
artRecord_level_0, platformNS_level_0 and regType_level_0 which are not 
registered and should have been.


Maybe I was ahead of myself by thinking that the mentioned change in 
IANA considerations would just block registration of those mentioned 
identifiers.


So just to consider when drafting the new text, that rules in the IANA 
considerations and in 2.2 don't forbid registering these identifiers for 
the original extensions.


Kind Regards,

Pawel




smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Referrals handling #56

[kowalik]

Hi Andy,

On 15.01.25 21:05, Andrew Newton (andy) wrote:

On Wed, Jan 15, 2025 at 5:38 AM  wrote:

Hi Andy,

On 14.01.25 17:42, Andrew Newton (andy) wrote:

On Fri, Jan 10, 2025 at 12:35 PM  wrote:

[PK] as indicated above it is not about the extension specifying the
referral.

Understood, but how does the current text not allow this?


I was guided by the interpretation that the text in 4.2 applies to
referrals specified by a given extension. If the intention of the text
is that it applies to any referrals, also to those specified elsewhere,
then it's OK, but maybe giving it an explicit wording in the text would
make it also very clear to the authors of future extensions.

I think that is a good enhancement.

[PK] Thanks.

Along with "servers MUST NOT use
multiple extensions in a response with processing requirements over
the same referrals."


[PK] I would not be that restrictive here. What matters is that the 
requirements do not pose a conflict which would make it impossible to 
process or the processing could be confused by the client rendering the 
results not deterministic.


My proposal:

"servers MUST NOT use multiple extensions in a response with processing 
requirements over the same referrals, which different clients would not 
be able to process in a deterministic way."


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Referrals handling #56

[kowalik]

Hi Andy,

On 10.01.25 18:21, Andrew Newton (andy) wrote:

On Wed, Jan 8, 2025 at 10:42 AM  wrote:

Hi Jasdip,

On 03.01.25 22:59, Jasdip Singh wrote:

https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56




Section 4.2, paragraph 3
Extensions MUST explicitly define any required behavioral changes to the 
processing of referrals.  If an extension does not make any provision in this 
respect, clients MUST assume the information provided by referrals requires no 
additional processing or modification to use in the dereferencing of the 
referral.




Similar to the comment in 4.1 the same applies here. If the referral is to be 
treated as redirect, so that no processing of href is expected from the client, 
then anything in the href must fulfill the same requirements as redirect URL. 
In this case it is up to the server to assure compatibility of the request with 
the link target. An alternative scenario would be if media type 
application/rdap+json is an indicator of RDAP resources and in this case the 
responsibility shall be put on client to construct a valid RDAP request 
compatible with the target server and client's capabilities. In this case one 
would need to define this default processing expected from the client.



[JS] Sorry, missing your point. That’s what this para is asking of an 
extension; to guide the client in case anything beyond the default “don’t touch 
the referral URL” scenario.


[PK] It was rather an question with 2 possible outcomes - just pick one. The 
current text does not account for a situation that eventual post-processing may 
be a result from a different extension than the one specifying the referral.

I am confused by the premise. If an extension does something like:

"foo99_bar": [
   "link": {
 ...
   }
]

Why would that referral be subject to the link processing of the
extension "faz1001"?

The only issue I see here is that if extension "foo99" says all links
in RFC 9083 json should be processed using X and extension faz1001
says the processing should by Y. But in that case, the server operator
needs to not do that.


[PK] versioning is such example.

Just imagine the request was done with ?versioning=foo99-1.0,faz1001-0.9

If the (RDAP) referral link in foo99_bar would not contain versioning 
query parameter, the client would have to post-process to add it.


Otherwise the client would need to expect no post-processing required 
and the request would be done without versioning parameter.


foo99 could not know in its specification, if there would be a 
versioning extension. Versioning extension could specify that the query 
parameter should be added to all RDAP referrals from any extension. 
Alternatively the extension draft could make a generic requirement for 
this behaviour, like with redirects.



First option is that the servers (thus extension authors) shall assure referral 
links are valid and complete RDAP links and undergo exactly the same scrutiny 
as redirects, inkl. addition of query parameters based on the request from the 
client (like versioning parameter). If this option would be chosen some 
language around it would be helpful.

Second option is that the client is always expected to post-process 
application/rdap+json referral links, because server will never add query 
parameters based on how the request from the client looks like. If this is the 
option adding some text would be needed as well.

Third option which is the last paragraph. The extension explicitly
states the necessary processing otherwise it is assumed the clients
will do none, in which case the href is assumed to be valid and
complete and does not leak sensitive or security information.


[PK] as indicated above it is not about the extension specifying the 
referral.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Non-IETF extensions #42

[kowalik]

Hi Andy,

On 10.01.25 17:26, Andrew Newton (andy) wrote:

2. what about a general purpose extension which won't get defined by IETF and 
would like to approach it later?

What about them? Is there something so onerous in this requirement
that they must break the rules?


[PK] Nothing, just lifecycle issue. I'm not happy with saying: you can 
do something if you startwork on your extension within IETF, but you 
can't if you start elsewhere and then go standardising it.




[JS] If so, it would at that time be considered from an IETF extension angle 
and would most likely get a new extension identifier which may or may not be 
used for prefixing.
[PK] And this is a scenario which is not welcoming people to come to 
IETF for this to happen.




3. would it not be just enough to have a proper review on IANA level when 
identifiers are being registered to assure no general terms are being 
overloaded by a specific extension or no conflicts between the extensions?

It would not be enough, because that supposes the IANA or the DEs need
to deconflict every JSON name etc.. and that would lead to mistakes.


[PK] I don't consider this a big issue. JSON Web Token Claims registry 
works like this in a way more heterogeneous environment.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Extension identifier case-insensitivity #50

[kowalik]

Hi Andrew,

On 10.01.25 17:54, Andrew Newton (andy) wrote:

On Mon, Jan 6, 2025 at 8:53 AM  wrote:

[PK] I do not have very hard feelings about changing this MUST NOT but there will be 
consequences, that MUST NOT will block those extremely marginal  but VALID cases (like 
the one I mentioned above, but maybe some others that do not come to mind now) creating 
possibly more harm, like a very new identifier instead of an editorial case correction. 
Possible harm of "strong" and narrow defined SHOULD NOT seems to be less. This 
goes through DEs review anyway, so they can definitely make the right call.


Unless I misread the thread, you gave a hypothetical scenario but not
an example use case. Can you spell out something more concrete?
Otherwise, I cannot see the value in having both "DeNic" and "DENic"
registered as two separate identifiers.


Maybe hypothetical, maybe not - depending where we land in all 
discussions around camel case, all lowcase etc. If the recommendation 
would turn some of existing extensions to be on the wrong side then 
changing case of an existing registration may be a real scenario.


Anyway I don't want to spend too much time on this issue.

Kind regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Current non-compliant extensions #44

[kowalik]

Hi Andy,

On 10.01.25 17:41, Andrew Newton (andy) wrote:

This one looks like not normative, for sure not for IANA. This exclusion list 
should be then included in the IANA considerations which in fact would have the 
same effect as registering these names as mentioned above.

I think putting these in the IANA considerations section is a good
idea, but I disagree that it is the same as registering them as a
registration must point to a stable reference of the extension.


[PK] Stable reference is in the registry itself - this is where the 
identifiers come from.


On a side note - forbidding registration will also block the original 
authors from registering them to make their registration compliant. A 
bit of paradox.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Extensions: Referrals handling #56

[kowalik]

Hi Andy,

On 14.01.25 17:42, Andrew Newton (andy) wrote:

On Fri, Jan 10, 2025 at 12:35 PM  wrote:


[PK] as indicated above it is not about the extension specifying the
referral.

Understood, but how does the current text not allow this?

I was guided by the interpretation that the text in 4.2 applies to 
referrals specified by a given extension. If the intention of the text 
is that it applies to any referrals, also to those specified elsewhere, 
then it's OK, but maybe giving it an explicit wording in the text would 
make it also very clear to the authors of future extensions.


Kind Regards,

Pawel





smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: A simple test project about using JSContact in RDAP

[kowalik]

Hi Mario,

Thanks for clarification. From draft-ietf-calext-jscontact-profiles-00 I 
interpreted that "localized Card replaces one or more top-level 
properties entirely" means full replacement. Partial replacement would 
be fine with a small issue of removing items, as then all what 
localisation could do is setting null. But I think it's not that wrong 
at the end.


As a side note then - your code does not seem to have any logic of 
looking up main object if it's not existing in the localisation. In 
normal use one would need some logic for this.


In pure context of RDAP the issue is indeed less relevant, as EPP 
servers have 2 distinct copies of data for each int/loc variant, so 
rendering a partial diff out of it would be more of a trouble than help, 
so full replacement variant would be likely the one used anyway.


Kind Regards,

Pawel

On 30.04.25 12:16, Mario Loffredo wrote:



Il 29/04/2025 16:51, kowa...@denic.de ha scritto:


Hi Mario,

This is very straightforward. My concern is in the data consistency 
and redundancy.


You have a very nice example, where just postOfficeBox and 
countryCode are not localised.


And even in this example if the localisation would set different 
countryCode the dataset would be inconsistent, maybe leaving even 
room to some misuse.


If the dataset would contain much more properties which are not being 
localised - tel/fax/email/vatid etc. then there will be a lot of 
redundant data where the implementation would either need to decide 
to close eyes and just trust they have the same content or implement 
some consistency check and error handling. All not nice.


Putting all trust in implementers of object creators (RDAP servers in 
this case) will render errors IMHO.


In the context of RDAP redaction would be more complicated as for 
each object there would be more paths to cover - at least as long as 
JSONPath is in use. However still easier or even possible compared to 
the original patch objects.


[ML] Properties that don't need to be localized are not required to be 
included in the localizations property.


I just updated the test by including the phones property that must not 
be localized per what is defined in rdap-jscontact doc,


In theory, you could even localize only the nested properties that can 
be language-dependent and ignore the others. Looking at the example in 
the test, you could exclude the country code and P.O. information from 
the localizations property.


The choice to localize the entire address reflects the way int/loc 
addresses are represented in EPP.


Honestly, the JSContact localizations property looks to me more 
similar to the EPP PostalInfo element than a data structure providing 
int/loc versions for each of the nested elements.


Additionally, please consider that not only text values can be 
localized in JSContact. For example, you might provide an audio/video 
message in different languages.


Therefore, to provide language-dependent variants along with the main 
information and keep the flexibility of the current proposal for 
localizations, we should implement a "LocalizedObject" type more than 
a "LocalizedString" type (quoting the text in a previous Robert's post).


Best,

Mario


Kind Regards,

Pawel

On 29.04.25 12:40, Mario Loffredo wrote:


Hi,

just made a simple project on GitHub 
(https://github.com/mario-loffredo/TestJSContactProfile) to 
demonstrate how it would be easy to implement the JSContact profile 
for RDAP.


The test at 
https://github.com/mario-loffredo/TestJSContactProfile/blob/master/src/test/java/testJSContactProfileForRDAP/LocalizationsTest.java 
is executed on the JSContact card reported in Figure 1 of 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/.


The uid property has been removed. As for localizations, I think the 
solution described in the JSContact profile document is the best way 
to go, as it preserves the efficiency and flexibility of the 
original proposal and, at the same time, allows implementers to 
handle localizations without having to deal with JSONPointer.The 
test project demonstrates that, using basic Java features (and I 
imagine that the same features are available in all programming 
languages ​​as well), an implementer can deserialize a JSContact 
card including the "localizations" property into a simple data 
structure.


Any feedback is appreciated.

Best,

Mario


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org

--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G.

[regext] Re: Experimental Extensions (was Re: ONE WEEK REVIEW of FINAL proposed revised charter for REGEXT)

[kowalik]

+1 from me as well, WG should be able to work on experimental.

On 29.04.25 16:29, Jasdip Singh wrote:


+1

IIUC, the proposed change, “IETF consensus”, should help not 
circumvent IETF’s standardization process for an experimental work 
that has been adopted by regext, if it comes to that.


Jasdip

*From: *Andrew (andy) Newton 
*Date: *Tuesday, April 29, 2025 at 9:22 AM
*To: *James Galvin , REGEXT Working Group 

*Subject: *[regext] Experimental Extensions (was Re: ONE WEEK REVIEW 
of FINAL proposed revised charter for REGEXT)


Hi all,

The current wording of the proposed charter excludes the working group 
from working on experimental extensions, which has been offered as a 
solution to move some documents forward in the wg. IMHO, disallowing 
experimentation runs counter to the "running code" nature of IETF work 
and takes away from the tools the working group has to create 
interoperable specifications.


The proposed charter has the following paragraphs:

 Proprietary documented extensions and individual submissions 
of informational or
 experimental extensions will follow the expert review process 
as described in the
 appropriate extensions registry. These extension documents 
will not be part of the
 REGEXT working group work or milestones. The working group 
may discuss or advise

 on these documents.

    Extensions that seek standards track status can be suggested 
for WG
    adoption. If accepted by the working group then the 
development of the

    standard may proceed.

I propose the following change to the second paragraph:

    Extensions that seek IETF consensus can be suggested for WG
    adoption. If accepted by the working group then the 
development of the

    standard may proceed.

This change does not exclude experimental status if the working group 
decides that is a good path for a document. It also draws the 
distinction between those documents accepted by the working group in 
contrast to the proprietary extensions mentioned in the first paragraph.


What do people think?

-andy, not the responsible AD for this wg

On 4/28/25 09:48, James Galvin wrote:
> Two weeks ago the Chairs distributed a proposed revised charter and 
opened a review period for the working group.  That review period 
closed yesterday.  Many thanks to those who took the time to review 
the proposal.

>
> Today begins a one week review of the final, proposed revised 
charter.  Everyone should have access and can still leave comments or 
suggest changes to the text.  The review closes on Sunday, 4 May 2025, 
close of business everywhere.

>
> Here is the current, FINAL proposed revised charter:
>
> 
https://docs.google.com/document/d/1ZEqVSc28YoiFJKDKlXgBfLHUSpYKfS1OIIgz4aVBOq0/edit?tab=t.0

>
>
> In consultation with our Area Director, all the comments were 
reviewed.  Almost all were accepted as is, a few were accepted in 
principle and the proposed text was revised to accommodate.  There 
were a couple that were rejected and those should have gotten a 
comment sent to them regarding why the change was rejected.

>
> For ease of reference, here is the current charter of the REGEXT 
working group:

>
> https://datatracker.ietf.org/group/regext/about/
>
> Please note, this revised proposed charter is still subject to IESG 
review.  While this version may represent our consensus, there may 
still be questions and comments to be resolved from the IESG.

>
>
> Thanks again to all who reviewed the proposal. The Chairs believe 
our Charter overall is better now than it was and hopefully you agree.

>
> Antoin and Jim
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: A simple test project about using JSContact in RDAP

[kowalik]

Hi Mario,

This is very straightforward. My concern is in the data consistency and 
redundancy.


You have a very nice example, where just postOfficeBox and countryCode 
are not localised.


And even in this example if the localisation would set different 
countryCode the dataset would be inconsistent, maybe leaving even room 
to some misuse.


If the dataset would contain much more properties which are not being 
localised - tel/fax/email/vatid etc. then there will be a lot of 
redundant data where the implementation would either need to decide to 
close eyes and just trust they have the same content or implement some 
consistency check and error handling. All not nice.


Putting all trust in implementers of object creators (RDAP servers in 
this case) will render errors IMHO.


In the context of RDAP redaction would be more complicated as for each 
object there would be more paths to cover - at least as long as JSONPath 
is in use. However still easier or even possible compared to the 
original patch objects.


Kind Regards,

Pawel

On 29.04.25 12:40, Mario Loffredo wrote:


Hi,

just made a simple project on GitHub 
(https://github.com/mario-loffredo/TestJSContactProfile) to 
demonstrate how it would be easy to implement the JSContact profile 
for RDAP.


The test at 
https://github.com/mario-loffredo/TestJSContactProfile/blob/master/src/test/java/testJSContactProfileForRDAP/LocalizationsTest.java 
is executed on the JSContact card reported in Figure 1 of 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/.


The uid property has been removed. As for localizations, I think the 
solution described in the JSContact profile document is the best way 
to go, as it preserves the efficiency and flexibility of the original 
proposal and, at the same time, allows implementers to handle 
localizations without having to deal with JSONPointer.The test project 
demonstrates that, using basic Java features (and I imagine that the 
same features are available in all programming languages ​​as well), 
an implementer can deserialize a JSContact card including the 
"localizations" property into a simple data structure.


Any feedback is appreciated.

Best,

Mario


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

[Kowalik, Pawel]

+1

Kind regards
Pawel Kowalik 

> Am 01.08.2022 um 15:49 schrieb James Galvin :
> 
> As everyone knows there has been quite some discussion on the mailing list 
> regarding how to implement rdapConformance.  This was a significant topic of 
> discussion at the REGEXT meeting during IETF114.
> 
> Three options were proposed on the mailing list and unfortunately the Chairs 
> do not believe there was a consensus on the mailing list as to how to 
> proceed.  So, the Chairs developed a proposal for how to proceed and 
> presented that at the IETF114 meeting.
> 
> Since all decision must be made on the mailing list, the purpose of this 
> message is to state the proposal and ask for support or objections, similar 
> to how we handle WGLC for documents.  Please indicate your support by 
> replying to this message with a “+1” or explaining any objection you have.
> 
> This CONSENSUS CALL will close in two weeks on 15 August 2022 at close of 
> business everywhere.
> 
> This proposal had consensus during the IETF114 meeting and is summarized as 
> follows.
> 
> 1. Given that both RFC7480 and RFC9083 are Internet Standards, the bar for 
> changes is quite high.
> 
> 2. There is a generally accepted consensus for how rdapConformance is to be 
> used and it is widely deployed today.
> 
> 3. Although any one of the three options could be a reasonable choice, none 
> of them has a broad consensus sufficient to justify changing the Standard.
> 
> 4. The proposal has two parts as follows:
> 
> A. Accept that the RDAP protocol and RDAP Extensions Registry do not directly 
> support versioning of extensions and that both support unique extension 
> identifiers.
> 
> B. Submit Errata to the appropriate RFC in STD95 to harmonize the example 
> usage of the extension identifiers “lunarNIC” and “lunarNIC_level_0” to 
> improve clarity on the uniqueness of identifiers.
> 
> For additional details working group members are referred to the slides used 
> by the Chairs during the discussion and recording of the meeting:
> 
> SLIDES: 
> https://datatracker.ietf.org/doc/slides-114-regext-rdap-extension-identifier-and-rdapconformance/
> 
> RECORDING: https://www.meetecho.com/ietf114/recordings#REGEXT
> 
> Thanks,
> 
> Antoin and Jim
> 
> ___
> 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] WGLC: draft-ietf-regext-rdap-openid-17

[Pawel Kowalik]

Hi,


The discussion is ongoing but I will try to summarise the status.


In the current state the draft is supporting pretty good the use cases 
of RDAP user interacting directly with RDAP server via the browser or 
using command line tools.


The draft is not supporting the use cases of RDAP user interacting with 
RDAP server via web application, neither client side nor server side.


Client side application support can be added pretty straightforward to 
the specification with added language of redirect_uri and state 
(analogue to the same features of OAuth2) and by specifying the 
necessary behaviour in terms of CORS and appropriate Security 
Considerations.


Server side applications are not supported by the current draft and not 
really possible to add the support without a major change to the 
specification. The main issue is the usage of the cookies, which cannot 
be passed cross domain between the front-end doing the authorisation 
with the RDAP server and the back-end doing the actual RDAP API 
interactions.


In my opinion the WG shall get the consensus around whether these web 
application related use-cases shall be supported in order to move 
forward with the WGLC.



Kind regards,

Pawel


Am 04.10.22 um 15:42 schrieb Hollenbeck, Scott:

-Original Message-
From: regext  On Behalf Of James Galvin
Sent: Monday, October 3, 2022 8:40 AM
To: REGEXT WG 
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

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.

REMINDER:

This document is in WGLC and has only received support from its Editor and its
Document Shepherd.

To advance this document we need expressions of support from others to
advance this document to the IESG to be considered for publication as a
Proposed Standard.

WGLC remains open through Monday, 10 October.  This document can not
advance without support.

[SAH] I'm currently having an off-list exchange with someone that might produce 
changes to the draft. I'll encourage that reviewer to provide a summary once 
he's comfortable doing so.

Scott
___
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] WGLC: draft-ietf-regext-rdap-openid-17

[Pawel Kowalik]

Hi Scott,


redirect_uri and state will allow the login flow to finish on a page of 
the web application initiating the login flow, instead of displaying a 
JSON output as the current draft specifies.


The web application user does not expect to see JSON output, rather 
expect to continue interaction with the application, like doing the 
domain query he started with.



Cookie issues:

- for the front-end type of client - with current CORS settings as 
recommended by section 5.6 of RFC7480 (setting "*" for 
Access-Control-Allow-Origin and no Access-Control-Allow-Credentials 
header) is blocking the cross-origin session cookies coming from the 
user agent to the RDAP server, effectively making the use case broken.


- for the back-end type of client - the login session and the session 
cookie is created between the user agent and the RDAP server. This 
cookie will not be passed to the backend system because the web 
application would typically another domain than the RDAP server. In 
effect the backend system won't be able to access protected resources of 
the RDAP server.



Kind Regards,

Pawel

Am 06.10.22 um 14:57 schrieb Hollenbeck, Scott:

Pawel, would you please explain these issues in a bit more detail? For
example, how does adding support for the redirect_uri and state query
parameters help? What do they do? What's the cookie issue?

Scott


-Original Message-
From: regext  On Behalf Of Pawel Kowalik
Sent: Thursday, October 6, 2022 8:22 AM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

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.

Hi,


The discussion is ongoing but I will try to summarise the status.


In the current state the draft is supporting pretty good the use cases of
RDAP
user interacting directly with RDAP server via the browser or using command
line tools.

The draft is not supporting the use cases of RDAP user interacting with RDAP
server via web application, neither client side nor server side.

Client side application support can be added pretty straightforward to the
specification with added language of redirect_uri and state (analogue to the
same features of OAuth2) and by specifying the necessary behaviour in terms
of CORS and appropriate Security Considerations.

Server side applications are not supported by the current draft and not
really
possible to add the support without a major change to the specification. The
main issue is the usage of the cookies, which cannot be passed cross domain
between the front-end doing the authorisation with the RDAP server and the
back-end doing the actual RDAP API interactions.

In my opinion the WG shall get the consensus around whether these web
application related use-cases shall be supported in order to move forward
with
the WGLC.


Kind regards,

Pawel


Am 04.10.22 um 15:42 schrieb Hollenbeck, Scott:

-Original Message-
From: regext  On Behalf Of James Galvin
Sent: Monday, October 3, 2022 8:40 AM
To: REGEXT WG 
Subject: [EXTERNAL] Re: [regext] WGLC:
draft-ietf-regext-rdap-openid-17

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.

REMINDER:

This document is in WGLC and has only received support from its
Editor and its Document Shepherd.

To advance this document we need expressions of support from others
to advance this document to the IESG to be considered for publication
as a Proposed Standard.

WGLC remains open through Monday, 10 October.  This document can not
advance without support.

[SAH] I'm currently having an off-list exchange with someone that might

produce changes to the draft. I'll encourage that reviewer to provide a
summary once he's comfortable doing so.

Scott
___
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/1zU1MYveTuBh9US9H88-

KwanCz9Jm5AUkv3Qpuu9r
bKowPbfig9_o0Wb_b8TEYITFDuWKq3JuH8aOMkNI4nXlp19GH6vgkYD7JMeeBG
a09cR_Sa
OpAxe92RHqwpZRaZhiCsI7QDzc0wt9i6MpMLzHPNxv6kebSP1A2Bd3hb5U4N32J
u4X4pRm

j9aD5rXHgsMO7ZDlsuJkHLnBVBzfMzyyx4lPHpRBsNYfw7-SizhHxsb_s-

Mf9ihZBIN-Oh

6nkmZx/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

___
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/1zU1MYveTuBh9US9H88-
KwanCz9Jm5AUkv3Qpuu9rbKowPbfig9_o0Wb_b8TEYITFDuWKq3JuH8aOMkNI4
nXlp19GH6vgkYD7JMeeBGa09cR_SaOpAxe92RHqwpZRaZhiCsI7QDzc0wt9i6Mp
MLzHPNxv6kebSP1A2Bd3hb5U4N32Ju4X4pRmj9aD5rXHgsMO7ZDlsuJkHLnBVBz
fMzyyx4lPHpRBsNYfw7-SizhHxsb_s-Mf9ihZBIN-
Oh6nkmZx/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

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


___

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

[Pawel Kowalik]

Comment inline

On Thu, Oct 6, 2022 at 8:22 AM Pawel Kowalik  wrote:


In my opinion the WG shall get the consensus around whether these web
application related use-cases shall be supported in order to move
forward with the WGLC.

Can you elaborate on what you mean by "web application"? Do you mean
an application that is not the user-agent?


Either an application running directly in the browser, like SPA, or the 
application running on the server side and just rendered in the browser.


Kind Regards,

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

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

[Pawel Kowalik]

Am 07.10.2022 um 14:49 schrieb Hollenbeck, Scott :










From: regext  On Behalf Of
Pawel Kowalik
Sent: Thursday, October 6, 2022 7:24 PM
To: Andrew Newton 
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17


 




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. 




Comment inline


On Thu, Oct 6, 2022 at 8:22 AM Pawel Kowalik
 wrote: 


In my opinion the WG shall get the consensus around whether these web 
application related use-cases shall be supported in order to move 
forward with the WGLC. 

Can you elaborate on what you mean by "web application"? Do you mean

an application that is not the user-agent? 


Either an application running directly in the browser, like SPA, or the application running on the server side and just rendered in the browser.


[SAH] Let me try to check my understanding: what you’re describing is a situation in which the RDAP client is software running on a web server, right? If so, the RDAP-client-side web server (call it WS1) needs to manage sessions for its users, and the
 web server that’s running the RDAP server (call it WS2) needs to manage sessions for its clients. The challenge here is that the only “client” the RDAP server sees is WS1, and it has no knowledge of WS1’s users. To identify, authenticate, and authorize the
 users of WS1, we need features that support definition of sessions for those users on both WS1 and WS2. Is that correct?
 Not exactly. The users (or the user agent they use to be exact) of WS2 have both the session with WS1 and WS2, just that WS1 cannot access WS2 with the same session because of the isolation by the user agent. The user agent won’t send the session cookie it has with WS2 to WS1 because it would be cross domain.Kind regards Pawel___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - Clients

[Pawel Kowalik]

Hi Mario,

Am 11.10.22 um 16:38 schrieb Mario Loffredo:


Il 11/10/2022 15:04, Andrew Newton ha scritto:

On Tue, Oct 11, 2022 at 8:16 AM Mario Loffredo
 wrote:
my humble opinion is that this document shouldn't deal with any kind 
of RDAP client other than a browser.


Looking at the chapter 1 of this document, but also at chapter 3 and 3.1 
there is no indication of such narrow usage of this specification.


Also  4.2.4.  Clients with Limited User Interfaces indicates other types 
of clients than the browser directly.




At the moment, I disagree with this. Authentication for non-browser
clients can be very useful. GitHub's client is a great example for
anybody who has ever needed Oauth/OpenID at the command line.


Andy, I didn't write that non-browser clients are unuseful.

On the contrary, I was the first here raising the question of how to 
deal with non-browser clients that most likely will issue the biggest 
number of requests to the RDAP servers.


I only expressed my concern about using for non-browser clients the 
same approach used thus far.  IMHO, the classic scheme based on tokens 
fit better in that case while sessions are the best for end users 
operating through a browser.


I can only agree to that concerns and as I understand till version 9 of 
this draft this was in fact the approach.


The browser use case was not supported well but all the others including 
clients other than the browser.


I expected the document should eventually support both therefore I 
raised the concerns about non browser clients not possible.




With regard to GitHub, AFAIK non-browser clients can access a 
repository either through an access token or via SSH key, anyway 
nothing similar to the exchange of a session cookie, right ?


GitHub CLI and other this kind of tools typically use a form of OAuth as 
well and store tokens locally.



Kind Regards,

Pawel

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

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - Clients

[Pawel Kowalik]

Am 12.10.22 um 14:56 schrieb Hollenbeck, Scott:

[SAH] Since the draft already includes text that describes support for two
different types of clients, I'm OK with the idea of adding (or re-adding) text
that describes support for web service clients, too. The challenge is in
deciding how to support those clients.

Pawel, what I had in the earlier versions of the draft worked liked this:

Client requests access, ID, and refresh tokens by sending a query to the RDAP
server.
RDAP server retrieves tokens from the OP and returns them to the client.
The access token can then be passed to the server for use with an RDAP query
by including the encoded token in an HTTP Bearer authorization header.

Does this address the issue?


Yes, this addresses the issue, requires some added elements however.

Keeping the flow as per draft version 17, with farv1_session/login path 
starting the authentication and authorisation, we cannot deliver the 
tokens as a response directly. This flow has to finish with a HTTP 
redirect back to the client which initiated the flow. It requires 
appropriate query parameters redirect_uri and state added to the 
farv1_session/login path.


For the tokens I propose then to add a dedicated path 
farv1_session/tokens which can be queried after successful 
authentication, otherwise 401 error code. CORS requirements need to be 
added here, so that this endpoint can be reached within the same session.




I'm not confident that the token refresh and revocation descriptions in -09
are workable, though. It describes passing the refresh token as a query
parameter; can that work? Can a refresh token be passed in an authorization
header?


I would follow the pattern of RFC 6749 Section 6, so a POST request to 
farv1_session/tokens with refresh_token in 
"application/x-www-form-urlencoded" parameters. Response would then be 
the new set of tokens.


For the token revocation RFC 7009 can be used as-is, all we'd need to 
specify would be the path segment like farv1_token_revocation and add 
signalling if the RDAP server supports it or not in the /help response.


Kind Regards,

Pawel

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

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - Clients

[Pawel Kowalik]

Am 12.10.22 um 19:07 schrieb Hollenbeck, Scott:



For the token revocation RFC 7009 can be used as-is, all we'd need to
specify
would be the path segment like farv1_token_revocation and add signalling if
the RDAP server supports it or not in the /help response.

[SAH] 7009 describes the interaction with the Authorization Server. I assume
the RDAP client would send the refresh token via POST as described above, and
then the RDAP server submits the 7009 revocation request to the authorization
server - right?


Important factor here is that the document shall leave it open whether 
the tokens are issued by the OP or the RDAP server.


The tokens are opaque to the client and this is up to the implementation 
of the RDAP server to forward the tokens from the OP, to exchange them 
or generate own.


From this perspective also the revocation end-point shall be offered by 
the RDAP server as only RDAP server would know what to do to revoke the 
token according to the own implementation.


To keep the solution more flexible we may signal the revocation 
end-point as an URL in the /help path, not as a fixed one.



Kind Regards,

Pawel

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

Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - Clients

[Pawel Kowalik]

Am 13.10.22 um 14:24 schrieb Hollenbeck, Scott

For the token revocation RFC 7009 can be used as-is, all we'd need to
specify would be the path segment like farv1_token_revocation and add
signalling if the RDAP server supports it or not in the /help
response.

[SAH] 7009 describes the interaction with the Authorization Server. I
assume the RDAP client would send the refresh token via POST as
described above, and then the RDAP server submits the 7009 revocation
request to the authorization server - right?

Important factor here is that the document shall leave it open whether the
tokens are issued by the OP or the RDAP server.

The tokens are opaque to the client and this is up to the implementation of the
RDAP server to forward the tokens from the OP, to exchange them or generate
own.

  From this perspective also the revocation end-point shall be offered by the
RDAP server as only RDAP server would know what to do to revoke the token
according to the own implementation.

To keep the solution more flexible we may signal the revocation end-point as
an URL in the /help path, not as a fixed one.

[SAH] I'm still not following. To revoke a token, the RDAP server needs to know who 
issued it (so the revocation endpoint can be found), and it needs the token itself.  How 
does the RDAP server acquire both if all it receives from the client is a path segment 
like farv1_token_revocation? A "default" OP can address the first need, but a 
token still needs to be included in the revocation request.


[PK] Yes, you are right, in order to know which OP shall receive the 
revocation request it has to happen within the same session, so the path 
shall be under /farv1_session path so that RDAP server knows the 
context. The token is submitted with the request as in RFC 7009 - this 
is a POST request with "application/x-www-form-urlencoded" parameters - 
token and an optional token_type_hint. This covers the second issue.


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:


[SAH] This update addresses most of the feedback received during the recent WG 
last call. There are still a few open issues for which I'm hoping to see WG 
discussion:

Thank you Scott.

1. How do we address web service clients?


[PK] I think the elements we need for web service clients were already 
elaborated in the discussion over the version 17.

I'm happy to support with text proposal if needed.


One additional point that appeared in the side discussion is whether 
such client shall be able to request additional claims from the OP.
Currently the specification only allows RDAP server to request claims 
which leaves the web client without such possibility, which in turn may 
end up in a broken experience.
The proposal here is to add a "scope" query parameter to the /login path 
which RDAP server may use to request additional claims from the OP on 
behalf of the client.




2. Are there any security concerns associated with return of the "userID", "iss", and 
"userClaims" members of the "farv1_session" data structure?


[PK] The specification does not foresee any (even optional) 
authentication of the client application. In this sense each client has 
to be treated as a public client.
There is a risk of malicious client obtaining access to those PII data 
because all the user sees in the consent step is RDAP requesting data to 
the OP.
Device flow is in this sense more vulnerable to phishing attacks to 
obtain PII and also access to RDAP data as such.
A countermeasure could be the RDAP server offering an own 
consent/confirmation screen displaying some identifiable information 
about the client requesting access.



3. Anything else I might have inadvertently missed.


[PK] "userClaim" is marked OPTIONAL in 4.1.1 whereas the following 
chapters indicate it is mandatory most of the times:


4.2.3.  Login Response
4.4.  Session Status
4.5.  Session Refresh

I suggested to change:
...response MUST include a "farv1_session" data structure that includes 
a "userClaims" object and a "sessionInfo" object.


to

..response MUST include a "farv1_session" data structure that includes a 
"sessionInfo" object and an optional "userClaims" object.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:


[SAH] This update addresses most of the feedback received during the recent WG 
last call. There are still a few open issues for which I'm hoping to see WG 
discussion:

Thank you Scott.

1. How do we address web service clients?


[PK] I think the elements we need for web service clients were already 
elaborated in the discussion over the version 17.

I'm happy to support with text proposal if needed.


One additional point that appeared in the side discussion is whether 
such client shall be able to request additional claims from the OP.
Currently the specification only allows RDAP server to request claims 
which leaves the web client without such possibility, which in turn may 
end up in a broken experience.
The proposal here is to add a "scope" query parameter to the /login path 
which RDAP server may use to request additional claims from the OP on 
behalf of the client.




2. Are there any security concerns associated with return of the "userID", "iss", and 
"userClaims" members of the "farv1_session" data structure?


[PK] The specification does not foresee any (even optional) 
authentication of the client application. In this sense each client has 
to be treated as a public client.
There is a risk of malicious client obtaining access to those PII data 
because all the user sees in the consent step is RDAP requesting data to 
the OP.
Device flow is in this sense more vulnerable to phishing attacks to 
obtain PII and also access to RDAP data as such.
A countermeasure could be the RDAP server offering an own 
consent/confirmation screen displaying some identifiable information 
about the client requesting access.



3. Anything else I might have inadvertently missed.


[PK] "userClaim" is marked OPTIONAL in 4.1.1 whereas the following 
chapters indicate it is mandatory most of the times:


4.2.3.  Login Response
4.4.  Session Status
4.5.  Session Refresh

I suggested to change:
...response MUST include a "farv1_session" data structure that includes 
a "userClaims" object and a "sessionInfo" object.


to

..response MUST include a "farv1_session" data structure that includes a 
"sessionInfo" object and an optional "userClaims" object.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:


[SAH] This update addresses most of the feedback received during the recent WG 
last call. There are still a few open issues for which I'm hoping to see WG 
discussion:

Thank you Scott.

1. How do we address web service clients?


[PK] I think the elements we need for web service clients were already 
elaborated in the discussion over the version 17.

I'm happy to support with text proposal if needed.


One additional point that appeared in the side discussion is whether 
such client shall be able to request additional claims from the OP.
Currently the specification only allows RDAP server to request claims 
which leaves the web client without such possibility, which in turn may 
end up in a broken experience.
The proposal here is to add a "scope" query parameter to the /login path 
which RDAP server may use to request additional claims from the OP on 
behalf of the client.




2. Are there any security concerns associated with return of the "userID", "iss", and 
"userClaims" members of the "farv1_session" data structure?


[PK] The specification does not foresee any (even optional) 
authentication of the client application. In this sense each client has 
to be treated as a public client.
There is a risk of malicious client obtaining access to those PII data 
because all the user sees in the consent step is RDAP requesting data to 
the OP.
Device flow is in this sense more vulnerable to phishing attacks to 
obtain PII and also access to RDAP data as such.
A countermeasure could be the RDAP server offering an own 
consent/confirmation screen displaying some identifiable information 
about the client requesting access.



3. Anything else I might have inadvertently missed.


[PK] "userClaim" is marked OPTIONAL in 4.1.1 whereas the following 
chapters indicate it is mandatory most of the times:


4.2.3.  Login Response
4.4.  Session Status
4.5.  Session Refresh

I suggested to change:
...response MUST include a "farv1_session" data structure that includes 
a "userClaims" object and a "sessionInfo" object.


to

..response MUST include a "farv1_session" data structure that includes a 
"sessionInfo" object and an optional "userClaims" object.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

I'm really sorry for flooding the list. Connection issues in the train 
made my email client send it 3 times unnoticed.


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott:
[SAH] If the PII data you're referring to is what's included in the 
userClaims, this might not be an issue if the claims aren't returned, 
correct? 


Correct


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Hi Scott,

Am 20.10.22 um 21:02 schrieb Hollenbeck, Scott:

Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott:

[SAH] If the PII data you're referring to is what's included in the
userClaims, this might not be an issue if the claims aren't returned,
correct?

Correct

[SAH] Does anyone object to removing the "userClaims" object from the
"farv1_session" data structure?


[PK] IMHO it's not the best idea to remove userClaims completely.

PII claims can be useful for UX, there are also non PII claims which can 
be returned,
like the Specialized Claims for RDAP, which won't be possible at all if 
we remove userClaims.
The provisions of making userClaims optional, under the policy of the 
RDAP server
and adding security considerations are in my eyes the right measures to 
address the concerns.


We also didn't complete the discussion about the web clients, where we 
can also minimise the risks

by adding a possibility of confidential clients if necessary.

Kind regards,

Pawel

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

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

[Pawel Kowalik]

Am 21.10.22 um 15:46 schrieb Hollenbeck, Scott

[SAH] OK, if we keep the "userClaims" I probably need to add text to the 
Security Considerations section. How about this:

"Some of the responses described in this specification return information to a client from an 
RDAP server that is intended to help the client match responses to queries and manage sessions. 
Some of that information, such as the "userClaims" described in Section 4.1.1, can be 
personally identifiable and considered sensitive if disclosed to unauthorized parties. An RDAP 
server operator SHOULD develop policies for information disclosure to ensure that personally 
identifiable information is disclosed only to clients that are authorized to process that 
information."


+1

Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 26.10.22 um 15:48 schrieb Mario Loffredo:

[ML] Before going into detail with technical aspects, think we should 
address some privacy implications connected with the following sentence:


RDAP server SHOULD merge the scopes requested by the client with the
   scopes needed for authorization purposes when building an
   authorization request to OP.

Since the authorization requests would come from the RDAP server 
(acting as a registered OpendID client), the request for consent would 
be for processing claims by the RDAP server. Hence, only the RDAP 
server should be authorized to process the requested claims. Correct?


In addition, IMO the following aspects related to GDPR should be 
considered:


- The RDAP server would be entitled to process PII under the consent 
lawful basis but the RDAP client wouldn't be allowed to leverage such 
a basis for its own PII processing.


- Usually, domain registries have a web page showing their own Data 
Protection Policy. In the case where the RDAP server could process 
PII, the DPP should state (more or less) that the RDAP server 
processes PII only for making access control decision and removes it 
at the end of an authenticated session. The DPP should also ensure 
that PII is not revealed unintentionally to other parties.
For that said, can't see how such a DPP could cover PII processing by 
other application than the RDAP server.



What's your opinion?

[PK] The text was proposed in the way which does not exclude certain 
valid use-cases but still allows the RDAP server to set its own policy 
on sharing data.


This is clear that RDAP server is acting as sort of Identity Provider 
towards its clients, so the similar considerations about data sharing 
shall apply. RDAP server may ask the user for the consent about sharing 
PII as well, decision is clearly by the RDAP server operator.


The proposal is also not obliging RDAP server to obey to the scope 
request from the RDAP client and same time not mandating forwarding any 
data to the client.


But if the RDAP server operator is comfortable to do so the protocol 
allows for that as well.



One reason why I put confidential clients as an open point is that 
currently only supporting public clients which are not authenticated by 
any way means that RDAP server has no means to apply different policies 
to registered trusted clients. Currently all are same so likely the 
least privileged policy would always apply, meaning no PII shared.


A way forward could be to indicate option for confidential clients but 
leaving the details up to implementation. The other option is to propose 
also a standard way of client authentication within this draft.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 27.10.22 um 14:11 schrieb Hollenbeck, Scott:



1. How do we address web service clients?



[PK] Please find attached my draft on Web Service Clients. Most of it is
based
on the concepts of the version 9. Scope "feature" is also included in the
proposal.

[SAH] I've been testing the proposed additions with my functionally-limited
RDAP server. I've found two minor things so far:

The tokens described in Section 4.2.5.2.1 should be placed in a named data
structure. "farv1_tokens" could work.

As described in RFC 6749, OP support for refresh tokens is OPTIONAL. As such,
return of the refresh_token should be OPTIONAL.


[PK] True. Good catch. I checked again in RFC 6749 and OIDC core and 
this is the correct setup:


   access_token REQUIRED.
   token_type REQUIRED.
   expires_in RECOMMENDED.
   refresh_token OPTIONAL

id_token is a MUST element in OIDC core, but assuming our discussion 
about PII, which can be present in ID token as well I think this one 
should be OPTIONAL and up to RDAP server policy.


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Am 28.10.22 um 11:35 schrieb Mario Loffredo:
[PK] The text was proposed in the way which does not exclude certain 
valid use-cases but still allows the RDAP server to set its own 
policy on sharing data.


This is clear that RDAP server is acting as sort of Identity Provider 
towards its clients, so the similar considerations about data sharing 
shall apply. RDAP server may ask the user for the consent about 
sharing PII as well, decision is clearly by the RDAP server operator.


[ML] Doesn't make sense to me that the RDAP server could operate as an 
IdP proxy for RDAP clients. It's already a bit weird that in this 
model the RDAP server acts simultaneously as a Relying Party and a 
Resource Server but I admit that, when the RDAP client is a browser, 
the RDAP server is the only intermediary application between the end 
user and  the IdP.


Instead of making the RDAP server more complex, the easy way is that, 
if an RDAP client needs PII claims for providing the end user with a 
better UX or for any other purpose, it should register with an IdP and 
ask those claims to that IdP under the end user consent.


[PK] There is quite relevant drawback from this scenario, that there is 
no assurance the identity provided to the RDAP client by the IdP would 
be the same as the one used towards the RDAP server if there is no 
relation. An IdP may hold more than one identity of the same user and 
offer account selection in the authorization step.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Hi Mario,

Am 28.10.22 um 16:36 schrieb Mario Loffredo:


[PK] There is quite relevant drawback from this scenario, that there 
is no assurance the identity provided to the RDAP client by the IdP 
would be the same as the one used towards the RDAP server if there is 
no relation. An IdP may hold more than one identity of the same user 
and offer account selection in the authorization step.



[ML] Are you meaning that the two accounts are related to the same 
user_id? AFAIK, one can use the same user_id (e.g. the mail) for 
signing up with different IdPs. Never heard before it happens within 
the same IdP.


[PK] I was rather referring to 2 different user_ids at the same IdP. In 
this case if the authorization is done unrelated from the RDAP client 
and RDAP server, there is a possible mismatch. Not very likely, but 
possible. There are also other cases to consider, where a mis-configured 
RDAP server would choose to authenticate the user with wrong IdP etc.
Anyway, even admitting the unusual case that an end user could select 
two different identities in two close authentications, why should the 
related PII be absolutely the same if they are used for two different 
purposes?


[PK] I don't want to go into discussion whether the purposes are the 
same or not, as these are policy questions which may have different 
answers for each setup RDAP Client / RDAP Server / IdP. I see a valid 
use case for RDAP client to have some level of information about the 
user who queried the RDAP server. Especially "rdap" scope is relevant to 
RDAP client as it determines which of the query parameters defined in 
Section 4.3 can be used within the session not risking 403 responses.




Apart from that, based on my interpretation of GDPR, a generic 
third-party client application processing the PII coming from the RDAP 
server as claims should be authorized by the end user through a 
specific request for consent.


[PK] I would stay away from any interpretation of GDPR in context of 
technical protocol. The protocol as proposed allows RDAP server to apply 
any policy it find appropriate, including not sharing any data at all, 
sharing some or all data without or with consent. It is very alike 
OpenID core Section 3.1.2.4. which does not mandate any specific way of 
authorization and includes "establishing consent via conditions for 
processing the request or other means (for example, via previous 
administrative consent)" which is exactly what server policy defines.


My only concern is that without an option for confidential clients the 
choice of options when defining the policy would be limited by the 
technical capability of the protocol, because each policy will need to 
deal with a case of sharing data to potentially unknown party.




This is because the request for consent from the Authorization Server 
regards only the server processing.


BTW, if "scope" is optional, should the farv1_openidcConfiguration 
object include a "scopeSupported" property?


[PK] Agreed. I would define it as a list of strings scopes_supported, 
same as RFC8414.



Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Hi Mario,

Am 29.10.22 um 16:41 schrieb Mario Loffredo:




Apart from that, based on my interpretation of GDPR, a generic 
third-party client application processing the PII coming from the 
RDAP server as claims should be authorized by the end user through a 
specific request for consent.


[PK] I would stay away from any interpretation of GDPR in context of 
technical protocol. The protocol as proposed allows RDAP server to 
apply any policy it find appropriate, including not sharing any data 
at all, sharing some or all data without or with consent. It is very 
alike OpenID core Section 3.1.2.4. which does not mandate any 
specific way of authorization and includes "establishing consent via 
conditions for processing the request or other means (for example, 
via previous administrative consent)" which is exactly what server 
policy defines.


[ML] IMO you are not allowed to stay away. I mean, you should address 
the potential privacy implications of one single consent authorizing 
PII processing for two different purposes by the client and the 
server. Beside GDPR, Section 5.2.3 of RFC6973 states that secondary 
use defined as "the use of collected information about an individual 
without the individual's consent for a purpose different from that for 
which the information was collected" is a potential privacy threat to 
avoid or mitigate.


Given that usually a public RDAP client is unknown to the RDAP server 
and it can't leverage other lawful basis to legitimize its PII 
processing, my understanding of that statement is that the draft 
should declare somewhere (Privacy Considerations ?) that an additional 
consent is required for public clients. With regard to confidential 
clients, one consent could be sufficient (am not completely sure) 
assuming that all the purposes for PII processing are explicitly 
declared in the server's DPP and, presumably, all of them are 
regulated by contract.


[PK] The current draft allows the RDAP server to add any interactive 
step in between RDAP "login" request and the response, so if needed RDAP 
server MAY add a second consent according to own policy and legal 
requirements. I agree that 2 consents are not the best possible UX, but 
keeping it open for RDAP server operator to decide is for me the best 
option as only the RDAP server operator knows its policy and legal 
requirements.
We may add some text around it to 3.2.1 (as an optional step in the 
process) and/or 4.2 to give implementers a clear indication of this 
consideration to take when implementing the server. A separate "Privacy 
Considerations" section is another possible approach. @Scott, what would 
you suggest?






My only concern is that without an option for confidential clients 
the choice of options when defining the policy would be limited by 
the technical capability of the protocol, because each policy will 
need to deal with a case of sharing data to potentially unknown party.




This is because the request for consent from the Authorization 
Server regards only the server processing.


BTW, if "scope" is optional, should the farv1_openidcConfiguration 
object include a "scopeSupported" property?


[PK] Agreed. I would define it as a list of strings scopes_supported, 
same as RFC8414.
In that case, I expect that the empty list will be allowed meaning 
that the scope parameter is unsupported.


[PK] RFC8414 defines it like this    scopes_supported RECOMMENDED.  JSON 
array containing a list of the OAuth 2.0 [RFC6749] "scope" values that 
this authorization server supports.
  Servers MAY choose not to advertise some supported scope values 
even when this parameter is used.


With this definition an empty list may also mean the parameter is 
supported but the server does not specify its allowed values. RFC6749 
also does not have to cope with "scope" not supported as it is a 
mandatory parameter in OAuth2.


We may take a guidance of OpenID Connect Discovery, where 2 server 
metadata items are used in analog case for claims parameter: 
claims_parameter_supported (bool) and claims_supported (list of strings).


So for our case it would be scope_parameter_supported and scopes_supported.


Kind Regards,

Pawel



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

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

[Pawel Kowalik]

Hi,


If anyone is interested in discussing this draft and the current issues 
in more depth than than the WG session time would allow on Thursday 
Scott and I will be setting up a public side meeting during IETF 115.



Wednesday 9 November 16:30 - 17.00 (UTC +0) in Richmond 6.

Online Link 
https://us02web.zoom.us/j/82146104492?pwd=R2x3K0FjQjNmZjl4bmlMeGZWdVNOUT09



Kind Regards,

Pawel

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

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

[Pawel Kowalik]

Hi Mario,

Am 07.11.22 um 11:27 schrieb Mario Loffredo:

I'm very busy Wednesday but, hopefully, I should be free for that time.


Great you can make it.

After a quick reading, a first big doubt from my side is about what is 
stated in section 4 regarding "redirect URIs".

Browser-based applications:
*  MUST Register one or more redirect URIs, and use only exact
   registered redirect URIs in authorization requests

Now, it's clear to me that, in the OpenID model we are working on, the 
RDAP server acts as an RP and is the one submitting requests to th AS 
but it can't use a fixed set if redirect_uri values.


Yes, the security considerations part is still open. Applicability 
mostly depends on whether there are confidential and/or registered 
clients or not. If clients are anonymous there are certain risks related 
to the redirect_uri, which can only to some degree be mitigated.


Kind Regards,

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

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

[Pawel Kowalik]

Hi Marc,

Great point about the mobile app. This was not yet discussed and I must 
admit I don't have a lot of practical experience in this area.


I don't think the CLI use-case would be the fitting one, as you won't 
get the best experience with the device flow in the web app, unless you 
are fine with your user copy-pasting the code in the authorization flow 
to the IdP page. There was a very good presentation today in the OAuth 
group about it, along the lines "don't use multi-device flows on the 
same device" and I think there is a point about it.


In my eyes a mobile app is more like a web app. If I understand how the 
mobile app can be built, it would trigger the authorization flow either 
with a built-in browser widget, or trigger the OS-default browser for 
that. Not 100% sure about the first scenario, but for the second it 
would be absolutely given that the app won't get access to the cookies 
set in the browser session, therefore breaking the flow. The only 
exception are the apps being actually SPAs running in a browser, then 
it's the same as a browser app - just no clue how the cookies are 
handled: same-site or cross-site, but likely you can control it in your app.


Kind Regards,

Pawel

Am 09.11.22 um 18:26 schrieb Marc Blanchet:
Sorry I was not able to attend. But reading the slides, I just want to 
make sure the mobile app RDAP client is properly taken into account. I 
think this is the « CLI » use case described, but just want to make 
sure we properly cover the mobile app RDAP client (I wrote one… and 
intend to implement openid)


Regards, Marc.


Le 9 nov. 2022 à 18:09, Pawel Kowalik  a écrit :

Hi,


Thanks for the participation in the meeting today.

There are not yet any conclusions, which would be discussed in the WG 
meeting tomorrow and likely after in the mailing list.


Slides with the current status and possibilities to move forward are 
attached.



Kind Regards,

Pawel



Am 07.11.22 um 13:33 schrieb Pawel Kowalik:


Hi Mario,

Am 07.11.22 um 11:27 schrieb Mario Loffredo:

I'm very busy Wednesday but, hopefully, I should be free for that time.


Great you can make it.

After a quick reading, a first big doubt from my side is about what 
is stated in section 4 regarding "redirect URIs".

Browser-based applications:
*  MUST Register one or more redirect URIs, and use only exact
   registered redirect URIs in authorization requests

Now, it's clear to me that, in the OpenID model we are working on, 
the RDAP server acts as an RP and is the one submitting requests to 
th AS but it can't use a fixed set if redirect_uri values.


Yes, the security considerations part is still open. Applicability 
mostly depends on whether there are confidential and/or registered 
clients or not. If clients are anonymous there are certain risks 
related to the redirect_uri, which can only to some degree be mitigated.


Kind Regards,

Pawel

Status.pdf>___

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___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

[Pawel Kowalik]

Am 09.11.22 um 18:47 schrieb Marc Blanchet:


There was a very good presentation today in the OAuth group about it, 
along the lines "don't use multi-device flows on the same device" and 
I think there is a point about it.


In my eyes a mobile app is more like a web app.

Yes. It is an http client, and can do whatever with its http 
connections: cookies, sessions, etc...


Is the app able to share the cookie jar with the browser widget 
triggered to make the authorization flow? Otherwise the browser widget 
would do the login but your app won't get the cookies to continue with 
the same logged in session.


Kind Regards,

Pawel


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

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

[Pawel Kowalik]

Hi,

I would opt to work on the option 2, at least to the point we can see 
how much both types of clients have in common and how much do they go 
split ways.


Based on this the WG could take more educated decision whether to break 
it into 2 drafts or remain with one.


Kind Regards,

Pawel


Am 14.11.22 um 15:09 schrieb Hollenbeck, Scott:

We need to decide what to do with draft-ietf-regext-rdap-openid and web
service clients. Our choices:

1. Finish the draft as-is, noting that it's limited to clients that can
implement OpenID Connect flows and can process session cookies. This implies
that we need another draft to describe OAuth-like token processing for clients
and servers that need that capability.

2. Add text to the draft that describes OAuth-like token processing for
clients and servers that need that capability.

My preference is for the first option.

Scott

___
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

[regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik]

Hi,


As an action item after IETF 115 I reviewed 
draft-ietf-regext-rdap-redacted-09 before WG LC and have the following 
questions / remarks:


Section 3, first paragraph:

> Redaction in RDAP can be handled in multiple ways.  The use of
> placeholder text for the values of the RDAP fields, such as the
> placeholder text "", MUST NOT be used for redaction.  A
> placeholder text value will not match the format requirements of each
> of the RDAP fields and provides an inconsistent and unreliable
> redaction signal.

Is the normative language adequate here? Firstly, I am not sure if the 
text can be well understood.
Does it mean that use of a fixed placeholder is prohibited, or any 
placeholder?
I can imagine a way of using placeholders, which do not necessarily 
break the format requirements,
therefore the second sentence shall not categorically tell "will not 
match" as it may not be even true.


My proposal would be to use SHOULD NOT instead of MUST NOT. It can be 
useful for the servers willing
still to support clients not implementing this extension in the 
transition period to populate fields with placeholders instead of just 
empty/missing fields.


---

Section 3, second paragraph:

The whole paragraph deals with particularities of redacting jCard with 
some very specific guidelines and examples.
Wouldn't it be more and future proof to have a general statement that 
redacting the data MUST NOT break the underlying data format?
The same remark applies then later to 3.2. with normative language for 
jCard redaction.


---
4.2.  "redacted" Member

The whole "redacted" member and especially the "path" and 
"replacementPath" members
shall allow the client to recognise parts of the JSON response which 
have been transformed

in the process of redaction.

Here some interesting questions:
- do the paths refer to the object before or after the redaction?
- if the paths refer to the object before the redaction, how should the 
client be able to interpret the path if not having access to this 
object, especially the JSONPath may even match multiple paths, e.g. from 
result and the path the client cannot digest which paths have been 
really removed? More to that each redaction step is actually 
transforming the object, so the order of redaction is also relevant in 
this case. Normalized Paths from JSONPath allow "reversing" the process 
from the result object if the order of redaction is being held.
- if the paths refer to the object after the redaction, likely the path 
member should be OPTIONAL not not required for redaction by removal or 
replacement, because in this case the object likely does not exist in 
the result object


With Section 5 being not-normative and about processing by the server, 
the draft should similarly include considerations for processing of the 
responses by the clients.


---

"pathLang" member

What is the rationale behind introducing this extension point? Right now 
the RFC specifies only one language, which is default one. If there will 
be an additional one I would expect it added by a RFC also answering 
some questions how to transition from one path language to another. 
Without any way for the client to express which "pathLang" it would like 
to get response with, the server would only be able to migrate after all 
clients support both formats, otherwise risking some clients to break.
And if this "pathLang" member is to persist, shouldn't there be IANA 
registry for allowed values, so that the clients have an ide what to 
implement?


---

3.1.  Redaction by Removal Method

> The Redaction by Removal Method MUST NOT be used to remove a field
> using the position in a fixed length array to signal the redacted
> field.  For example, removal of an individual data field in jCard
> [RFC7095] will result in a non-conformant jCard [RFC7095] array
> definition.

Is the first normative sentence meant to apply to every case, or just 
the case where removal of such field would render an invalid jCard?
I think there is quite legit way or removing whole objects by position 
in a fixed length array, like "path": "$.entities[0]" which should be 
still allowed.


---

6.2.  JSON Values Registry

Registry for "redacted name" allows to identify what has been removed 
without interpreting it from the path member. This is of a great 
benefit, looking at the difficulties of interpreting the "path" member I 
mentioned above.
However, semantically, isn't this registry rather defining the members 
and objects of RDAP response in a general sense? I mean "Registry Domain 
ID" means the same no matter if in context of redaction or in context of 
RDAP response and actually IMHO we should make sure it means the same in 
any other RDAP context it would be used in the future. IMHO this IANA 
registry shall be a generic one defining labels to the information 
pieces in RDAP responses.


---

Examples with entity role indexing.

The draft has many examples of the kind 
$.entities[?(@.roles[0]=='registra

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

[Pawel Kowalik]

Hi Scott,

Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott:

[SAH] Based on the testing you and I've been doing, we already know that web
service clients require token processing features that aren't currently
specified. That's fixable; earlier versions of the draft included text that
was demonstrated to work. However, we also know that login processing will be
a problem if the client-side application can't process third-party cookies.
That might be more difficult to overcome. What do you have in mind?


I think for web clients we need to let the clients do the OAuth2 flow on 
their own, receive tokens from the IdP directly and then use the token 
to interact with the RDAP server.
RDAP server would remain stateless and session-less in the role of 
OAuth2 resource server when tokens are in use.
The draft would be limited to defining profile of the OAuth2 protocol to 
maintain interoperability (scopes / claims or flows / endpoints that 
need to be supported etc.) as well as the discovery part of the IdP 
(likely just a property add to what we have in /help already).
This is different to our approach so far, when we tried to maintain 
cookie-based session, letting RDAP server to act as Relying Party, and 
same time operate with tokens as if it were a Resource Server.


Kind Regards,

Pawel


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

Re: [regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-15.txt

[Pawel Kowalik]

Hi Mario,


I reviewed this draft and have 2 questions:

- Reverse search property - the draft defines a fixed list of 4 search 
properties. Do I understand it right that adding some other reverse 
search properties, which are to be interoperable, would require a new 
RFC? Wouldn't it be better to have an IANA registry for the search 
properties? Actually JSON Values Registry for "redacted name" proposed 
in draft-ietf-regext-rdap-redacted has almost the same semantic meaning: 
giving labels to certain JSONPaths.


- Discovery - how should the client learn which reverse search 
properties are supported? Even those 4 defined in the draft are a SHOULD 
requirement, so do not have to be supported. I see this particular issue 
was discussed on the mailing list 
https://mailarchive.ietf.org/arch/msg/regext/dgdPRRnQbWNhL0VVa_dq7xM-a5M/ 
but there was no continuation/conclusion.


Kind regards,

Pawel


Am 15.11.22 um 08:57 schrieb Mario Loffredo:


Hi all,

as you may note from the change log and diff tool, I have made a 
couple of arrangements to the document:


- Have moved RFC6973 from Normative to Informative References because 
it is an Informational RFC. I apologize if I missed this mistake 
before WGLC.


- Have removed the reference to rdap-openid . The reference was used 
in the Appendix as a mere hint to a possible way to specify a purpose 
for a reverse search query and, IMO, its removal don't change the 
meaning of the sentence where It is cited. After the discussion at 
last aside meeting at IETF, it seemed to me appropriate to remove that 
reference to avoid a dependency from a document in deep progress. The 
only open dependency left is on jsonpath-base which is expected to end 
the evaluation process shortly.


Both the changes have been agreed with the shepherd.

Best,

Mario



 Messaggio Inoltrato 
Oggetto: 	[regext] I-D Action: 
draft-ietf-regext-rdap-reverse-search-15.txt

Data:   Mon, 14 Nov 2022 06:13:16 -0800
Mittente:   internet-dra...@ietf.org
Rispondi-a: regext@ietf.org
A:  i-d-annou...@ietf.org
CC: regext@ietf.org




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


Title : Registration Data Access Protocol (RDAP) Reverse search 
capabilities

Authors : Mario Loffredo
Maurizio Martinelli
Filename : draft-ietf-regext-rdap-reverse-search-15.txt
Pages : 14
Date : 2022-11-14

Abstract:
The Registration Data Access Protocol (RDAP) does not include query
capabilities for finding the list of domains related to a set of
entities matching a given search pattern. In the RDAP context, an
entity can be associated with any defined object class. Moreover,
other relationships between object classes exist and might be used
for providing a reverse search capability. Therefore, a reverse
search can be applied to other use cases besides the classic domain-
entity scenario. This document describes an RDAP extension that
allows servers to provide a reverse search feature based on the
relationship defined in RDAP between an object class for search and
any related object class. The reverse search based on the domain-
entity relationship is treated as a particular case.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-15


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

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


--
Pawel Kowalik
Head of Product Management
--
DENIC eG, Kaiserstraße 75 - 77, 60329 Frankfurt am Main, GERMANY
E-Mail:pawel.kowa...@denic.de, Fon: ‭+49 173 3087096‬
https://www.denic.de

Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler
Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am 
Main

Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13, 
Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch 
DENIC finden Sie unterhttps://www.denic.de/datenverarbeitung-allgemein/
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

[Pawel Kowalik]

Hi Scott,

Am 15.11.22 um 17:54 schrieb Hollenbeck, Scott:

[...]
A "pure OAuth2" solution is probably way more warrant of future, IMHO.

Marc.

[SAH] ...but it's not OpenID Connect, which is the focus of the current draft.
Incorporating these concepts into the current draft could mean significant
change to generalize from "Federated Authentication for the Registration Data
Access Protocol (RDAP) using OpenID Connect" to "Federated Authentication for
the Registration Data Access Protocol (RDAP)" or "Federated Authentication for
the Registration Data Access Protocol (RDAP) using ". I'm not
opposed to generalization if it produces a more complete specification, BUT:

OAuth doesn't do identification and authentication [1]. A "pure OAuth2"
solution would require *something else* to provide identification and
authentication. What can we use?


[PK] I think "OpenID Connect" aspect should remain. My focus was more on 
the flow,
where RDAP client would interact with IdP directly instead of letting 
RDAP server to act as RP.
OAuth2 flows I mentioned are generally the same for OpenID and OAuth2 
therefore one does not exclude the other.
But you are right, we should be speaking about OpenID Connect rather 
than pure OAuth2 without identity part.


When the identity is concerned I think the important consideration is 
whether we strive the model with the Authorization Server
as and integral part of an RDAP server infrastructure (inside the same 
security domain), which can use OpenID Connect to authenticate users via 
other IdPs
(a.k.a. Federated Identity) - in this case we only need to focus on the 
interfaces and flows between RDAP client and RDAP server
and RDAP client and Authorization Server. The integration between the 
Authorization Server and RDAP server would be then left out to the RDAP 
server operator.


If we also consider "any IdP / OAuth2" server directly making 
authorization for the RDAP server, then we would
also need to specify the interface between the RDAP server and the 
Authorization server.


I would like to hear other voices from the WG whether "any IdP / OAuth2" 
is useful to define.


Kind Regards,

Pawel

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

Re: [regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-15.txt

[Pawel Kowalik]

Hi Mario,

My feedback below.

Am 15.11.22 um 19:58 schrieb Mario Loffredo:


Hi Pawel,

thanks a lot for your review.

Please find my comments inline.

Il 15/11/2022 17:28, Pawel Kowalik ha scritto:


Hi Mario,


I reviewed this draft and have 2 questions:

- Reverse search property - the draft defines a fixed list of 4 
search properties. Do I understand it right that adding some other 
reverse search properties, which are to be interoperable, would 
require a new RFC? Wouldn't it be better to have an IANA registry for 
the search properties? Actually JSON Values Registry for "redacted 
name" proposed in draft-ietf-regext-rdap-redacted has almost the same 
semantic meaning: giving labels to certain JSONPaths.


[ML] The document allows the definition of custom reverse search 
properties that are related to response extensions.


A server that includes additional fields in its objects in accordance
with the extensibility provisions of section 6 of [RFC7480] MAY
support the use of those fields in search conditions, in the same way
as for the search conditions defined in this section.

The 4 properties listed in the document match the recommendation 
presented in Section 6 and cover the relationships between the three 
searchable resource types currently available and the only possible 
related resource type (i.e. entity) for which a reverse search 
property hasn't already been defined (see. nsLdhName and nsIp for 
domain-nameserver relationship).


Hence, the definition of further interoperable reverse search 
properties based on other relationships is deferred to other documents 
introducing new resource types (either searchable or related).


That said, a specific registry could certainly provide a centralized 
list of reverse search properties thus improving interoperability.


Each entry in the registry could contain the following fields:

- Searchable resource type

- Related resource type

- Property name

- RDAP property path

- Reference

Do you agree ?


[PK] Yes, I would support this.


Is there any other proposal from everyone else?

- Discovery - how should the client learn which reverse search 
properties are supported? Even those 4 defined in the draft are a 
SHOULD requirement, so do not have to be supported. I see this 
particular issue was discussed on the mailing list 
https://mailarchive.ietf.org/arch/msg/regext/dgdPRRnQbWNhL0VVa_dq7xM-a5M/ 
but there was no continuation/conclusion.


Have used "SHOULD" because RDAP operators may support some of them, 
not all.


WIth regard to the discussion, guess the conclusion was subordinated 
to the outcomes of the other discussion about the extension identifiers.


Surely, we could quickly resume the discussion on that point.

I would suggest two possible solution:

1) Simply extend the help response with the array of supported reverse 
search properties . Each object of the array should include as many 
members as the registry fields. The first free fields should be 
required while "RDAP property path" and "reference" could be set only 
for custom properties (i.e not included in the registry) .


2) Follow Tom's approach of having different metadata endpoints. In 
this case, the first two fields would be omitted and only "property 
name" would be required.


[PK] I will be more inclined to support the first option with the help 
response. This was also the approach taken in the RDAP OpenID draft so 
it would offer some consistency between RDAP responses.



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

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik]

Hi James,

See my feedback below.

Am 15.11.22 um 21:15 schrieb Gould, James:

[...]

JG - The use of placeholder values for redaction is prohibited based on the second normative 
sentence.  The normative language is needed to implement the redaction defined by the RDAP 
extension.  I agree that stating "A placeholder text value will not match" is too strong 
and needs to be changed to "A placeholder text may not match".  This will be changed in 
the next version of the draft.

[PK] Yes, the changed text is way better.


 My proposal would be to use SHOULD NOT instead of MUST NOT. It can be
 useful for the servers willing
 still to support clients not implementing this extension in the
 transition period to populate fields with placeholders instead of just
 empty/missing fields.

JG - I understand that there may be a transition period to fully implement the 
RDAP extension as will be the case of any RDAP extension that standardizes a 
crosscutting feature like redaction, but weakening the normative language from 
MUST NOT to SHOULD NOT misses the purpose of the RDAP extension and will result 
in potentially long running interoperability issues.


[PK] Looking at the Abstract and the Introduction of the draft it reads 
"This document describes an RDAP extension for explicitly identifying 
redacted RDAP response fields, using JSONPath as the default expression 
language.". I see a clear focus on "identify", whereas such strong 
normative language actually influences the way the redaction is done. I 
don't think this should be the main focus of this draft and a bit softer 
SHOULD allows to align servers to the best practice without a dilemma if 
one can use the rdapConformance "redacted" even if placeholders are in 
use for whatever reason. Placeholders are perfectly fitting the 
"Redaction by Replacement Value Method", so also fitting the draft.



[...]

JG - jCard is currently used in RFC 9083 and the specifics of handling redaction of jCard 
is an important concept that needs to be covered.  The "Redaction by Empty Value 
Method" is needed because of jCard.  I believe the combination of jCard being used 
in RFC 9083 and the definition of a redaction method to support jCard warrants providing 
the detail.


[PK] Fine


[...]
JG - The path refers to the object before the redaction for the Redaction by 
Removal Method, since the RDAP field was removed.  In this case the path points 
to where the RDAP field would have been.  The path refers to the object before 
and after the redaction for the Redaction by Empty Value Method, since the RDAP 
field exists but has been set to an empty value.  The path refers to the object 
before the redaction for the Redaction by Replacement Value Method, while the 
replacementPath refers to the object after the redaction, since it points to 
the replacement JSON field.  Right, requiring the path to a non-existent JSON 
fields in the case of the Redaction by Removal Method and the Redaction by 
Replacement Value Method consequently requires the client to validate the 
JSONPath expression using a non-redacted RDAP response,, which the client does 
not have.  Having the JSONPath for where the field would have existed may be 
useful for a client, but they would need to generate the non-redacted response.


[PK] It would be of a great value to describe to which object the path 
refers to to make it clear for the implementers.
Maybe even worth considering to have 2 distinct members "originalPath" 
and "responsePath" where each one is clearly defined to be referring to 
a source or a result object respectively.



I don't oppose setting the "path" to OPTIONAL but with normative language 
specifying that it MUST be included when the JSON field does exist in the redacted 
response.  Do you agree with this?

[PK] Yes, I would support that.
   



 With Section 5 being not-normative and about processing by the server,
 the draft should similarly include considerations for processing of the
 responses by the clients.

JG - Yes, Section 5 provides non-normative considerations for the server.  Offhand I believe considerations 
#2 "Validate a JSONPath expression using a non-redacted RDAP response" could be applicable when a 
client receives a response that includes the "path" expression for the Redaction by Removal Method 
and the Redaction by Replacement Value Method, per the feedback above, but the client would need to generate 
a template non-redacted RDAP response based on the "path" expressions.  Do you agree with this 
possible consideration, and do you have any other considerations that should be considered?  If there are 
useful client considerations, they certainly can be added.


[PK] The approach with a "template non-redacted RDAP response" may be 
interesting to take a deeper look into.
My first impression would be that such fits-all template may be 
difficult to build, accounting that an entity may have multiple roles 
assigned or that vCard all

Re: [regext] Web Service Client Flow

[Pawel Kowalik]

Hi Scott,

Am 17.11.22 um 15:47 schrieb Hollenbeck, Scott:

Is this a correct sequence of steps for a web service client flow?

The RDAP Web Service Client sends an RDAP "help" query to an RDAP server to
determine the type and capabilities of the OpenID Providers (Ops) that are
used by the RDAP server.
The RDAP Web Service Client determines the End-User's OP and confirms that
it's supported by the RDAP server.
The RDAP Web Service Client sends an Authentication Request to the OP.
The OP authenticates the End-User.
The OP obtains End-User consent/authorization.
The OP returns an Authorization Code to the RDAP Web Service Client.
The RDAP Web Service Client requests tokens using the Authorization Code at
the OP's Token Endpoint.
The RDAP Web Service Client receives a response that contains an ID Token and
an Access Token in the response body.
The RDAP Web Service Client monitors the token validity period and either
refreshes the token or requests new tokens as necessary.

[PK] All OK till here.

The RDAP Web Service Client sends queries that require user identification,
authentication, and authorization to an RDAP server that include the ID Token
in an HTTP bearer authorization header.
[PK] The client should never be sending ID Token, but access_token in 
this case.

The RDAP server validates the ID Token, exchanges it for an Access Token, and
retrieves the claims associated with the End-User's identity from the OP.


[PK] RDAP server needs to validate the access_token. It would be done 
either by introspection (call to OP)

or if it's JWT it can be validated offline.
Access token may either contain all needed information in its claims, or 
also additional identity
information can be requested by RDAP server from OP's user-info endpoint 
using the access token.



The RDAP server determines the End-User's authorization level and processes
the query in accordance with the End-User's authorization level.

Note that this requires the RDAP server to contact the OP as part of
processing every query that requires authorization.


[PK] In most basic and not optimized implementation yes. Caching of the 
information would be a typical choice to avoid that.


Quite common practice is to include all needed information in the JWT 
access token to avoid these kind of calls.
It's easy to assure for that with an OP being well integrated with the 
RDAP server, less likely for public OPs.


Kind Regards,

Pawel

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

Re: [regext] Web Service Client Flow

[Pawel Kowalik]

Hi Scott,

Am 17.11.22 um 20:26 schrieb Hollenbeck, Scott:

The RDAP Web Service Client sends queries that require user

identification, authentication, and authorization to an RDAP server
that include the ID Token in an HTTP bearer authorization header.

[PK] The client should never be sending ID Token, but access_token in this
case.

[SAH] That's a problem, because the Access Token is an opaque value per RFC
6749. If an RDAP server receives only an Access Token along with an RDAP
query, it has no way of knowing who the OP is, how to contact that OP, etc.
The ID Token identifies that the issuer, which allows the RDAP server to
contact the OP - right?


True. This was the reason I posed the question whether we want to support
"Any OP". Maybe I should have been more specific to ask whether we want
to support "any OP" as access_token issuer.
The workable model is to have the the RDAP server integrated with its 
local IdP,
which makes identity brokerage to other IdPs. This local IdP is then 
sole token
issuer so the problem is gone. The RDAP client can be offered with a way 
of triggering

authentication with OP of its choice, by using a specific authorization URL.
Keycloak for example allows for query parameter kc_idp_hint to control that.

I would strongly opt for this scenario, as most of the frameworks for 
resource server do not go well
with multiple token issuer schema, so the implementation would be a way 
more complex RDAP server side.


Otherwise we'd need to invent a way to transport identification of the 
OP with every RDAP request.
It's not super complicated - either with http header or query parameter 
- just there is no standard for that.


The other way around is to require the access tokens to be always JWTs 
(per RFC9068), where the iss claim is always there.
This may be too restrictive for some OPs so to support them RDAP server 
would need to setup a proxy anyway.



[SAH] Ah, "JWT access token". Are you assuming that "access token" is
something other than the Access Token defined by OAuth? If so, it sounds like
we need to design our own token format.


See above. RFC9068 defines such access tokens.

Kind Regards,

Pawel

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

Re: [regext] Web Service Client Flow

[Pawel Kowalik]

Hi Scott,

Am 18.11.22 um 14:01 schrieb Hollenbeck, Scott:

[...]

I would strongly opt for this scenario, as most of the frameworks for
resource server do not go well with multiple token issuer schema, so
the implementation would be a way more complex RDAP server side.

+ 1

[SAH] Me too. This is MUCH easier if we don't have to worry about remote OPs.


[PK] Great, this simplifies a lot of things down the line.



Revised flow:

The RDAP Web Service Client sends an RDAP "help" query to an RDAP server to
determine the type and capabilities of the OpenID Providers (OPs) that are
used by the RDAP server.
The RDAP Web Service Client determines the End-User's OP and confirms that
it's supported by the RDAP server.
The RDAP Web Service Client sends an Authentication Request to the OP.
The OP authenticates the End-User.
The OP obtains End-User consent/authorization.
The OP returns an Authorization Code to the RDAP Web Service Client.
The RDAP Web Service Client requests tokens using the Authorization Code at
the OP's Token Endpoint.
The RDAP Web Service Client receives a response that contains an ID Token and
an Access Token in the response body.
The RDAP Web Service Client monitors the token validity period and either
refreshes the token or requests new tokens as necessary.
The RDAP Web Service Client sends queries that require user identification,
authentication, and authorization to an RDAP server that include a JWT Access
Token [RFC9068] in an HTTP bearer authorization header.
[PK] In this scenario the access token does not need to be always "JWT 
Access Token"
if the assumptions is that it is up to RDAP server to integrate with 
their local OP.

The RDAP server validates the Access Token and retrieves the claims associated
with the End-User's identity from the Access Token or the local OP.
[PK] Just a remark not to limit the text to JWT access token. Opaque 
tokens can also carry data obtainable through token introspection. This 
is again local integration issue RDAP server - local OP which I see out 
of scope for our draft.

The RDAP server determines the End-User's authorization level and processes
the query in accordance with the End-User's authorization level.



Kind Regards,

Pawel

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

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik]

Hi James,

My comments also inline.

Am 22.11.22 um 14:18 schrieb Gould, James:
[...] [PK] Looking at the Abstract and the Introduction of the draft 
it reads "This document describes an RDAP extension for explicitly 
identifying redacted RDAP response fields, using JSONPath as the 
default expression language.". I see a clear focus on "identify", 
whereas such strong normative language actually influences the way the 
redaction is done. I don't think this should be the main focus of this 
draft and a bit softer SHOULD allows to align servers to the best 
practice without a dilemma if one can use the rdapConformance 
"redacted" even if placeholders are in use for whatever reason. 
Placeholders are perfectly fitting the "Redaction by Replacement Value 
Method", so also fitting the draft. JG2 - The use of placeholder text, 
such as "REDACTED", is an alternative approach that is incompatible 
with the method of redaction defined in this draft. The draft 
explicitly states that the use of placeholder text MUST NOT be used 
for redaction, and it has no impact on the use of placeholder text for 
other purposes.


[PK2] This is exactly what I allude to. The document describes not only 
the "extension for explicitly identifying redacted RDAP response fields" 
but also dictates what methods of redaction are allowed and which not. 
If there is consensus that the document also shall mandate the methods 
of redaction I think the Abstract and Introduction part should state it 
as well.


The real question is whether the goal of making clear what part of the 
dataset was redacted not enough for this draft.
For the client the indication that some data is not real, don't use it, 
is just enough of information, no matter if the data was removed, set to 
null, empty or otherwise replaced, isn't it?


Populating the existing value with a static placeholder value as a 
signal for redaction is different from what is defined for the 
"Redaction by Replacement Value Method", which changes the value to a 
non-static value or moves the location of the value.
[PK2] I believe it should be perfectly valid to replace one email with 
another email (for example privacy proxy email) without moving it, 
shouldn't it? For me it would be "Redaction by Replacement Value Method" 
where both paths are same.
If I currently implemented placeholder text for the purpose of 
redaction and I decided to implement redaction using the approach 
defined in this draft, then I don't see the purpose of running them in 
parallel even during a transition period, since clients should be 
notified of the transition and the draft includes the needed signaling 
using the "redacted" rdapConformance value. Is there a specific use 
case that would warrant a softer transition? If there is a softer 
transition use case warranted, then adding a Transition Considerations 
section, such as defined in section 6 of RFC 9154 "EPP Secure 
Authorization Information for Transfer, may be needed.


[PK2] Assuming the initial situation: RDAP server does not support 
"redacted" extension and puts the placeholder values and all the clients 
do not support "redacted" extension but know how to interpret the 
placeholder.


Now if the server would just turn on "redacted" first, not waiting for 
the clients, being fully compatible with the extension it would have to 
change the redaction with either empty value or removal of the fields. 
By doing this the clients which are not aware of "redacted" extension 
would potentially break due to changed behavior.


To avoid it the server would have to first make sure all clients support 
"redacted" before switching. This is somewhat impossible, as client is 
not informing the server in any way which extension it supports. If it 
would have a way to inform the server the problem would be gone as well, 
as server might have offered different representation to different 
clients. The other way around is to relax the requirement and allow the 
server operators to manage this.


SHOULD instead of MUST would give the operators a bit more of 
flexibility and same time none of the benefits of this draft would be lost.


[...] Another approach would be to define a way of interpreting the 
JSONPath so that it is reversible or even defining a subset of 
JSONPath which is reversible in the narrower RDAP context. JG2 - I'm 
not sure what is meant by JSONPath that is reversable. I believe that 
JSONPath needs to be used as defined.
[PK2] Reversable means that you can unambiguously re-create the original 
object structure based on the path. Normalized JSONPath have this 
property (see 2.8 of JSONPath draft) but may not be the best in case of 
array members identified by a property value of array member, like in 
jCard. The expressions like $.entities[?(@.roles[0]=='registrant')] can 
be also reversible, but this is not true for just any JSONPath 
expression. If we would define a narrowed down definition of JSONPath 
expressions which are allowed, we could 

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik]

Hi James,

My comments below.

Am 23.11.22 um 14:17 schrieb Gould, James:

[...]

JG3 – What triggered the creation of this extension was a proposal to 
use placeholder text for redaction, which in my opinion is an 
anti-pattern that needs to be directly addressed.  I believe that you 
see the need to support a transition period that would be up to server 
policy.  See my comment below related to creating a Transition 
Considerations section to make this explicit. The draft can define the 
methods for redaction, disallow the use of placeholder text for 
redaction outside of a transition period, and add explicit support for 
a transition period with a set of considerations.  Does this meet your 
needs?


[PK3] OK, please include also this part in the Abstract and 
Introduction, that the draft also defines certain rules for redaction to 
mitigate the anti-patterns, if there is a consensus in WG to mandate how 
redaction is done.



Populating the existing value with a static placeholder value as a signal for 
redaction is different from what is defined for the "Redaction by Replacement Value 
Method", which changes the value to a non-static value or moves the location of the 
value.

[PK2] I believe it should be perfectly valid to replace one email with 
another email (for example privacy proxy email) without moving it, 
shouldn't it? For me it would be "Redaction by Replacement Value 
Method" where both paths are same.


JG3 – Yes, use of a privacy proxy email is a form of "Redaction by 
Replacement Value Method", since the real value is not being provided 
but a replacement value is being used instead.  In this case the 
“method” value is “replacementValue” and the “replacementPath” is not 
used. Does this need to be clarified in the draft, since the intent is 
to support replacing the value in place or replacing the value using 
an alternate field, such as the replacement with the “contact—uri” 
property?


[PK3] Now I see it from examples that replacementPath might be omitted. 
It would be good to have some normative text defining that.


[...]

JG3 – Ok, that helps.  I believe the biggest issue from a client 
perspective is when they expect a non-empty value, and the server 
implements the Redaction by Empty Value Method and then returns an 
empty value.  The use of the placeholder redaction text can be used in 
parallel with draft-ietf-regext-rdap-redacted during a transition 
period.  The duration of the transition period would be up to server 
policy.  What I don’t want to introduce is parallel forms of redaction 
for beyond a transition period.  How about including the definition of 
a transition period in a Transition Considerations section and 
updating the MUST NOT language to “The use of placeholder text … MUST 
NOT be used for redaction outside of a transition period defined in 
Section X . In the Transition Considerations section, it can define 
that placeholder redaction text may exist and may overlap with this 
extension during a transition period that is up to server policy.  
Then there can be a set of considerations for the server and client in 
making the transition.  I believe this would address the transition 
more explicitly and leave the timing of the transition up to server 
policy.  Do you agree?


[PK3] If the WG is in consensus to keep "MUST NOT" then Transition 
Considerations is a good way to cover the smooth transition.



[...]

     Another approach would be to define a way of interpreting the JSONPath

 so that it is reversible or even defining a subset of JSONPath which is

 reversible in the narrower RDAP context.

JG2 - I'm not sure what is meant by JSONPath that is reversable.  I believe 
that JSONPath needs to be used as defined.

[PK2] Reversable means that you can unambiguously re-create the 
original object structure based on the path. Normalized JSONPath have 
this property (see 2.8 of JSONPath draft) but may not be the best in 
case of array members identified by a property value of array member, 
like in jCard. The expressions like 
$.entities[?(@.roles[0]=='registrant')] can be also reversible, but 
this is not true for just any JSONPath expression. If we would define 
a narrowed down definition of JSONPath expressions which are allowed, 
we could achieve the property of reversibility and maybe even that one 
kind of object or property would have exactly one and only possible 
JSONPath describing it. Again - it's just an idea how to deal with 
removed paths. It may be also not worth following if we assume 
"redacted name" would be the leading property (see below).


JG3 – Thanks for the reference, I’ll review it and see whether 
something can be used.  My initial thought is that it’s going to be 
too complex and won’t cover the broad set of use cases in RDAP.  Right 
now, we’ll assume that it can’t be used in 
draft-ietf-regext-rdap-redacted, but it’s being reviewed.




 In the end, implementing a client, I would rather 

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

[Pawel Kowalik]

Hi James,


Thanks for that.

My preference would be 3 or 4, to focus the draft on signaling, allowing 
the clients to recognize redacted fields.



Kind Regards,

Pawel


Am 23.11.22 um 16:57 schrieb Gould, James:


Pawel,

I add responses embedded below with “JG4 – “.

For the WG, I’m including one discussion topic at the top for 
consideration:


Section 3 currently states “The use of placeholder text for the values 
of the RDAP fields, such as the placeholder text "", MUST NOT be 
used for redaction.”  Pawel raised an issue with the MUST NOT language 
and proposed to use SHOULD NOT.  I view the use of placeholder text 
redaction as an anti-pattern that should be disallowed when 
implementing draft-ietf-regext-rdap-redacted, but I do recognize the 
potential need for a transition period.  I summarize the options below:
1.Keep MJST NOT with Transition Period – Formally define the 
transition period that is based on server policy in a new Transition 
Considerations section.
2.Change MUST NOT to SHOULD NOT – This enables the draft to recommend 
that placeholder text not be used for redaction, but still enable the 
server to support it in parallel with the redaction methods defined in 
the extension.
3.Remove the normative language – Change “The use of placeholder text 
for the values of the RDAP fields, such as the placeholder text 
"", MUST NOT be used for redaction.”  To “The use of placeholder 
text for the values of the RDAP fields, such as the placeholder text 
"", has been used for redaction.  …”.
4.Remove reference to placeholder text use for redaction – Just lead 
section 3 with the sentence “This section covers the redaction methods 
that can be used with the redaction signaling defined in Section 4.2 
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted#section-4.2>.”.
Please respond to the mailing list with your thoughts on the options 
or if you have any additional options.   My preferred option is option 
1 “Keep MJST NOT with Transition Period”.

Thanks,

--

JG




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



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

Verisign.com <http://verisigninc.com/>

*From: *Pawel Kowalik 
*Date: *Wednesday, November 23, 2022 at 9:23 AM
*To: *James Gould , 
"draft-ietf-regext-rdap-redac...@ietf.org" 


*Cc: *"regext@ietf.org" 
*Subject: *[EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09

Hi James,

My comments below.

Am 23.11.22 um 14:17 schrieb Gould, James:

[...]

JG3 – What triggered the creation of this extension was a proposal
to use placeholder text for redaction, which in my opinion is an
anti-pattern that needs to be directly addressed.  I believe that
you see the need to support a transition period that would be up
to server policy.  See my comment below related to creating a
Transition Considerations section to make this explicit.  The
draft can define the methods for redaction, disallow the use of
placeholder text for redaction outside of a transition period, and
add explicit support for a transition period with a set of
considerations.  Does this meet your needs?

[PK3] OK, please include also this part in the Abstract and 
Introduction, that the draft also defines certain rules for redaction 
to mitigate the anti-patterns, if there is a consensus in WG to 
mandate how redaction is done.


JG4 – I’m raising the options for discussion in the WG to hopefully 
find a consensus option.


Populating the existing value with a static placeholder value as a signal for 
redaction is different from what is defined for the "Redaction by Replacement Value 
Method", which changes the value to a non-static value or moves the location of the 
value.

[PK2] I believe it should be perfectly valid to replace one email
with another email (for example privacy proxy email) without
moving it, shouldn't it? For me it would be "Redaction by
Replacement Value Method" where both paths are same.


JG3 – Yes, use of a privacy proxy email is a form of "Redaction by
Replacement Value Method", since the real value is not being
provided but a replacement value is being used instead.  In this
case the “method” value is “replacementValue” and the
“replacementPath” is not used. Does this need to be clarified in
the draft, since the intent is to support replacing the value in
place or replacing the value using an alternate field, such as the
replacement with the “contact—uri” property?

[PK3] Now I see it from examples that replacementPath might be 
omitted. It would be good to have some normative text defining that.


JG4 – Ok, I’ll look to add clarification text.

[...]

JG3 – Ok, that helps.  I believe the biggest issue from a client
perspective is when they expect a non-empty value, and the server
implements the

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

[Pawel Kowalik]

Hi,

My comments below.

Am 27.11.22 um 22:49 schrieb Tom Harrison:

[...]

I still think that custom properties are useful for the reasons above.

On the other hand, their possible misuse should be ruled somehow.

Here in the following a possible statement limiting the scope of custom
properties:

"A custom reverse search property MUST NOT collide with a registered reverse
search property and MUST NOT match an RDAP property, or any of its variants,
matched by a registered reverse search property."
[PK] not sure about the second MUST NOT if it's not too hard. What kind 
of harm we are trying to prevent, when 2 reverse search properties match 
the same RDAP property?
I am thinking of a scenario, where the server defines a custom property, 
then it gets registered under a different name - the server may wish to 
keep both for back compatibility.


Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define
"name" as a custom property.


[PK] Isn't it actually a useful property if "reverse search property" 
may remain the same no matter what the underlying representation is? As 
a client I am interested to get all related objects with an entity 
holding for example certain email address, no matter if jCard or 
JSContact is used by the server. This abstraction layer offers the 
possibility to leave the differences in the data representation and the 
related filtering up to the RDAP server implementation without breaking 
the protocol.



I still don't see how the document can require that a custom reverse
search property not collide with registered reverse search properties
as to its name or the members that it refers to, because the person
registering a new reverse seach property is not guaranteed to be aware
of all existing custom reverse search properties.  The fact that a
given field is a 'variant' of another may not be obvious to
implementors, either.  If any new reverse search that isn't covered by
the existing document has to be defined in an extension, then these
problems go away.


[PK] I think it's a common problem. RFC 6648 Section 3 and 4 offer some 
guidance which we may reference to or adapt into this draft.


Kind Regards,

Pawel

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

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

[Pawel Kowalik]

Hi Mario,

My comment inline.

Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a 
registered reverse
search property and MUST NOT match an RDAP property, or any of its 
variants,

matched by a registered reverse search property."
[PK] not sure about the second MUST NOT if it's not too hard. What 
kind of harm we are trying to prevent, when 2 reverse search 
properties match the same RDAP property?
I am thinking of a scenario, where the server defines a custom 
property, then it gets registered under a different name - the server 
may wish to keep both for back compatibility.
[ML] Just the opposite harm. A registered property having the same 
name of a custom property but they refer to different RDAP properties. 
[PK2] OK, this one I agree, but this is the first part "A custom reverse 
search property MUST NOT collide with a registered reverse search 
property", isn't it?


My comment was referring to the second part, where, if I read it right, 
it would be forbidden to match a custom reverse search property to same 
field as any of already registered ones.


Kind regards,

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

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

[Pawel Kowalik]

Hi Mario,

Am 29.11.22 um 07:46 schrieb Mario Loffredo:


Hi Pawel,

Il 28/11/2022 22:02, Pawel Kowalik ha scritto:


Hi Mario,

My comment inline.

Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a 
registered reverse
search property and MUST NOT match an RDAP property, or any of 
its variants,

matched by a registered reverse search property."
[PK] not sure about the second MUST NOT if it's not too hard. What 
kind of harm we are trying to prevent, when 2 reverse search 
properties match the same RDAP property?
I am thinking of a scenario, where the server defines a custom 
property, then it gets registered under a different name - the 
server may wish to keep both for back compatibility.
[ML] Just the opposite harm. A registered property having the same 
name of a custom property but they refer to different RDAP properties. 
[PK2] OK, this one I agree, but this is the first part "A custom 
reverse search property MUST NOT collide with a registered reverse 
search property", isn't it?


My comment was referring to the second part, where, if I read it 
right, it would be forbidden to match a custom reverse search 
property to same field as any of already registered ones.


[ML] In my opinion, both the misuses are harmful. For the sake of 
increasing interoperability, the case of two reverse search properties 
mapping the same RDAP property must be avoided as well.


[PK3] Sure, this must not happen on the level of registered reverse 
search properties, to have duplicated registered names pointing to the 
same property. I think it should be at least allowed (ergo SHOULD NOT 
instead of MUST NOT) to have such duplicates with custom property which 
is local and makes no harm to the interoperability. There is a clear 
use-case behind which is a natural consequence of experimental nature of 
custom reverse search properties. See the scenario I mentioned 2 comment 
earlier.


The only admissible case should be when the same name is used to map 
two RDAP properties but one is an equivalent representation of the 
other in another format (i.e. the entity full name can be represented 
both in jCard and in JSContact but both are used to represent the same 
information).



[PK3] Fully agree here.

Kind Regards,

Pawel

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

Re: [regext] Web Service Client Flow

[Pawel Kowalik]

Hi Scott,

I have a bit of difficulty with those definitions.

I think this starts with the definition of a client.

RFC 2616 defines it as follows:

   client
  A program that establishes connections for the purpose of sending
  requests.

   user agent
  The client which initiates a request. These are often browsers,
  editors, spiders (web-traversing robots), or other end user tools.


RFC 6749 has a different definition:

   An application making protected resource requests on behalf of the
  resource owner and with its authorization.  The term "client" does
  not imply any particular implementation characteristics (e.g.,
  whether the application executes on a server, a desktop, or other
  devices).


When we now talk of "session-oriented" clients, we actually mean "user 
agent" as per RFC 2616 which supports cookies for session management,

whereas "token-oriented" clients are in fact clients in sense of RFC 6749.

In the definition of "token-oriented" clients there needs to be a 
differentiation between OIDC interactions and OAuth2 interactions.
In our scenario RDAP server is a resource server as per RFC 6749, a role 
which does not exist explicitly in OIDC - or to be fully correct is 
fulfilled by OP for its own userinfo resource.

So it's incorrect to say that RDAP server performs RP functions.

Kind Regards,

Pawel

Am 28.11.22 um 18:07 schrieb Hollenbeck, Scott:

Does this make sense for use as introductory text to appear in new Section 
3.1.2 of what will be -19? Please make suggestions for improvement as you see 
fit.

3.1.1 Terminology

3.1.2 Client Considerations

Clients that can accept and process HTTP cookies [RFC6265] as part of session-oriented 
interactions with an RDAP server are known as "session-oriented" clients. This 
type of RDAP client performs the role of an OpenID Connect Core 1.0 [OIDCC] Entity or 
End-User. An RDAP server performs the role of an OpenID Connect Core Relying Party (RP). 
A web browser used to send queries directly to an RDAP server is an example of a 
session-oriented client.

Clients that perform the role of an RP in interactions with an OP and send tokens to an 
RDAP server to authorize RDAP queries are known as "token-oriented" clients. An 
RDAP server also performs RP functions to verify the tokens received from the client and 
to retrieve information from the OP as necessary to make access control decisions. A web 
browser running JavaScript received from a web service that sends queries to an RDAP 
server is an example of a token-oriented client.

3.1.3 Overview


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

Re: [regext] Web Service Client Flow

[Pawel Kowalik]

Hi Scott,

Am 30.11.22 um 17:39 schrieb Hollenbeck, Scott:

-Original Message-
From: Pawel Kowalik 
Sent: Wednesday, November 30, 2022 11:15 AM
To: Hollenbeck, Scott ; mario.loffr...@iit.cnr.it;
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Web Service Client Flow

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.

Hi Scott,

I have a bit of difficulty with those definitions.

I think this starts with the definition of a client.

RFC 2616 defines it as follows:

 client
A program that establishes connections for the purpose of sending
requests.

 user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.

[SAH] The draft inherits a definition of "client" from RFC 7480. That's
spelled out in the "terminology" section.


[PK2] Indeed I overlooked that. The definition in RFC 7480 actually 
refers to HTTP user agent, so RFC 2616 definition.




RFC 6749 has a different definition:

 An application making protected resource requests on behalf of the
resource owner and with its authorization.  The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).


When we now talk of "session-oriented" clients, we actually mean "user
agent"
as per RFC 2616 which supports cookies for session management, whereas
"token-oriented" clients are in fact clients in sense of RFC 6749.

[SAH] OK, so what's the best way to identify these two types of clients in the
draft given the RDAP definition of "client" found in RFC 7480?


[PK2] My proposal:

Clients that want to delegate OIDC Authentication to RDAP server as part of 
session-oriented interactions and can accept and process HTTP cookies [RFC6265] to 
maintain the session are known as "session-oriented" clients. This type of RDAP 
client performs the role of user agent [RFC2616]. An RDAP server performs the role of an 
OpenID Connect Core Relying Party (RP). A web browser used to send queries directly to an 
RDAP server is an example of a session-oriented client.

Clients that perform OIDC Authentication directly taking the role of an RP in 
interactions with an OP and send access tokens [RFC6749] to an RDAP server to authorize 
RDAP queries are known as "token-oriented" clients. An RDAP server performs 
resource server functions [RFC6749] to verify the tokens received from the client and RP 
functions to retrieve information from the OP as necessary to make access control 
decisions. A web browser running JavaScript received from a web service that sends 
queries to an RDAP server directly or through its backend web service is an example of a 
token-oriented client.


In the definition of "token-oriented" clients there needs to be a
differentiation
between OIDC interactions and OAuth2 interactions.
In our scenario RDAP server is a resource server as per RFC 6749, a role
which
does not exist explicitly in OIDC - or to be fully correct is fulfilled by
OP for its
own userinfo resource.
So it's incorrect to say that RDAP server performs RP functions.

[SAH] Note that the OpenID Connect Core specifications says that "OAuth 2.0
Clients using OpenID Connect are also referred to as Relying Parties (RPs)".
The RDAP server can request claims from an OP using an Access Token. I
described the RDAP server as an RP related to performance of that function.
I'm open to re-wording of the description if it's inaccurate or incomplete.


[PK2] See proposal above. Getting information from OP can be seen as RP 
function whereas token verification isn't.


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

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

[SAH] This is my first attempt for text that addresses token-oriented clients. 
I'd greatly appreciate review and feedback.

Scott

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


--
Pawel Kowalik
Head of Product Management
--
DENIC eG, Kaiserstraße 75 - 77, 60329 Frankfurt am Main, GERMANY
E-Mail: pawel.kowa...@denic.de, Fon: ‭+49 173 3087096‬
https://www.denic.de

Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler
Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am 
Main

Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13, 
Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch 
DENIC finden Sie unter https://www.denic.de/datenverarbeitung-allgemein/

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

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

[Pawel Kowalik]

Hi Scott,

Feedback below.

Am 06.12.22 um 15:23 schrieb Hollenbeck, Scott:

Thanks for the feedback. More below...



- we discussed that we do not care that much about remote OPs, however the
issue of access_token coming from an unknown OP remains. My proposal for a
simple solution would be just to require a query parameter "OP Issuer
Identifier" with each RDAP query for non-default OP server. This would be an
add to 6.2

[SAH] The document already includes the "farv1_iss" query parameter that's
used with a login query. It can be used in this context as needed. Are you
suggesting that the document should include support for a client sending a
"farv1_iss" query parameter with a (for example) domain query such that the
RDAP server will start a session-oriented login process prior to processing
the domain query? If not that, are you suggesting that receipt of a
"farv1_iss" query parameter will simply identify the issuer to the RDAP server
so that the RDAP server can attempt to process the access token received from
a token-oriented client? The latter makes more sense to me.

[PK] Yes, absolutely I meant the latter.


I see value in remote OPs. In the ICANN registry/registrar world, I fully
believe there is room for entities like law enforcement, security researchers,
intellectual property interests, and similar "communities of interest" to
deploy and operate identity providers for their members. That model scales
better than every registry/registrar RDAP server operator having to operator
their own OP and issue credentials to every person who wants access to their
service. If they do that, they might as well just issue user names and
passwords for use with HTTP Basic authentication.

[PK] Yes I see that too, therefore with "farv1_iss" it would be working.


Kind Regards,

Pawel

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

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

[Pawel Kowalik]

Hi James,

Thanks for posting the new version incorporating the changes. I reviewed 
it and have few comments on that:


1. As the WG consensus seems to be to keep normative language in the 
form "placeholder text , MUST NOT be used for redaction" I would 
recommend to extend Abstract and Introduction accordingly, that the 
document also specifies allowed methods of RDAP response redaction.



2. The description of "path" member in 4.3 is now correctly describing 
all the cases for different redaction methods, but due to that it became 
very complex. I would still reconsider, if it wouldn't be better to have 
2 members "preredactedPath" and "redactedPath", which refer to 
pre-redacted response and redacted response accordingly. Then for 
different redaction method you would apply:


- Redaction By Removal Method: preredactedPath (OPTIONAL, same as path 
in -10)


- Redaction by Empty Value Method: redactedPath (MANDATORY, same as path 
in -10)


- Redaction by Partial Value Method: redactedPath (MANDATORY, same as 
path in -10)


- Redaction by Replacement Value Method: preredactedPath (OPTIONAL, same 
as path in -10) and redactedPath (MANDATORY, same as replacementPath in -10)


I see a clear advantage of this approach that the clients can always use 
"redactedPath" on the response object without tedious logic depending on 
redaction method.



Kind Regards,

Pawel

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

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

[Pawel Kowalik]

Hi James,

Please find my comments embedded below.

Am 19.12.22 um 14:54 schrieb Gould, James:

On 12/19/22, 2:43 AM, "Pawel Kowalik"  wrote:

 Hi James,

 Thanks for posting the new version incorporating the changes. I reviewed
 it and have few comments on that:

 1. As the WG consensus seems to be to keep normative language in the
 form "placeholder text , MUST NOT be used for redaction" I would
 recommend to extend Abstract and Introduction accordingly, that the
 document also specifies allowed methods of RDAP response redaction.

JG - Other forms of redaction can be created and used, which can also result in 
a future update to the draft or RFC.  As an example, the new Redaction by 
Partial Value Method was added in draft-ietf-regext-rdap-redacted-10 to cover a 
newly raised use case.  The proposal to use of placeholder text for redaction 
drove the initial creation of this draft to define an explicit redaction signal 
that didn't touch the content of the response body, which is the reason why 
placeholder text redaction needs to be called out.
   
Do you have a redaction use case that is not effectively covered by the methods defined in the draft that needs to be considered?


Have you implemented placeholder text redaction in a way that can't be 
transitioned to use the redaction extension?


[PK] Sorry for not being specific enough in my previous remark.

My point was to indicate in the Abstract and Introduction to the 
document, that the documents specifies ways of redaction, not only 
indentification thereof - in a generic way.


A proposed change to the Abstract:

"This document describes an RDAP extension for specifying ways of 
redaction of RDAP responses and explicitly identifying redacted RDAP 
response fields, using JSONPath as the default expression language."


I would see similar change to the first paragraph of Introduction section.


 2. The description of "path" member in 4.3 is now correctly describing
 all the cases for different redaction methods, but due to that it became
 very complex. I would still reconsider, if it wouldn't be better to have
 2 members "preredactedPath" and "redactedPath", which refer to
 pre-redacted response and redacted response accordingly. Then for
 different redaction method you would apply:

 - Redaction By Removal Method: preredactedPath (OPTIONAL, same as path
 in -10)

 - Redaction by Empty Value Method: redactedPath (MANDATORY, same as path
 in -10)

 - Redaction by Partial Value Method: redactedPath (MANDATORY, same as
 path in -10)

 - Redaction by Replacement Value Method: preredactedPath (OPTIONAL, same
 as path in -10) and redactedPath (MANDATORY, same as replacementPath in 
-10)

 I see a clear advantage of this approach that the clients can always use
 "redactedPath" on the response object without tedious logic depending on
 redaction method.

JG - I agree that embedding the path context (pre or post redaction) into the member names provides 
a more explicit signal.  I would view the members as being mutually exclusive, as reflected by the 
second sentences of the descriptions below.  I don't see any impact on the use of the 
"replacementPath" member.  One variance with what you describe is that the 
"redactedPath" is only required for the Redaction by Replacement Value Method when the 
redacted member does exist in the redacted response (e.g., empty instead of removed).  How about 
shortening the member names with some additional normative descriptive language below?

"prePath": OPTIONAL JSON expression referencing a redacted JSON field in the pre-redacted response.  The 
"prePath" member MAY be set when the redacted field does not exist in the redacted response for the Redaction 
by Removal Method (Section 3.1) and the Redaction by Replacement Value Method (Section 3.4).  The "prePath" 
member MUST NOT be set when the "postPath" member is set.
"postPath: OPTIONAL JSON expression referencing a redacted JSON field in the redacted (post-redacted) 
response.The "postPath" member MUST be set when the redacted field does exist in the redacted 
response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 
3.3), and the Redaction by Replacement Value Method (Section 3.4),  The "postPath" member MUST NOT be 
set when the "prePath" member is set.

A nuance is that the "postPath" member is required for the Redaction by 
Replacement Value Method only when the redacted field does exist in the redacted response 
(e.g., empty instead of removed).  The focus of the normative language is whether the 
redacted field exists in the redacted response, where the list of the methods applies.  
Is this clear?


[P

Re: [regext] New version of rdap-reverse-search

[Pawel Kowalik]

Hi,

The current draft addresses all the points I've brought up.

One of the points was actually the discoverability. The draft describes 
4 predefined search properties: fn, handle, email, role.
The support for all of them is optional, so the client would not know if 
the query is supported or not, other than try&error approach. /help 
structure solves this issue.


The other point was about adding new reverse search properties. One way 
is to always require an extension for new reverse search properties, 
even if no new data structures are added (e.g. search by telephone 
number). This approach will use an existing IANA registry.
The solution proposed by Mario adds a new IANA registry for reverse 
search properties. It would offer better transparency and consistency 
over reverse search properties across the extensions.


Kind Regards,
Pawel

Am 19.12.22 um 16:18 schrieb Jasdip Singh:


Hi.

Per the comments in [1], it would be good to settle if the proposed 
discovery and IANA registration of reverse search properties is an 
overkill or not. Specifically:


  * Is the newly proposed "reverse_search_properties" member in the
help response (section 5) needed?
  * Is the newly proposed "RDAP Reverse Search Properties" registry
(section 9.2) needed?

Thanks,

Jasdip

[1] 
https://mailarchive.ietf.org/arch/msg/regext/baN_jHO32rRLTbzef6B5Rtep29g/


*From: *regext  on behalf of Antoin 
Verschuren 

*Date: *Monday, December 19, 2022 at 10:04 AM
*To: *"regext@ietf.org" 
*Subject: *Re: [regext] New version of rdap-reverse-search

Hi all, can all people that commented on 
draft-ietf-regext-rdap-reverse-search since the start of the previous 
last call (Tom, Pawel, Jasdip) confirm that all their issues are now 
addressed in version 17, so that the document shepherd can confirm 
there are no new changes to be expected during WGLC?


Once we have confirmation, we will issue a 3th WGLC when the document 
is stable.


Regards,

Jim and Antoin



Op 1 dec. 2022, om 14:24 heeft Mario Loffredo
 het volgende geschreven:

Hi Chairs,

this is to inform you that I'm ready to submit the new
rdap-reverse-search version addressing the feedback provided
during the LC, i.e. reverse searech properties discovery and
registration.

Hopefully, no futher feedback will be provided.

Would like to know how to proceed now.

Should I ask for a new WGLC?

Will you do that?


Best,

Mario

-- 
Dott. Mario Loffredo

Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
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___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-harrison-regext-rdap-rir-search

[Pawel Kowalik]

I support the adoption.

Kind Regards,

Pawel

Am 19.12.22 um 15:33 schrieb Antoin Verschuren:

This is the formal adoption request for RDAP RIR Search:

https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-rir-search/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT and comment to the list, clearly stating your view.

This Call For Adoption will close on Monday, 16 January.

If there are no objections, the chairs will consider this document adopted.

Thanks,

Jim and Antoin
___
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] draft-ietf-regext-rdap-redacted-10 Posted

[Pawel Kowalik]

Hi James,

Am 22.12.22 um 14:51 schrieb Gould, James:

"This document describes an RDAP extension for specifying methods of
   redaction of RDAP responses and explicitly identifying redacted RDAP
   response fields, using JSONPath as the default expression language."

This change will be incorporated in draft-ietf-regext-rdap-redacted-11.


[PK3] Thank you.


JG2 - Yes, the "replacementPath" member needs to remain and can be included with the "postPath" member when 
an empty value field is replaced with a different field.  Changing the "path" member to the "prePath" and 
"postPath" members will be included in draft-ietf-regext-rdap-redacted-11.


[PK3] Perfect, than all of my points would be well covered in -11. 
Thanks again.


Kind Regards,

Pawel

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

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

[Pawel Kowalik]

Hi Scott,

Responses below.

Am 04.01.23 um 13:58 schrieb Hollenbeck, Scott:



- in the Section 3.1.3 the Sequence diagram for session-oriented client
should
also contain RDAP server <-> OP interactions to correspond to the sequence
diagram of token-oriented clients

[SAH] What exactly is missing that needs to be there? I see a number of RDAP
Server interactions with the OP in the existing diagram.


[PK] Reviewed it again and indeed the only flow missing is "RDAP Query" 
flow, which may be added for completeness.


Also just noticed, that the order of entities is different with "RDAP 
Server" and "RDAP Client" being swapped between the two. Maybe this is 
what confused me initially.





- in the Section 4.1 I propose to add an additional member to the object in
openidcProviders array:

- "additionalAuthorizationQueryParams" being an object where each member
represents query parameter name and value is the query parameter value
This metadata will allow Token-Oriented Client to trigger authorization
with a
specified OP through Proxy OP, even if the iss and authorization endpoints
are
same. With Keycloak as example this can be controlled with "kc_idp_hint"
parameter, so the example configuration would be:

 "openidcProviders":
  [
{
  "iss": "https://secure-
web.cisco.com/1qTpGgvOW0O1IaI0PV07VJOt4JaNNTkdi-
AvAhv3Wp4mF7rRuTcjEJ_leMZoez112c1Atkf2PO3rgB4na-
Z5QDbPI5VqhnmYMV0ZW4XrWDJbweHswBJkznKyK3pY8PN8-fx-Bm9EnN-
5sKFRu35KKGIlU2masFNMkcEcqVzNugSp9lmz_-
0k5eydMRr5Co4TIFhwzWJNkSVXc85nyOazgjgK2vrbF88bIKCirXHUujUQ4XzZkJXW
B1ehJ9ZZflrTQlqSpaBKl_9XPJ7ZsdAiYrHEHgSntsTbZBhZnFTchaDaAfdPhjwkiMv3
AE1v21nXS/https%3A%2F%2Flocal-idp.rdap.example.com",
  "name": "Example Public IDP",
  "additionalAuthorizationQueryParams": {
 "kc_idp_hint": "examplepublicidp"
  }

}

  ]

[SAH] The RDAP server publishes support for
"additionalAuthorizationQueryParams". How would a client use this information,
or tell the RDAP server to do something with it as part of a query, Pawel?


[PK] This would be my proposal including the intended handling for the 
RDAP Client.


- "additionalAuthorizationQueryParams" - an object where each member 
represents a query parameter name and value. Token-oriented RDAP Client 
SHOULD add these query parameters with their corresponding values to the 
Authentication Request URL when requesting authorization from OP.


Kind Regards,

Pawel

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

Re: [regext] RDAP queries based on redacted properties

[Pawel Kowalik]

Hi,

My comment below.

Am 11.01.23 um 19:03 schrieb Marc Blanchet:



Le 11 janv. 2023 à 12:43, Gould, James  a 
écrit :

Mario,

I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for 
RDAPs use case.  Use of redaction by empty value would not be compliant with the potential format language.  The difference between jCard and 
JSContact is that jCard was already an RFC when RDAP was being created, where JSContact is currently an Internet Draft.  You are aware of the need to 
redact the "uid" field for the RDAP use case, so why not make the "uid" optional in JSContact to make it meet the broader use 
case of RDAP with some potential caveats (e.g., the "uid" MUST be set when there is the need for discovering, comparing, or synchronizing 
contact cards)?RDAP doesn't have those needs, so the inclusion of the "uid" can be optional and used where it makes sense, such as 
returning in an entity query response.  The "uid" could match the "handle" and be redacted in the domain query response.

My 2 cents. an object shall have a mandatory unique identifier. I think we are 
going way too far by removing a unique (random) object identifier for the 
purpose of privacy. A UID/UUID does not provide any privacy related info. I’m 
aware of the cross references, but I just think we are going way too far. I 
would vote for keeping the UID as mandatory, since for an implementer 
perspective, I can keep this object and its UID, put it in a database and know 
when I have an updated version of that object because the UID is unique and 
mandatory. Without UID, all objects are different, and this is no fun to 
correlate: I would potentially have multiple copies of the same object without 
being able to flush them out, unless a do a full deep comparison, which does 
not make any sense.


I think we would be going too far if the technical / protocol decision 
would implicitly narrow down privacy policy options of the registry.


If this is mandatory for the data structure to contain uid, that's fine. 
One of the rules in this draft was not to break data formats by the 
redaction. This can be achieved by replacing the real uid with a 
generated and privacy-preserving one, as raised already in some of the 
proposals. It should be properly signaled, same as for any other 
redaction taking place. The client applications basically shall not rely 
on identifiers, which have been redacted.


It may be a valid point to expect RDAP server to always deliver the same 
response to the same query, which would imply the same entity delivering 
the same redacted uid in the same query context, instead of fully random 
uids. I assume however that even that may be too much from privacy 
policy perspective of some registries, therefore IMHO the specification 
shall allow for such radical redaction and the client applications have 
to be able to deal with it.


Kind Regards,

Pawel

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

Re: [regext] RDAP queries based on redacted properties

[Pawel Kowalik]

Hi Marc,

Comment below

Am 16.01.23 um 16:49 schrieb Marc Blanchet:



Le 11 janv. 2023 à 12:43, Gould, James  a 
écrit :

Mario,

I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for 
RDAPs use case.  Use of redaction by empty value would not be compliant with the potential format language.  The difference between jCard and 
JSContact is that jCard was already an RFC when RDAP was being created, where JSContact is currently an Internet Draft.  You are aware of the need to 
redact the "uid" field for the RDAP use case, so why not make the "uid" optional in JSContact to make it meet the broader use 
case of RDAP with some potential caveats (e.g., the "uid" MUST be set when there is the need for discovering, comparing, or synchronizing 
contact cards)?RDAP doesn't have those needs, so the inclusion of the "uid" can be optional and used where it makes sense, such as 
returning in an entity query response.  The "uid" could match the "handle" and be redacted in the domain query response.

My 2 cents. an object shall have a mandatory unique identifier. I think we are 
going way too far by removing a unique (random) object identifier for the 
purpose of privacy. A UID/UUID does not provide any privacy related info. I’m 
aware of the cross references, but I just think we are going way too far. I 
would vote for keeping the UID as mandatory, since for an implementer 
perspective, I can keep this object and its UID, put it in a database and know 
when I have an updated version of that object because the UID is unique and 
mandatory. Without UID, all objects are different, and this is no fun to 
correlate: I would potentially have multiple copies of the same object without 
being able to flush them out, unless a do a full deep comparison, which does 
not make any sense.

I think we would be going too far if the technical / protocol decision would 
implicitly narrow down privacy policy options of the registry.

If this is mandatory for the data structure to contain uid, that's fine. One of 
the rules in this draft was not to break data formats by the redaction. This 
can be achieved by replacing the real uid with a generated and 
privacy-preserving one, as raised already in some of the proposals. It should 
be properly signaled, same as for any other redaction taking place. The client 
applications basically shall not rely on identifiers, which have been redacted.

It may be a valid point to expect RDAP server to always deliver the same 
response to the same query, which would imply the same entity delivering the 
same redacted uid in the same query context, instead of fully random uids. I 
assume however that even that may be too much from privacy policy perspective 
of some registries, therefore IMHO the specification shall allow for such 
radical redaction and the client applications have to be able to deal with it.

Okay, but then, we are essentially disabling any kind of caching if the uid is 
always different and random at each query for the same object. That would have 
an impact on the servers, as clients will always query the servers, and the 
server operators won’t be able to use caching services to help manage trafic. 
Sad for an object that is so “cachable” as it otherwise does not change 
frequently.

Marc.


[PK] I think the statement is not fully true. All http-based strategies 
for caching will remain available, as long as the server operator would 
not exclude caching on purpose by setting appropriate http headers. The 
server operator would have to balance out the privacy policy vs. the 
strategies of uid redaction and the implications on the server 
performance. I think it is a fair deal if this decisions are left out to 
the server operator rather than arbitrarily deciding it on the protocol 
level.


One consideration we may think of, is whether there is (enough) value 
for the server to inform the client (by the mean of specific new 
redaction methods) whether the redacted uid is random each time, or it's 
random but stable for a given entity in the same context, or it's 
redacted with a static value and always the same for all entities. It 
may serve a benefit for the clients and their caching / object 
management strategies, but adds certain complexity to the protocol.


Kind Regards,

Pawel

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