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

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 <regext-bounces@ietf.org> 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 <regext-bounces@ietf.org> On Behalf Of James Galvin
>>>> Sent: Monday, October 3, 2022 8:40 AM
>>>> To: REGEXT WG <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.
>>>>
>>>> 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