-rdap-openid Post IETF-115
[SAH] [snip]
Why wouldn't it be OpenID? On the contrary, I would say (as a matter of fact
have always said) that it's the classic OpenID scheme where the RDAP server
acts only as a Resource Server and the RDAP client as a Relying Party.
We all know that OpenID i
> -Original Message-
> From: Mario Loffredo
> Sent: Wednesday, November 16, 2022 2:31 AM
> To: Hollenbeck, Scott ;
> marc.blanc...@viagenie.ca; kowa...@denic.de
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
Hi Scott,
Am 15.11.22 um 17:54 schrieb Hollenbeck, Scott:
[...]
A "pure OAuth2" solution is probably way more warrant of future, IMHO.
Marc.
[SAH] ...but it's not OpenID Connect, which is the focus of the current draft.
Incorporating these concepts into the current draft could mean significant
Hi Scott,
Il 15/11/2022 17:54, Hollenbeck, Scott ha scritto:
-Original Message-
From: Marc Blanchet
Sent: Tuesday, November 15, 2022 10:57 AM
To: Pawel Kowalik
Cc: Hollenbeck, Scott ; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
Caution
> -Original Message-
> From: Marc Blanchet
> Sent: Tuesday, November 15, 2022 10:57 AM
> To: Pawel Kowalik
> Cc: Hollenbeck, Scott ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
>
> Caution: This email ori
> Le 15 nov. 2022 à 10:50, Pawel Kowalik a écrit :
>
> Hi Scott,
>
> Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott:
>> [SAH] Based on the testing you and I've been doing, we already know that web
>> service clients require token processing features that aren't currently
>> specified. That's f
Hi Scott,
Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott:
[SAH] Based on the testing you and I've been doing, we already know that web
service clients require token processing features that aren't currently
specified. That's fixable; earlier versions of the draft included text that
was demonstra
> -Original Message-
> From: regext On Behalf Of Pawel Kowalik
> Sent: Monday, November 14, 2022 12:18 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
>
> Caution: This email originated from outside the organ
> Le 14 nov. 2022 à 09:09, Hollenbeck, Scott
> a écrit :
>
> We need to decide what to do with draft-ietf-regext-rdap-openid and web
> service clients. Our choices:
>
> 1. Finish the draft as-is, noting that it's limited to clients that can
> implement OpenID Connect flows and can process s
Hi all,
my preference would be for option 1; this was my first recommendation
due to my conviction that the session-based approach didn't fit some
clients well.
However, I do believe that we need to take some time to be sure that
what could be defined in the second document couldn't impact o
Scott and everyone in the WG,
Speaking as co-Chair, Antoin and I meet earlier today to decide how to handle
the WGLC for this document. We have decided to pull this back to the WG. I
will be sending a separate note in the WGLC thread to explain this.
Short response is simply that this documen
Hi,
I would opt to work on the option 2, at least to the point we can see
how much both types of clients have in common and how much do they go
split ways.
Based on this the WG could take more educated decision whether to break
it into 2 drafts or remain with one.
Kind Regards,
Pawel
Am
We need to decide what to do with draft-ietf-regext-rdap-openid and web
service clients. Our choices:
1. Finish the draft as-is, noting that it's limited to clients that can
implement OpenID Connect flows and can process session cookies. This implies
that we need another draft to describe OAuth
13 matches
Mail list logo
