Re: [regext] Web Service Client Flow

[Pawel Kowalik <[e-mail]>]

Hi Scott,

Am 30.11.22 um 17:39 schrieb Hollenbeck, Scott:
>> -----Original Message-----
>> From: Pawel Kowalik <[e-mail]>
>> Sent: Wednesday, November 30, 2022 11:15 AM
>> To: Hollenbeck, Scott <[e-mail]>; [e-mail];
>> [e-mail]
>> 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