Re: [regext] Web Service Client Flow

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Pawel Kowalik <[e-mail]>
> Sent: Friday, December 2, 2022 9:45 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,
>
> 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.

[SAH] Thanks, this works for me. I'll get it into -20.

Scott