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

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? Her

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

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

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

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 thi

Re: [regext] RDAP-X draft adoption

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

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

+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 REQUESTE

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

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

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

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

Re: [regext] EPP Transport Service Discovery

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

Re: [regext] Re-chartering REGEXT?

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 al

Re: [regext] Re-chartering REGEXT?

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 "ses

Re: [regext] Re-chartering REGEXT?

+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 discussio

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

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

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

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:

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

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

[regext] Re: Simple Redaction

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, practic

[regext] Re: Simple Redaction

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 pr

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

+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 lik

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

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 t

[regext] Re: [Ext] DSYNC in EPP

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 pro

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

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 putt

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

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 u

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

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 f

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

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

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

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

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

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

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

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 doc

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

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 edito

[regext] Re: RDAP versioning draft feedback

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

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

+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

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

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 M

[regext] Re: Extensions: Clarify redirects #55

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. 

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

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

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

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 explicitl

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

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 wou

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

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

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

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 R

[regext] Re: Extensions: Referrals handling #56

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 provisi

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

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

[regext] Re: Extensions: Referrals handling #56

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

[regext] Re: Extensions: Referrals handling #56

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 b

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

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 lifecyc

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

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 abov

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

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 thes

[regext] Re: Extensions: Referrals handling #56

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 ap

Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

+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

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

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 use

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

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, 202

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

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&quo

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

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

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

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

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

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 supp

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

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 interacti

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

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

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

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

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

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

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

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

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

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

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 lis

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

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 remo

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

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

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

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 pu

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

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 a

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

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,

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

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 m

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

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]

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

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 http

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

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 appli

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

escribed, 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 d

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt - Side Meeting at IETF 115

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 clien

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

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

[regext] Review of draft-ietf-regext-rdap-redacted-09

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

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

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 demonstra

Re: [regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-15.txt

lman/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://w

Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115

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

Re: [regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-15.txt

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

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

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 s

Re: [regext] Web Service Client Flow

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 se

Re: [regext] Web Service Client Flow

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

Re: [regext] Web Service Client Flow

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

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

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 expres

Re: [regext] 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 nee

Re: [regext] Review of draft-ietf-regext-rdap-redacted-09

*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: *"re

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

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:

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

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 a

Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

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

Re: [regext] Web Service Client Flow

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

Re: [regext] Web Service Client Flow

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

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

ation 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

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

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

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

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 Intr

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

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.

Re: [regext] New version of rdap-reverse-search

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 no

Re: [regext] CALL FOR ADOPTION: draft-harrison-regext-rdap-rir-search

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

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

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 incorpora

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

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

Re: [regext] RDAP queries based on redacted properties

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 redac

Re: [regext] RDAP queries based on redacted properties

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 reda

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

Hi Julien, Answer embedded. Am 16.01.23 um 20:33 schrieb Julien Bernard:  - section 4.1 I'm not that familiar with OIDC and that's might be the issue but I don't really understand the need for additionalAuthorizationQueryParams. Is there a way to clarify this or a reference that would help?

Re: [regext] RDAP queries based on redacted properties

tocol. Let's wait for a response and then we'll be able to make a definitive proposal about this matter. Meantime, thanks everyone who has joined the discussion thus far. Best, Mario Il 16/01/2023 23:33, Marc Blanchet ha scritto: Le 16 janv. 2023 à 16:18, Pawel Kowalik a é

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

Hi, Am 26.01.23 um 20:33 schrieb Jasdip Singh: [SAH] Thanks for the feedback, Mario. I still don't think this is a good idea, but if mine is a minority opinion I'll update the text to remove the MUST and include config info so a server can describe the type(s) of clients it supports. Please folk

  1   2   >