I agree that without a tight binding between the RS and AS we need to
revisit RS meta-data.
It is a can of worms however.
On 4/17/2020 2:39 PM, Torsten Lodderstedt wrote:
> I think the same is already true for mTLS. Solving it in an
> interoperable way would require some metadata about RS and
I think the same is already true for mTLS. Solving it in an interoperable way
would require some metadata about RS and their requirements re mTLS/DPoP. Shall
we revitalize the idea of RS metadata?
> Am 17.04.2020 um 17:37 schrieb George Fletcher
> :
>
> This brings up interesting rollout
All,
You can find this meeting minutes at the following link:
https://datatracker.ietf.org/doc/minutes-interim-2020-oauth-04-202004131200/
Thanks to *Jared Jennings *for taking these notes.
Regards,
Rifaat & Hannes
On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary
wrote:
> The Web
This brings up interesting rollout questions. Protecting just the
refresh_token is easy and a useful security measure (especially if
access tokens are short lived). However, once you start issuing DPoP
bound access tokens to a client, it means ALL the endpoints that client
invokes MUST
I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and
The idea of “Continuing to work without taking advantage of sender constraints”
is, I would argue, a security hole. Systems are allowed to fail security checks
but still offer functionality. This is exactly the pattern behind allowing an
unsigned JWT because you checked the “alg" header and it
I don't know about a PAR "requirement", but it feels like the PAR spec
is the right place to put this. My understanding of what's being asked
is... how does the AS advertise to it's clients that it will ONLY accept
PAR based request_uris and other authn/authz request methods will fail.
On
Is this really a PAR requirement? I’m asking since the client in the end is
required to use an authorization request in the fron channel but with a PAR
request_uri. So one could see this as a constrained on the authorisation
request itself. Another question is whether this request_uri must be
