Hi Scott,
please find my comments inline.
Il 08/12/2021 19:26, Hollenbeck, Scott ha scritto:
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 <mario.loffr...@iit.cnr.it>
Sent: Monday, November 8, 2021 3:58 PM
To: Hollenbeck, Scott <shollenb...@verisign.com>; 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")
Sounds good.
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?
What does it mean "standard"? If it means coming from an anonymous user,
the response is no; it wouldn't look like an anonymous request as the
draft states that using the id parameter is only one method to submit an
authenticated request according the draft.
The other (the reference method in OIDC) is including a valid access
token in the request.
Otherwise, the same request provided as an example in section 4.2 should
be considered anonymous but it isn't.
The difference in dealing with an authenticated/anonymous request mainly
depends on two factors:
- if the request is directed towards a protected endpoint or not
- if the request includes an access token or not
If an endpoint is considered protected, to submit an authenticated
request you need to include an access token in the request or to be
previously authenticated by the OP and then redirected back to the endpoint.
In .it implementation, the standard endpoints are all considered
protected. If you want to access one of them as an authenticated user,
you need to include an access token otherwise you are marked as anonymous.
The /tokens endpoint is the only one requiring an authentication by the
OP. So the logic is: firstly take an access token after being
authenticated by the OP and then use it to submit authenticated requests
to the standard endpoints.
This is also the logic of SSO.
The requests towards /tokens used for refreshing and /tokens/revoke are
transformed in requests coming from an anonymous user because, in these
cases, the server needs only to check for the tokens' validity.
In your model, the server also accepts (let's call them) one-shot
authenticated requests. Such requests always make the OP authenticate
the user before they are redirected to the server.
Best,
Mario
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
<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>. 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 OPs the one which will be in charge of the
authentication.
Hope it could be helpful to move the discussion forward.
[SAH] Agreed. What do others think?
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. 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
