Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Mario Loffredo]

Il 07/12/2021 14:42, Marc Blanchet ha scritto:


Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
 a écrit :


We can **certainly** do that, Mario. It’s the option I support 
because there is a cost to replace a jCard implementation once it’s 
been implemented and deployed. Make it an optional extension and let 
server operators decide if/when they want to make the change.
I note that this will make life more difficult for client 
implementors because they’ll have to support both formats.


But the genie is already out of the bottle… I.e. if one have done a 
client implementation, it has already support for jCard. Adding the 
JSContact is just more code.  There will be only less work if one is 
implementing a client in the future after the whole ecosystem had 
moved to JSContact, therefore no need to implement jCard, which is 
still a good win, as I guess that many haven’t implemented a client 
yet since whois is still dominant and RDAP is not yet at the same level.


+1

Every extension requires an implementation effort and every transition 
process from the old to the new requires a period where both coexist.


If we hadn't been aware of that, we wouldn't have started the process to 
replace Whois with RDAP. And, like Marc pointed out, this process is 
still at the beginning  and we still don't imagine when it will really 
be completed.


In addition to that, I wonder why some members are so worried about the 
implementation effort done in this case in comparison to other 
extensions that completed the reviewing process.


For example, why haven't we been so concerned about the implementation 
effort required to client and servers in order to implement the EPP 
Login Security extension and the consequent period where clients and 
servers should deal with both the password formats ? And what about the 
implementation effort done to replace custom solutions already existing 
with new standard solutions?


Honestly, it seems to me that the implementation effort required in this 
case is lower than the one required by other extensions.


I believe that the main point is if we (intended as most of us) finally 
agree that the benefits from implementing an extension far outweigh the 
required efforts and we have evidence that


the new will be significantly better than the old (and it seems to me we 
have it in this case).


But, at the same time, we are not sure that the majority of EPP or RDAP 
operators will implement it. That's it.



That being said, IMO, the status of this document should remain 
"Standard Track".



Best,

Mario




“Be liberal in what you accept” applies.


yes.

Marc.


Scott
*From:*regext *On Behalf Of*Mario Loffredo
*Sent:*Tuesday, December 7, 2021 3:45 AM
*To:*Antoin Verschuren ;regext@ietf.org
*Subject:*[EXTERNAL] Re: [regext] New Version Notification for 
draft-ietf-regext-rdap-jscontact-04.txt


*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 all,

maybe I'm missing something but is there anybody explaining me why we 
can have two standards for the email address in EPP but we cannot 
have two standards for the contact card in RDAP ?


I admit that the reasons supporting the two documents are different 
but their matters appear very similar to me.


Using JSContact inside RDAP is basically an extension.

If we remove stages 3 and 4 of the transition from the document, we 
simply have an RDAP extension that is or isn't implemented  by a server.


This extension can be firstly signaled by the server, then requested 
by the client and consequently returned by the server just as it 
happens for the EAI extension in the EPP context.


Best,

Mario

Il 06/12/2021 15:29, Antoin Verschuren ha scritto:

Hi all,
In addition to the questions from Mario, we still need to discuss
the status of this document as discussed during the IETF112 meeting:
"the document doesn’t have designated status; it was adopted
without a status (on purpose). We need to think about the
implications. Encouraged group to discuss/comment on the list”
Meaning that because jCard is not depreciated with publishing
this document, what will the status of this document be? We
cannot have 2 standards, so we need to say something about it.
Jim and Antoin


Op 27 nov. 2021, om 09:04 heeft Mario Loffredo
 het volgende geschreven:
Hi folks,
this new version addresses the feedback provided by Jasdip
except for the following two points left for WG discussion:
1) In the sentence "To aid interoperability, RDAP providers
are RECOMMENDED to use as map keys the following string
values and labels defined in [RFC5733].", should  "are
RECOMMNEDED to" be replaced with "MUST"?
2)  Does the portion of the spec for jCard to JSContact
transition signaling add significant implementation overhead
  

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Gavin Brown]

On 8 Dec 2021, at 09:55, Mario Loffredo  wrote:
> 
> 
> 
> Il 07/12/2021 14:42, Marc Blanchet ha scritto:
>> 
>>> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
>>>  a écrit :
>>> 
>>> We can *certainly* do that, Mario. It’s the option I support because there 
>>> is a cost to replace a jCard implementation once it’s been implemented and 
>>> deployed. Make it an optional extension and let server operators decide 
>>> if/when they want to make the change.
>>>  
>>> I note that this will make life more difficult for client implementors 
>>> because they’ll have to support both formats.
>> 
>> But the genie is already out of the bottle… I.e. if one have done a client 
>> implementation, it has already support for jCard. Adding the JSContact is 
>> just more code.  There will be only less work if one is implementing a 
>> client in the future after the whole ecosystem had moved to JSContact, 
>> therefore no need to implement jCard, which is still a good win, as I guess 
>> that many haven’t implemented a client yet since whois is still dominant and 
>> RDAP is not yet at the same level.
> +1
> 
> Every extension requires an implementation effort and every transition 
> process from the old to the new requires a period where both coexist. 
> 
> If we hadn't been aware of that, we wouldn't have started the process to 
> replace Whois with RDAP. And, like Marc pointed out, this process is still at 
> the beginning  and we still don't imagine when it will really be completed.
> 
> In addition to that, I wonder why some members are so worried about the 
> implementation effort done in this case in comparison to other extensions 
> that completed the reviewing process.

Speaking as a client implementer, the amount of work required to update my RDAP 
client to support JSContact was minimal - which speaks to how much easier 
JSContact is to work with than jCard. You can see every change required in 
https://client.rdap.org here:

https://gitlab.centralnic.com/centralnic/rdap-web-client/-/compare/ba4fd514...c9deae03

Getting JSContact working in the CentralNic RDAP server took a bit more work, 
but I see it as being worthwhile if it makes life easier for client 
implementers.

We are still in the early days of RDAP, and the amount of RDAP code that exists 
now is much smaller than the amount of RDAP code still to be written. If we can 
make a modest change now that makes that future code smaller and easier to 
write and maintain, we should do so.

(full disclosure: I am a co-author on this draft).

G.

> 
> For example, why haven't we been so concerned about the implementation effort 
> required to client and servers in order to implement the EPP Login Security 
> extension and the consequent period where clients and servers should deal 
> with both the password formats ? And what about the implementation effort 
> done to replace custom solutions already existing with new standard solutions?
> 
> Honestly, it seems to me that the implementation effort required in this case 
> is lower than the one required by other extensions.
> 
> I believe that the main point is if we (intended as most of us) finally agree 
> that the benefits from implementing an extension far outweigh the required 
> efforts and we have evidence that 
> 
> the new will be significantly better than the old (and it seems to me we have 
> it in this case).
> 
> But, at the same time, we are not sure that the majority of EPP or RDAP 
> operators will implement it. That's it.
> 
> 
> 
> 
> That being said, IMO, the status of this document should remain "Standard 
> Track".

+1

> 
> 
> 
> Best,
> 
> Mario
> 
>> 
>>> “Be liberal in what you accept” applies.
>> 
>> yes.
>> 
>> Marc.
>> 
>>>  
>>> Scott
>>>  
>>> From: regext  On Behalf Of Mario Loffredo
>>> Sent: Tuesday, December 7, 2021 3:45 AM
>>> To: Antoin Verschuren ; regext@ietf.org
>>> Subject: [EXTERNAL] Re: [regext] New Version Notification for 
>>> draft-ietf-regext-rdap-jscontact-04.txt
>>>  
>>> 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 all,
>>> 
>>> maybe I'm missing something but is there anybody explaining me why we can 
>>> have two standards for the email address in EPP but we cannot have two 
>>> standards for the contact card in RDAP ?
>>> 
>>> I admit that the reasons supporting the two documents are different but 
>>> their matters appear very similar to me. 
>>> 
>>> Using JSContact inside RDAP is basically an extension. 
>>> 
>>> If we remove stages 3 and 4 of the transition from the document, we simply 
>>> have an RDAP extension that is or isn't implemented  by a server.
>>> 
>>> This extension can be firstly signaled by the server, then requested by the 
>>> client and consequently returned by the server just as it happens for the 
>>> EAI extension in the EPP context. 
>>> 
>>>  
>>> 
>>> Best,
>>> 
>>> Mario
>>> 
>>>  
>>> 
>>> Il 06/12

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Gould, James]

I view the jscontact is a valid use case for a standards track RDAP extension.  
We have many similar use cases for standards track extensions in EPP, where the 
RFCs couldn't envision a feature or an approach that comes up later.  The 
jscontact draft needs to be defined as an RDAP extension that is optional, with 
the appropriate signaling, and with transition considerations to support a 
transition from the jCard defined in RFC 9083 to JSContact defined in the 
extension.  I don't foresee that support for jCard will go away, but that 
JSContact can be become an alternative and potentially a preferred format for 
the RDAP contact data.  As Scott points out, supporting multiple formats can 
add complexity, but I believe that is a known cost to progress.  

-- 
 
JG



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


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

Verisign.com 

On 12/8/21, 5:31 AM, "regext on behalf of Gavin Brown" 
 wrote:


On 8 Dec 2021, at 09:55, Mario Loffredo  wrote:
> 
> 
> 
> Il 07/12/2021 14:42, Marc Blanchet ha scritto:
>> 
>>> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
 a écrit :
>>> 
>>> We can *certainly* do that, Mario. It’s the option I support because 
there is a cost to replace a jCard implementation once it’s been implemented 
and deployed. Make it an optional extension and let server operators decide 
if/when they want to make the change.
>>>  
>>> I note that this will make life more difficult for client implementors 
because they’ll have to support both formats.
>> 
>> But the genie is already out of the bottle… I.e. if one have done a 
client implementation, it has already support for jCard. Adding the JSContact 
is just more code.  There will be only less work if one is implementing a 
client in the future after the whole ecosystem had moved to JSContact, 
therefore no need to implement jCard, which is still a good win, as I guess 
that many haven’t implemented a client yet since whois is still dominant and 
RDAP is not yet at the same level.
> +1
> 
> Every extension requires an implementation effort and every transition 
process from the old to the new requires a period where both coexist. 
> 
> If we hadn't been aware of that, we wouldn't have started the process to 
replace Whois with RDAP. And, like Marc pointed out, this process is still at 
the beginning  and we still don't imagine when it will really be completed.
> 
> In addition to that, I wonder why some members are so worried about the 
implementation effort done in this case in comparison to other extensions that 
completed the reviewing process.

Speaking as a client implementer, the amount of work required to update my 
RDAP client to support JSContact was minimal - which speaks to how much easier 
JSContact is to work with than jCard. You can see every change required in 
https://client.rdap.org here:


https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03

Getting JSContact working in the CentralNic RDAP server took a bit more 
work, but I see it as being worthwhile if it makes life easier for client 
implementers.

We are still in the early days of RDAP, and the amount of RDAP code that 
exists now is much smaller than the amount of RDAP code still to be written. If 
we can make a modest change now that makes that future code smaller and easier 
to write and maintain, we should do so.

(full disclosure: I am a co-author on this draft).

G.

> 
> For example, why haven't we been so concerned about the implementation 
effort required to client and servers in order to implement the EPP Login 
Security extension and the consequent period where clients and servers should 
deal with both the password formats ? And what about the implementation effort 
done to replace custom solutions already existing with new standard solutions?
> 
> Honestly, it seems to me that the implementation effort required in this 
case is lower than the one required by other extensions.
> 
> I believe that the main point is if we (intended as most of us) finally 
agree that the benefits from implementing an extension far outweigh the 
required efforts and we have evidence that 
> 
> the new will be significantly better than the old (and it seems to me we 
have it in this case).
> 
> But, at the same time, we are not sure that the majority of EPP or RDAP 
operators will implement it. That's it.
> 
> 
> 
> 
> That being said, IMO, the status of this document should remain "Standard 
Track".

+1

> 

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

[Hollenbeck, Scott]

Mario, I've been thinking about this a bit and I have a slightly different 
proposal to suggest. See below.

> -Original Message-
> From: Mario Loffredo 
> Sent: Monday, November 8, 2021 3:58 PM
> To: Hollenbeck, Scott ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-
> 08.txt
>
> 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 folks,
>
> I think the first point we need to discuss is if we should introduce two
> conformance tags for this extension:
>
> - "rdap_openidc_level_0" used by RDAP servers to signal that they
> implement SSO through the OIDC services provided by a local OP
>
> - "rdap_federation_level_0" used by RDAP servers to signal that they
> implement SSO through the OIDC services provided by a set of trusted
> external OPs

[SAH] I'd like to keep these values aligned to note the distinction between 
support for a local OP and eternal Ops. What about something like this?

rdap_openidc_local_level_0 (or maybe "internal" instead of "local")
rdap_openidc_remote_level_0 (or maybe "external" instead of "remote")

A server could support one or both of these. If only one is supported, the 
client will need to send queries a certain way as described below. If both are 
supported, the client can send queries without the id parameter to use the 
local OP, and with the id parameter to use a remote OP.

Note that this means that a server that supports rdap_openidc_local_level_0 
can't distinguish between a query for which authentication is requested and a 
query without an authentication request. A query without the id parameter will 
look like a "standard" RDAP query. Is that a feature or a bug?

> To start a SSO session with a server that is rdap_openidc_level_0
> conformant, an end user operating through a web browser:
>
> - sends a query to /tokens endpoint of the RDAP server without the id
> parameter
>
> - is authenticated by the local OP (i.e. by filling out the login form)
>
> - receives the access_token and uses it as either bearer or query parameter
> for submitting requests towards standard endpoints of the RDAP server
>
> - requests for token refreshment and revoking without including the id
> parameter
>
> In this scenario, the id parameter is ignored.
>
> To start a SSO session with a server that is rdap_federation_level_0
> conformant, an end user operating through a web browser:
>
> - sends a query to /tokens endpoint of the RDAP server including the id
> parameter
>
> - is authenticated by the OP discovered through the OpenID Discovering
> process (i.e. by filling out the login form)
>
> - receives the access_token and uses it as either bearer or query parameter
> for submitting requests towards standard endpoints of the RDAP server
>
> - requests for token refreshment and revoking including the id parameter
>
> In this scenario, the id parameter is required.

[SAH] I think this can work.

> Some futher considerations support my proposal of splitting the
> conformance in two:
>
> 1) AFAIK, the available OPs provide built-in OIDC features supporting the
> implementation of the Authorization Code Flow. But this doesn't apply for
> the features required to implement federation such as OP discovery and
> dynamic client registration. Therefore, while SSO could be implemented
> without knowing OIDC in depth, RDAP developers on server side should
> tackle the implementation of a federation at a lower level.
>
> 2) Joining a federation doesn't only imply the implementation of such
> additional OIDC features but also an agreement between all the parties
> involved as it is described in https://secure-
> web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> federation-1_0.html
>  web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> federation-1_0.html>. For this reason, it seems to me that a federation
> represents a layer upon the implementaion of OIDC to support
> authentication and SSO.
>
> 3) Currently, some OPs provide support external authentication through
> other mechanisms (e.g identity brokering, social login). Briefly, instead of
> discovering the OP from a user identifier, the user is directly requested to
> select in a list of trusted O