Brian,
Thanks for all the hard work that you put into this important document.
We do not mind it when you are vibrant; we know that you always have good
intentions 😀
Regards,
Rifaat
On Wed, Jul 27, 2022 at 6:44 PM Brian Campbell
wrote:
> Thanks Rifaat and others for the vibrant* discussions
Apologies accepted! :-)
Am 28.07.22 um 01:11 schrieb Brian Campbell:
I need to make one more apology - this time for the incorrect spelling
of Dr. Fett's name (should be Daniel not Danial). My apologies.
On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell
wrote:
Thanks Rifaat and others for
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I need to make one more apology - this time for the incorrect spelling of
Dr. Fett's name (should be Daniel not Danial). My apologies.
On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell
wrote:
> Thanks Rifaat and others for the vibrant* discussions about the DPoP draft
> in the side meeting yesterda
Dear Aaron and Warren,
1. Thx a lot for such a quick response. It completely makes sense. The
initial idea was to be a little more elaborate or explicit in mentioning
the preference of choosing one option over the other in the specs itself.
2. Aaron yesterday discussed the idea of having an error
The discussion yesterday was about the redirect_uri parameter at the token
endpoint, not at the authorization endpoint.
The redirect_uri parameter at the authorization endpoint is currently:
* optional if the client has only one redirect URI registered
* required if the client has multiple redire
Can you explain why you think:
>
> But definitely cannot be both (as in the present definition).
>From a theoretical perspective, of course it can be. But perhaps there is a
concrete reason you think otherwise, I think it would be prudent to share
that context explicitly with an explanation here.
Dear Aaron,
1. Yesterday you brought up an important issue of choosing "redirect_uri"
to be REQUIRED vs OPTIONAL parameter at the authorization code endpoint.
The esteemed members had their considered opinion that the definition
should remain as it is.
2. However, I am of the opinion that an impo
Seems to be similar to the intentions of:
https://datatracker.ietf.org/doc/html/rfc8176
and/or
https://openid.net/specs/openid-connect-modrna-authentication-1_0-06.html
--
-jim
Jim Willeke
On Wed, Jul 27, 2022 at 7:45 AM Jaimandeep Singh wrote:
> Dear Aaron and esteemed members,
>
> 1. It was
Dear Aaron and esteemed members,
1. It was good to note that we are planning to simplify the definitions of
confidential and public clients in the new specs. However, my thoughts are
that instead of these definitions which are open to interpretation, we can
work on these two options:
*Option I*:
All,
We will be using Meetecho for today's and tomorrow's meeting.
Hopefully that will help make the remote experience better than yesterday.
Wed:
https://meetings.conf.meetecho.com/interim/?short=4558043e-bafb-4746-9a87-3e5af7486bca
Thu:
https://meetings.conf.meetecho.com/interim/?short=82e0d98
11 matches
Mail list logo
