Hi Scott,
Am 30.11.22 um 17:39 schrieb Hollenbeck, Scott:
-----Original Message-----
From: Pawel Kowalik <kowa...@denic.de>
Sent: Wednesday, November 30, 2022 11:15 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>; mario.loffr...@iit.cnr.it;
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Web Service Client Flow
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 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 request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
[SAH] The draft inherits a definition of "client" from RFC 7480. That's
spelled out in the "terminology" section.
[PK2] Indeed I overlooked that. The definition in RFC 7480 actually
refers to HTTP user agent, so RFC 2616 definition.
RFC 6749 has a different definition:
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
When we now talk of "session-oriented" clients, we actually mean "user
agent"
as per RFC 2616 which supports cookies for session management, whereas
"token-oriented" clients are in fact clients in sense of RFC 6749.
[SAH] OK, so what's the best way to identify these two types of clients in the
draft given the RDAP definition of "client" found in RFC 7480?
[PK2] My proposal:
Clients that want to delegate OIDC Authentication to RDAP server as part of
session-oriented interactions and can accept and process HTTP cookies [RFC6265] to
maintain the session are known as "session-oriented" clients. This type of RDAP
client performs the role of user agent [RFC2616]. An RDAP server performs the role of an
OpenID Connect Core Relying Party (RP). A web browser used to send queries directly to an
RDAP server is an example of a session-oriented client.
Clients that perform OIDC Authentication directly taking the role of an RP in
interactions with an OP and send access tokens [RFC6749] to an RDAP server to authorize
RDAP queries are known as "token-oriented" clients. An RDAP server performs
resource server functions [RFC6749] to verify the tokens received from the client and RP
functions to retrieve information from the OP as necessary to make access control
decisions. A web browser running JavaScript received from a web service that sends
queries to an RDAP server directly or through its backend web service is an example of a
token-oriented client.
In the definition of "token-oriented" clients there needs to be a
differentiation
between OIDC interactions and OAuth2 interactions.
In our scenario RDAP server is a resource server as per RFC 6749, a role
which
does not exist explicitly in OIDC - or to be fully correct is fulfilled by
OP for its
own userinfo resource.
So it's incorrect to say that RDAP server performs RP functions.
[SAH] Note that the OpenID Connect Core specifications says that "OAuth 2.0
Clients using OpenID Connect are also referred to as Relying Parties (RPs)".
The RDAP server can request claims from an OP using an Access Token. I
described the RDAP server as an RP related to performance of that function.
I'm open to re-wording of the description if it's inaccurate or incomplete.
[PK2] See proposal above. Getting information from OP can be seen as RP
function whereas token verification isn't.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
