A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Demonstration of Proof-of-Possession at the
Application Layer (DPoP)
Authors : Daniel
Thanks Mike for sharing this summary of what sounds like it was a valuable
discussion. I'm sorry that I wasn't "at" IIW so wasn't able to participate
in the session.
I will endeavor to incorporate the open issues into the presentation on
DPoP for the virtual interim on Monday
I created a pull request https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/4
> On 1. May 2020, at 18:16, Mike Jones
> wrote:
>
> I believe that Nat hasn’t yet published the JAR updates that Brian made. Do
> we want to add this text to the editor’s draft before publishing?
>
>
Works for me.
From: OAuth On Behalf Of Torsten Lodderstedt
Sent: Friday, May 1, 2020 2:51 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
Filip´s proposal works for me.
Are there any objections?
Brian Campbell
Works for me also
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Filip´s proposal works for me.
Are there any objections?
Brian Campbell schrieb am Mo.
27. Apr. 2020 um 20:57:
> While there are certainly different permutations and contexts of use that
> could be imagine, I tend to agree with Filip here in not seeing a strong
> need to define new PAR
wfm - thanks.
Brian Campbell schrieb am Mo.
27. Apr. 2020 um 21:06:
> require_pushed_authorization_requests works for me and is maybe/arguably a
> bit better by being more consistent with other names.
>
> On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan wrote:
>
>> Alternatively,
Thanks Mike.
I suggest to add text to JAR describing use of this registry values to
determine the request object signing and encryption algorithms.
Mike Jones schrieb am Mi.
29. Apr. 2020 um 01:38:
> “request_object_signing_alg_values_supported” and other AS Metadata values
> defined by OpenID
Comments on draft-ietf-oauth-dpop-00.
1) In section 9 (Security considerations), the text states:
DPoP does not, however, achieve the
same level of protection as TLS-based methods such as OAuth Mutual
TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
(see also Section 9.1 and
