Based on the discussion during the last interim meeting series, the plan is
to schedule another series of these meetings with times/dates that work for
the WG.
Regards,
Rifaat
On Fri, Jun 12, 2020 at 5:48 PM Brian Campbell
wrote:
> No OAuth WG sessions planned for the 108 meeting?
>
> On Fri,
No OAuth WG sessions planned for the 108 meeting?
On Fri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool <
session-requ...@ietf.org> wrote:
>
>
> Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the
> oauth working group does not plan to hold a session at IETF 108
Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the
oauth working group does not plan to hold a session at IETF 108.
This message was generated and sent by the IETF Meeting Session Request Tool.
___
OAuth mailing list
OAuth@
Hi,
Sorry for the late reply. I and John were really busy lately partly due to
COVID-19 thing and could not respond in a timely fashion.
I just replied to one of the thread that you posed a question about. Is
that the question you mentioned in this email?
Best,
Nat Sakimura
On Sun, May 31, 2020
My take is that the basic assumption of OAuth 2.0 Framework is that there
is a strong relationship between AS and RS.
I feel that it is quite unrealistic that an RS would trust the access token
issued by an AS that it has no strong relationship with.
Your scenario is more like in the case where a u
Am 11.06.20 um 23:17 schrieb Brian Campbell:
>
> Also to help facilitate mixed or rollout deployments, I'm not sure
> about "An client should never send a DPoP [bound access] token as a
> Bearer header." Such a constraint could be put on the client but it
> seems unhelpful. A bad acting client cou
