Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

August will conflict with holiday time for most Europeans… Just been to Trondheim last week - it was lovely weather. ——— Dominick On 25. July 2019 at 22:14:28, Mike Jones ( michael.jones=40microsoft@dmarc.ietf.org) wrote: I'm not aware of any conflicts for any of the three sets of dates. -

Re: [OAUTH-WG] IETF Meetup for XYZ

FWIW: We are meeting in the main lobby outside of Centre-Ville. — Justin On Jul 24, 2019, at 7:41 PM, Justin Richer mailto:jric...@mit.edu>> wrote: Hi all, I was talking with Hannes, and we’d like to propose a dinner meetup tomorrow (Thursday) for anyone who wants to discuss XYZ in more detai

[OAUTH-WG] [Technical Errata Reported] RFC6749 (5793)

The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5793 -- Type: Technical Reported by: Martin

[OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)

Dear all, draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a JWS' signature (the client's key) (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2). However there no such guidance for JWE encryption: * any "enc" key published by the AS on its jwks_uri? *

[OAUTH-WG] Secdir last call review of draft-ietf-oauth-mtls-15

Reviewer: Vincent Roca Review result: Ready Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors a

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

I'm not aware of any conflicts for any of the three sets of dates. -- Mike -Original Message- From: OAuth On Behalf Of Aaron Parecki Sent: Thursday, July 25, 2019 4:07 PM To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Location and dates for next OAu

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day! All of the dates work for me, but I would prefer the July dates since it'll be easier/cheaper to bundle the two trips into one. (Hopefully we could get the OAuth meeting dates early in the week at IETF then) On Thu, Jul 25, 2019 at 3

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

+1 to July / August. Nicer weather in the north then. =) On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett wrote: > Hi all, > > it seems like there is a rough consensus on having the next OAuth Security > Workshop in Trondheim, Norway. We will therefore start with the planning. > > After checking var

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> Am 24.07.2019 um 09:50 schrieb Tomek Stojecki > : > > I agree that 6.1 takes too broad of a swipe, but I'd say with same-site > cookies and (sadly) without token-binding, the suggestion to use cookie based > session following oauth/oidc auth is a good one and should be incorporated > perha

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> I agree, I removed the mention of OIDC. If that means you'd leave the OAuth prohibition, it's still misleading or confusing. OIDC is of course an extension of or layer over OAuth. If you prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's the way it reads. On Thu, Jul

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> Am 24.07.2019 um 04:13 schrieb David Waite : > > Perhaps it should be turned into a stated document assumption (that the > reader has decided to use OAuth) rather than guidance later in the document > (that OAuth may not be the best fit) +1 smime.p7s Description: S/MIME cryptographic signa

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Am 24.07.2019 um 22:13 schrieb Aaron Parecki : >> 2) Regarding architectures: I think this BCP should focus on recommendations >> for securely implementing OAuth in the different potential architecture. I >> don’t think we should get into the business of recommending and assessing >> other so

[OAUTH-WG] RFC7009: what to return when revoking a token which is not the client's?

Hi, In RFC7009 - section 2.1 (https://tools.ietf.org/html/rfc7009#section-2.1), it is stated that: The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation requ

[OAUTH-WG] Location and dates for next OAuth Security Workshop

Hi all, it seems like there is a rough consensus on having the next OAuth Security Workshop in Trondheim, Norway. We will therefore start with the planning. After checking various event calendars it seems like the following dates are suitable: ** * * May 7-9 * July 22-24 *

Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

Filip, thank you for your reply. Additional remarks inline. On 25.07.2019 21:14, Filip Skokan wrote: See my reply inline. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс > wrote: In https://tools.ietf.org/html/draft-ietf-oau

Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

You're welcome, of course. And thanks for the prompt response. I've endeavored to continue the parts of the conversation that needed continuing below. On Wed, Jul 24, 2019 at 3:46 PM Vittorio Bertocci wrote: > Thank you Brian for the thorough and insightful review! > Comments: > > > On authentic

Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

See my reply inline. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс wrote: > In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it > is stated that an error is to be returned when the object request is > invalid. These errors are "invalid_request_uri"

[OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it is stated that an error is to be returned when the object request is invalid. These errors are "invalid_request_uri" and "invalid_request_object". However, to which redirect URI redirect in the following cases: * the reque

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

I also think it would be useful, but a problem is that things like “application type” are usually a stand in for a whole bunch of different attributes that we actually care about. That’s what happened with web/native and why, to my knowledge, nobody really uses those in lieu of things like publi

Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

Some notes and minor corrections: > Abstract "OAuth2" should be "OAuth 2.0" > 1. Introduction "many important scenario" should be "scenarios" "OAuth2" should be "OAuth 2.0" > 2.1. Header > ... use of asymmetric algorithms is RECOMMENDED Has anyone implemented or does anyone have plans to impl

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> > Obviously it can do it on a per-client basis still, but now an AS is going > to have to know a bit more about the app itself. Perhaps we finally need a > few more entries in the “application_type” metadata parameter from OIDC’s > extension RFC7591 beyond “native” and “web”? But we at least prob

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients. Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone. Similar

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> On Jul 24, 2019, at 3:03 PM, Aaron Parecki wrote: > > On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier > wrote: > >> I would rather say that ANY JS app should use CSP to lock down the browser >> features to a minimal attack surface. In addition, if refresh or access >> tokens are involve