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-boun...@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-boun...@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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
