[OAUTH-WG] Re: SD-JWT linkability

> On 23 Dec 2024, at 16:02, Denis wrote: > > Joseph wrote: > > I believe I've said that, including in your PR I linked above: there are > situations where SD-JWT is the best currently available deployable technology > for a user disclosing their age to a verifier, and yes, it is absolutely

[OAUTH-WG] Re: SD-JWT linkability

Hi > On 22 Dec 2024, at 20:35, Watson Ladd wrote: > > The fact that you and everyone else feels content to shoot down text > rather than try to meet me halfway shows that this isn't an honest > attempt to achieve rough consensus or conversely say my views are in > the rough because of actually t

[OAUTH-WG] Re: SD-JWT linkability

> On 21 Dec 2024, at 19:10, Watson Ladd wrote: > > On Sat, Dec 21, 2024, 8:26 AM Joseph Heenan <mailto:jos...@authlete.com>> wrote: >> >> >> >> On 20 Dec 2024, at 18:07, Watson Ladd wrote: >> >> On Fri, Dec 20, 2024 at 9:47 AM Josep

[OAUTH-WG] Re: SD-JWT linkability

> On 20 Dec 2024, at 18:07, Watson Ladd wrote: > > On Fri, Dec 20, 2024 at 9:47 AM Joseph Heenan wrote: >> >> >> >> On 19 Dec 2024, at 21:54, Watson Ladd wrote: >> >> On Tue, Dec 17, 2024, 1:59 PM Joseph Heenan wrote: >> >>

[OAUTH-WG] Re: SD-JWT linkability

> On 19 Dec 2024, at 21:54, Watson Ladd wrote: > > On Tue, Dec 17, 2024, 1:59 PM Joseph Heenan <mailto:jos...@authlete.com>> wrote: >> >> Hi Watson >> >> Just to respond to the suggested text: >> >>> >>> "When disclos

[OAUTH-WG] Re: SD-JWT linkability

Hi Watson Just to respond to the suggested text: > > "When disclosures include information easily understood to be > identifying, users intuitive view of what they are revealing largely > matches the underlying technical reality. In cases where the > information being disclosed is not identifyin

[OAUTH-WG] Re: Call for adoption - First Party Apps

Hi I strongly support adoption. Joseph > On 3 Sep 2024, at 11:46, Rifaat Shekh-Yusef wrote: > > All, > > As per the discussion in Vancouver, this is a call for adoption for the First > Party Apps draft: > https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ > > Please, re

[OAUTH-WG] CISA Cyber Safety Review Board Report recommendations to IETF

Hi all I don’t believe the CISA report linked from this page has been discussed in the OAuth group yet: https://www.cisa.gov/resources-tools/resources/cyber-safety-review-board-releases-report-microsoft-online-exchange-incident-summer-2023 Of particular note is that IETF and I think implicitly

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

> On 8 May 2024, at 21:43, Sam Goto wrote: > > > > On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <mailto:jos...@authlete.com>> wrote: >> Hi Neil >> >> >>> On 8 May 2024, at 18:45, Neil Madden >> <mailto:neil.e.mad...@gmail.c

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Hi Neil > On 8 May 2024, at 18:45, Neil Madden wrote: > > >> On 8 May 2024, at 17:52, Sam Goto wrote: >> >> On Wed, May 8, 2024 at 7:23 AM Neil Madden > > wrote: > >> >>> In particular, the call to the accounts endpoint assumes that the IdP is >>> willing

Re: [OAUTH-WG] Call for adoption - Transaction Tokens

I support adoption. Joseph > On 14 Nov 2023, at 12:57, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Transaction Tokens draft: > https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] Call for adoption - Identity Chaining

I supported adoption. Joseph > On 14 Nov 2023, at 12:58, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Identity Chaining draft: > https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ > > Please, reply on the mailing list and l

Re: [OAUTH-WG] PAR request_uri questions/guidance

Hi Brock Answers inline: > On 28 Sep 2023, at 19:39, Brock Allen wrote: > > Hello -- > > While implementing PAR, some questions came up around the request_uri, > expiration, and one-time use semantics. > > 1: I found this conversation: > https://mailarchive.ietf.org/arch/msg/oauth/Xp5Wyt4N9

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

I support adoption. Joseph > On 30 Sep 2023, at 13:52, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the JWT and CWT Status List draft: > https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support adoption. Joseph > On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Protected Resource Metadata > draft: > https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ > > Please, reply on the mailing list and

Re: [OAUTH-WG] Scoring OAuth authorization servers on best practices

Hi It’s not exactly what you asked for, but https://oauch.io/ was aiming to do this - although the online site currently seems to give a 500 error after logging in for me. I’m sure the team behind it were planning to publish the results of the tool, but I can’t remember if they did yet. There

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

Hi all I support adoption of this document. Thanks Joseph > On 15 Nov 2022, at 14:43, Rifaat Shekh-Yusef wrote: > > All, > > During the IETF meeting last week, there was a strong support for the > adoption of the following document as a WG document: > https://datatracker.ietf.org/doc/draft

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 2

Hi Dmitry Yes, the OpenID Foundation conformance suite will include tests for DPoP as part of the FAPI2 test suite. The tests already exist and can be run, but they are not yet complete (some negative tests are missing, nonces are not yet supported, etc). If you (or anyone else) would like to

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-dev

[OAUTH-WG] OAuth security BCP: Lifetime of authorization codes

Hi all I couldn't find any text in the current BCP document about the lifetime of authorization codes, do people think that this may be worth mentioning? The only guidance I could find on authorization code lifetimes is RFC 6749, 4.1.2: "A maximum authorization code lifetime of 10 minutes is R

Re: [OAUTH-WG] DPoP - Impementations

Hi Rifaat The OpenID Foundation FAPI2 certification tools have implementations of / tests for (most of) DPoP as both an AS/RS & client. Authlete has implemented DPoP as an AS / RS. Thanks Joseph > On 10 Aug 2022, at 22:39, Rifaat Shekh-Yusef wrote: > > All, > > As part of the shepherd writ

Re: [OAUTH-WG] Call for adoption - SD-JWT

I support adoption. Joseph Heenan > On 29 Jul 2022, at 01:16, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption for the SD-JWT document > https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ > <https://datatracker.ietf.

Re: [OAUTH-WG] Comments on ietf-oauth-dpop

Hi Rohan, > On 22 Mar 2022, at 15:24, Rohan Mahy > wrote: > > Here are some comments on draft-ietf-oauth-dpop-06: > > 1) With such a significant attack possible as DPoP proof pre-generation, why > isn't using the server nonce a SHOULD? Preventing a significant attack and > making lifetime h

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

Hi Daniel I do think it’s a problem that’s worth addressing somehow. I think there’s another factor, which is that the providers of OAuth2 Authorization Servers (where they don’t have their own SDKs specific to their server) tend to lead the developer through how to do a “from scratch” impleme

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

etter than I could have given and matches my > understanding as well. > > Thanks, > George > > On 11/3/20 2:13 PM, Dick Hardt wrote: >> Thanks Joseph. >> >> George Fletcher ran a great session on the topic at the last IIW as well. >> >> George: do you

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

Hi Dick I didn’t attend the call so don’t know the background of this and the exact situation, but the general problem is mostly where the Authorization Server’s app is *not* installed. In that case Android falls back to much weaker mechanisms that allow other apps to get a look in. App links a

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

I agree, it is in redundant in the JARM case. I find the text in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I think it would be good to say something along

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

I agree with Brian here, I think “typ”:”JWT” should be permitted as well as no typ and “typ”: "oauth.authz.req+jwt". There are other tests we could write for JAR that an OIDC server will fail (for example, one that tested the behaviour of passing a value only outside the request object - which

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

Thanks Rifaat, Hannes, and also thanks to all the authors. I’ve been through the latest spec and it basically looks great to me; I raised 3 minor niggles under https://github.com/oauthstuff/draft-oauth-par/issues https://github.com/oauthstu

Re: [OAUTH-WG] Namespacing "type" in RAR

I’d agree with this. I’d probably go even further and suggest the specification simply disallow non-ASCII values - it just seems like a minefield that so many people have unsuccessfully attempted to negotiate, and it is not necessary to force or allow AS implementors (or the rest of the ecosyste

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Hi James, > On 5 Jun 2020, at 03:23, Manger, James > wrote: > If you merely want to trigger a different look-n-feel, define a “brand” > parameter to add the to the authorization request. Unfortunately this doesn’t work when the authorization endpoint is a claimed https url for a mobile app:

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Hi Francis, > On 3 Jun 2020, at 18:07, Francis Pouatcha > wrote: > > Hello Dave, > > I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery > doc, however that is not always possible. > > I'd like to understand Francis what particular issue you see from allowing an > A

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

of bank chooser. Will this chooser provide the client with issuer and brand >>> id? >>> >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov >>>> <mailto:vladi...@connect2id.com> wrote: >>>> >>>> A mapping like the one yo

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

gt;> >>> A mapping like the one you propose can definitely work. Since the user will >>> be making the choice which endpoint to take with the client app, having the >>> logo_uri is a good idea. If the branded endpoints differ somehow in policy >>> one could al

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

letely separate, then it seems sensible that each brand >> must have its own `issuer` and therefore its own discovery document at the >> correct location (i.e. brand 1 would have an issuer of "https://as/brand1 >> <https://as/brand1>" and a discovery docu

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

JAR Server | OIDC Server | > > ++--+ > > JAR Client | YES| NO | > > OIDC Client | YES| YES | > > > > Breaking one out of the four possible combinations in a very predictable

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

one out of the four possible combinations in a very predictable way >> is, I think, the best way to handle backwards compatibility here. >> >> But between this issue and JAR’s problematic call for the value of a >> request_uri to always be a JWT and be fetchable by the AS

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

I agree with this, particularly the security concerns of merging. If we merge, we can much guarantee there will eventually be a security issue where an attacker is able to gain an advantage by adding a parameter to the url query (which the server would then happily process if that parameter isn’

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

+1 > On 8 Jan 2020, at 03:31, Steinar Noem wrote: > > +1 > > tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt > >: > +1 > > > On 7. Jan 2020, at 17:25, Brian Campbell > > > > wrote: > > > > +1 > > >

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

I support the adoption of PAR. Thanks Joseph > On 17 Dec 2019, at 12:59, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >

Re: [OAUTH-WG] Question regarding RFC 8628

Hi Hervé > On 18 Nov 2019, at 14:20, Robache Hervé wrote: > > Thanks Joseph > > I agree with you. There should be no issue when the URL is registered during > the TPP app installation. > > From my perspective, this URL should be passed during the authorization > request within the [redirec

Re: [OAUTH-WG] Question regarding RFC 8628

Hi all, Thanks, Torsten. > On 18 Nov 2019, at 13:22, Torsten Lodderstedt wrote: > > Hi Hervé, > > looping in Joseph. > >> On 18. Nov 2019, at 21:17, Robache Hervé > > wrote: >> >> Thanks Torsten >> >> Yes, we study this flow as well. Actually we consider the tw

Re: [OAUTH-WG] embedded UA detection

Hi Giada, All methods can be bypassed by an attacker that has control of the app in question, it’s just a matter of effort. I believe many AS’s use client side javascript to provide a harder to bypass implementation. Your aim here is probably mainly to prevent naive developers “accidentally” (o

Re: [OAUTH-WG] Device Authorization Grant Interval

Hi Janak, Interestingly this came up when discussing the CIBA specification (which builds upon device authorization grant to some extent) recently: https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-when-client-polls The thought that group came up with is that returning ‘inv

Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Hi all, It’s worth adding that a per-instance dynamic registration of a native client can still imply a higher level of trust than a public client and registration isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines an “initial access token”: > OAuth 2.0 access token

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

Hi Torsten, A few comments having just read this afresh: 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given it appears to be permitted? I find it a little hard to understand exactly what "avoid any redirects or forwards which can be parameterized by URI query paramete

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Aaron, Thanks for putting this document together, I think this kind of guidance is invaluable. It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing in

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

Hi Denis, This presentation is only describing one attack. Page 12 summarises it. The attack is not a full attack targeted against oauth, but it shows how a malicious network can steal any codes returned to the browser in the URL, even if the codes are always sent over TLS. I was only respondi

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

Hi Denis, > On 22 May 2018, at 14:05, Denis wrote: > In particular, the text states: > >"Clients shall use PKCE [RFC7636] in order to (with the help of the > authorization server) detect and prevent attempts > to inject (replay) authorization codes into the authorization > res

Re: [OAUTH-WG] Token Revocation error codes

I think one important point Sergey raised was that the response to the client from submitting the wrong token is the same 200 response as submitting a valid token, and that hugely increases the chance that the developer of the client app might submit the wrong token and never realise. Making it

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi Torsten, As we briefly spoke about earlier, "3.8.1. Authorization Server as Open Redirector" could I think be made more explicit. Currently it explicitly mentions the invalid_request and invalid_scope errors must not redirect back to the client's registered redirect uri. https://tools.ietf.