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

[Joseph Heenan]

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, reply on the mailing list and let us know if you are in favor or 
> against adopting this draft as WG document, by Sep 17th.
> 
> Regards, 
>  Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Joseph Heenan]

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 (as OIDC is built on top 
of OAuth) the OAuth WG is called out: 

"CSPs and relevant standards bodies, such as OpenID Foundation (OIDF), 
Organization for the Advancement of Structured Information Standards (OASIS), 
and The Internet Engineering Task Force (IETF), should develop or update 
profiles for core digital identity standards such as OIDC and Security 
Assertion Markup Language (SAML) to include requirements and/or security 
considerations around key rotation, stateful credentials, credential linking, 
and key scope.”

From Page 22, 2.1.4, "DIGITAL IDENTITY STANDARDS AND GUIDANCE”, recommendation 
13. (Bold emphasis added by myself.)

Recommendation 11 explicitly recommends DPoP which is nice.

Recommendation 12 is also perhaps in scope for this group, though I can’t say I 
understand how to action it: "Relevant standards bodies should refine and 
update these standards to account for a threat model of advanced nation-state 
attackers targeting core CSP identity systems."

Thanks

Joseph

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Joseph Heenan]

> 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.com>> wrote:
>>> 
>>> 
>>>> On 8 May 2024, at 17:52, Sam Goto >>> <mailto:g...@google.com>> wrote:
>>>> 
>>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden >>> <mailto:neil.e.mad...@gmail.com>> wrote:
>>> 
>>>>  
>>>>> In particular, the call to the accounts endpoint assumes that the IdP is 
>>>>> willing to provide PII about the user to the browser. That seems 
>>>>> questionable. 
>>>> 
>>>> Aside from a privacy/security threat model perspective (meaning, the user 
>>>> agent already has visibility over every network request made available to 
>>>> the content area)
>>> 
>>> Sure, but if I use the recommended auth code flow or encrypted ID tokens, 
>>> then PII is not exposed to the browser. And it’s not just the browser 
>>> itself in the current proposal, as the token is exposed to javascript, of 
>>> course, so the usual XSS risks. 
>> 
>> Sam’s response here is fair, but also note that as far as I understand it 
>> you can still use the authorization code flow or encrypted id tokens with 
>> the FedCM API 
> 
> That's correct: the browser doesn't open the response from the IdP to the RP, 
> so it can, for example, be encrypted.
> 
> I was assuming that Neil was referring to the fact that the 
> id_assertion_endpoint (which contains the user's IdP's PII accounts 
> <https://fedidcg.github.io/FedCM/#dictdef-identityprovideraccount>) become, 
> suddenly, transparent to the browser.

Oh yes, that’s true - but (I think) the data from the id_assertion_endpoint at 
least isn’t exposed to javascript and isn’t vulnerable to XSS?

Joseph

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Joseph Heenan]

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 to provide PII about the user to the browser. That seems 
>>> questionable.
>> 
>> Aside from a privacy/security threat model perspective (meaning, the user 
>> agent already has visibility over every network request made available to 
>> the content area)
> 
> Sure, but if I use the recommended auth code flow or encrypted ID tokens, 
> then PII is not exposed to the browser. And it’s not just the browser itself 
> in the current proposal, as the token is exposed to javascript, of course, so 
> the usual XSS risks. 

Sam’s response here is fair, but also note that as far as I understand it you 
can still use the authorization code flow or encrypted id tokens with the FedCM 
API - this is likely one of the things we need to talk about as we discuss how 
OAuth2 & OpenID Connect are profiled to work with the new API.

Joseph

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Joseph Heenan]

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 us know if you are in favor or 
> against adopting this draft as WG document, by Nov 28th.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 let us know if you are in favor or 
> against adopting this draft as WG document, by Nov 28th.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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/Xp5Wyt4N9U6RZZzMd6RctU3koQw/#
> 
> And so after reading it, my sense is that the request_uri one-time use 
> semantics is "upon successful authorization response". Is that a fair 
> conclusion?

I’m not sure there was a clear conclusion in those messages - I’m definitely 
interested to hear other people’s interpretations.

I have certainly heard of cases on Android where treating the request_uri as 
strictly one time use has resulted in failures due to some browsers appearing 
to fetch the url before launching the deep link as per the web2app pattern. So 
some leeway seems necessary.

> 2: The spec says that a typical range of values for the expiration to be 
> between 5 and 600 seconds. I guess someone with a low value is not expecting 
> the end user to do any sort of interactive login, whereas the higher number 
> is assuming the user does need to perform an interactive login. Is that a 
> fair conclusion? 

I have always expected that the expiry relates to the time until the 
request_uri is presented to the authorization server. If it is not expired at 
that point I think the authorization server server should continue and that the 
expiry time of the request_uri should not be a factor after that.

> 3: Any suggestions for an error response from the authorize endpoint when an 
> expired or consumed request_uri is passed?

invalid_request_uri as per 
https://www.rfc-editor.org/rfc/rfc9101.html#section-7 seems like the 
appropriate one to me, and is the one the various FAPI certification tests that 
test PAR expect.


Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 us know if you are in favor or 
> against adopting this draft as WG document, by Oct 13th.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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’s also the various certification tools the OpenID Foundation have 
(disclaimer: I work on these tools), though [other than the FAPI2 tests] these 
all also require that the server supports OpenID, and they give more of a 
pass/fail rather than a score.

Cheers

Joseph




> On 6 Apr 2023, at 16:41, M Hickford  wrote:
> 
> Has anyone tried scoring how well public OAuth authorization servers
> follow tbe best practices described in
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
> ?
> 
> I scored some software forges including GitHub, GitLab, BitBucket on a
> subset of best practices
> https://github.com/hickford/git-credential-oauth/issues/17 . This
> identified multiple issues. For example, of those three servers, only
> GitLab supports PKCE
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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-kasselman-cross-device-security/ 
> 
> 
> This is to start a call for adoption for this document. 
> Please, provide your feedback on the mailing list on whether you support the 
> adoption of this document as a WG or not, by Nov 29th.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 try the current tests please drop me an 
email off list and I can provide some guidance.

Thanks

Joseph


> On 15 Nov 2022, at 00:42, Dmitry Telegin 
>  wrote:
> 
> - DPoP and Step-Up (hello Brian :)
> 
> TL;DR: can we use DPoP and Step-Up together?
> 
> The question is probably more about understanding of the process rather than 
> technical details. If I understand correctly, Step-Up is meant to 
> amend/extend RFC 6750. Can we say that the features defined in Step-Up 
> automatically become available for the specs that build on top of 6750, e.g. 
> DPoP? In other words, would the following response be considered valid:
> 
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: DPoP algs="ES256 PS256", 
> error="insufficient_user_authentication",
>   error_description="A different authentication level is required",
>   acr_values="myACR"
> 
> - DPoP conformance
> Is there any "official" conformance suite that could be used to test an AS/RS 
> for DPoP conformance? would that be the OIDC Conformance Suite (its FAPI2 
> part)?
> 
> Thanks,
> Dmitry
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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-device and 
same-device, can’t I save myself effort by only implementing CIBA and not 
bothering with standard redirect-based OAuth flows?” are commonly asked.

Also, in this text:

"If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel 
Authentication (CIBA) provides an alternative, provided that the underlying 
devices can receive push notifications.”

It might be best to use a term other than ‘push notifications’ there or 
otherwise rewording this, as there are alternatives. e.g. I think there’s at 
least one CIBA implementation out there that can use email to notify the user 
of an authorization request.

Thanks

Joseph

> On 19 Oct 2022, at 15:55, Pieter Kasselman 
>  wrote:
> 
> Hi All
> 
> Following on from the discussions at IETF 113, the OAuth Security Workshop, 
> Identiverse and IETF 114, Daniel, Filip and I created a draft document 
> capturing some of the attacks that we are seeing on cross device flows, 
> including Device Authorization Grant (aka Device Code Flow). 
> 
> These attacks exploit the unauthenticated channel between devices to trick 
> users into granting authorization by using social engineering techniques to 
> change the context in which authorization is requested. 
> 
> The purpose of the document is to serve as guidance on best practices when 
> designing and implementing scenarios that require cross device flows. We 
> would appreciate any feedback or comments on the document, or any other 
> mitigations or techniques that can be used to mitigate these attacks. Links 
> to the documents are below. We also hope to discuss this at IETF 115 in 
> London in a few weeks' time.
> 
> -
> A new version of I-D, draft-kasselman-cross-device-security-00.txt
> has been successfully submitted by Pieter Kasselman and posted to the IETF 
> repository.
> 
> Name: draft-kasselman-cross-device-security
> Revision: 00
> Title:Cross Device Flows: Security Best Current Practice
> Document date:2022-10-19
> Group:Individual Submission
> Pages:25
> URL: 
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt
> Status: 
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt 
> Html:   
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kasselman-cross-device-security
> 
> 
> Abstract:
>   This document describes threats against cross-device flows along with
>   near term mitigations, protocol selection guidance and the analytical
>   tools needed to evaluate the effectiveness of these mitigations.  It
>   serves as a security guide to system designers, architects, product
>   managers, security specialists, fraud analysts and engineers
>   implementing cross-device flows.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 RECOMMENDED.”

Feedback from some vendors (on the FAPI WG) seemed to be that they default to 
shorter lifetimes these days.

Shorter lifetimes seem like they can prevent various attacks, particularly if 
the AS isn't enforcing single-use of authorization code.


(I raised this at 
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/50 
 too, 
but forgot to email this list at the time)

Thanks

Joseph


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - Impementations

[Joseph Heenan]

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 write-up for the DPoP document, we are looking for 
> information about implementations of this draft.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 
> 
> 
> Please, reply to this email on the mailing list with any implementations that 
> you are aware of to support this document.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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.org/doc/draft-fett-oauth-selective-disclosure-jwt/>
> 
> Please, provide your feedback on the mailing list by August 12th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 handling sane are two excellent reasons to use a server 
> nonce. If an implementation has a good reason to not use a server nonce, we 
> can give guidance about what additional steps the implementation needs to 
> take. 

I think this is a good question, and I’ve been wondering about it myself.

The argument I see for not more strongly requiring nonces is that it pushes 
additional and non-trivial implementation complexity onto clients (and arguably 
also onto resource servers).

There are situations where I am not sure a nonce adds much value - for example 
in the case of a confidential client, an attacker with access to pre-generate 
DPoP proofs can likely also pre-generate private_key_jwt client authentication 
assertions and likely also has access to any refresh token. I believe this 
would allow them to obtain access tokens bound to a DPoP key of their choosing, 
and a nonce then seems to provide no additional protection.

(There are also cases where the nonce clearly does add a lot of value, 
particularly when considering public clients, and there may well be an argument 
for a ’should’ in those cases. Conversely I think there’s a potential argument 
for saying you should not use nonces in the confidential client situation I 
outlined, as it adds little other than complexity.)

Thanks

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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” 
implementation of OAuth2 and rarely if ever mention any libraries. (So a 
chicken and egg problem, because as you note there are languages without 
obvious good libraries to point people at.)

There’s even a set of documentation I’ve seen that links to an online PKCE 
generator and appears to imply that the developer should just generate the 
values once and hardcode them into every request…

I agree that pushing AS metadata will help matters. One of the downsides of 
maintaining OAuth2 libraries is dealing with constant “bug” reports when the 
library appears to a naive developer not to work correctly with a particular 
provider.

I’ve found https://jwt.io/libraries  a very useful 
reference for JWT libraries; anything of a similar nature for OAuth libraries 
sounds good to me.

Joseph



> On 1 Mar 2022, at 17:18, Daniel Fett  wrote:
> 
>  Hi all,
> 
> While helping clients to onboard into the yes ecosystem, in my consulting 
> work, and in discussions with developers implementing OAuth 2.0, one topic 
> comes up increasingly often: The (somewhat frustrating) lack of good, modern, 
> and universal OAuth libraries. 
> 
> Many of the libraries out there have one or more of the following drawbacks:
> 
>  * They are not maintained any longer
>  * They are not well documented (e.g., it is often unclear which 
> specifications are supported)
>  * They support only a subset of the OAuth 2.0 specification
>  * They work only with selected providers (e.g., Google, Facebook, etc.)
>  * It is unclear whether they follow recent security recommendations
>  * They do not support modern features, such as PKCE, AS Metadata, MTLS, etc.
> 
> Exceptions exist, of course, like Filip's Node.js implementation and the 
> nimbus library for Java. But apart from those rare cases, when a developer 
> asks me what library to use, my answer is often: "I don't think there's a 
> good one in your language". It is a telltale sign that many providers of 
> OAuth protected APIs also provide a custom OAuth implementation in their 
> SDKs, which they then often have to maintain for a number of languages. This 
> creates unnecessary costs and friction, e.g., when introducing new security 
> features.
> 
> At the same time, practically every language/framework comes with a TLS stack 
> and making HTTPS requests is often just a few lines of code. Why aren't we 
> there yet with OAuth? I'm well aware that OAuth 2.0 is a framework, not a 
> single protocol like TLS, but the mentioned libraries show that this does not 
> preclude a comprehensive library support.
> 
> If I had to speculate about the reasons for this mess, I'd say that there are 
> three:
> 
>  * The core of OAuth is easy to implement. The need to create or use a 
> library might not be obvious to developers. Of course, if you want a proper 
> implementation with correct error handling, observing all the security 
> recommendations, etc., the effort is huge. But just getting OAuth to work for 
> one specific use case is relatively easy.
> 
>  * OAuth is traditionally hard to configure: authorization and token endpoint 
> URLs, client id and secret, supported scopes (and claims for OIDC), supported 
> response types and modes, and required security features are just some of the 
> things a developer has to figure out - often from the API's documentation - 
> to get everything up and running. Even though configuration is not the same 
> as implementation, I imagine that this complexity can lead to the perception 
> that there are barely any commonalities between different OAuth flows. There 
> might be no value, after all, in an OAuth library, if I have to provide so 
> many details myself.
> 
>  * With many extensions and specifications to choose from, it can be hard to 
> select a reasonable subset to support. 
> 
> What can we do about this?
> 
> I'm not sure, but I have a few ideas.
> 
>  * Of course, one step would be to increase visibility and documentation for 
> existing implementations: Beyond listing libraries (like the list on 
> oauth.net), it would be great to have a place to go to to find libraries 
> based on their feature support. I'm sure there are more good libraries out 
> there.
>  * The OpenID Foundation has a great set of conformance tests for OIDC, FAPI 
> and other stuff. Creating conformance tests for OAuth would be harder, given 
> that the framework leaves many options for implementers to choose from. I’m 
> not sure if running a conformance programme would be in the scope of IETF, 
> but it can be worthwhile to think about if we could support such an endeavor.
>  * The single most important thing to do would, in my opinion, be to set a 
> goa

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

[Joseph Heenan]

Thanks George :) That’s a shame, I would have liked to listen to the recording.

My email below was thinking of the OSW interactive sessions (we had about 2 
hours of technical discussion on some of the issues with implementing app2app 
in practice particularly on Android), but now I’ve looked I think perhaps the 
recordings of those weren’t published. I have been working on a blog post with 
others that delves more into the Android side of things, hopefully we will 
publish that in the not too distant future.

I did an identiverse session too, which although it starts out quite similar 
diverges after about 10 minutes, delving less into the detail of security and 
covering more of the higher level what/why/how: 
https://identiverse.gallery.video/detail/video/6186099813001/

Joseph

> On 3 Nov 2020, at 22:12, George Fletcher  wrote:
> 
> I sent in some notes but I don't have a link for the recording. I don't 
> believe the recordings were being kept much past the end of the conference. 
> I'm pretty sure I heard that the recordings would be removed after N days (I 
> don't remember what N was stated as:)
> 
> Joseph explanation is better 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 have a link?
>> 
>> ᐧ
>> 
>> On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  
>> <mailto:jos...@authlete.com> wrote:
>> 
>>> 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 also
>>> aren’t consistently supported across all commonly used android browsers
>>> which causes further problems.
>>> 
>>> In general to do app2app oauth redirections securely on Android it’s
>>> necessary for both apps to fetch the /.well-known/assetlinks.json for the
>>> url they want to redirect to, and verify that the intent the app intends to
>>> launch to handle the url is signed using the expected certificate. Web2app
>>> flows are trickier, on both iOS and on Android. There were lengthy
>>> discussions on at least the Android case at OAuth Security Workshop this
>>> year (recordings available).
>>> 
>>> Joseph
>>> 
>>> 
>>> On 20 Oct 2020, at 00:09, Dick Hardt  
>>> <mailto:dick.ha...@gmail.com> wrote:
>>> 
>>> Hey Vittorio
>>> 
>>> (cc'ing OAuth list as this was brought up in the office hours today)
>>> 
>>> https://developer.android.com/training/app-links 
>>> <https://developer.android.com/training/app-links>
>>> 
>>> An app is the default handler and the developer has verified ownership of
>>> the HTTPS URL. While a user can override the app being the default handler
>>> in the system settings -- I don't see how a malicious app can be the
>>> default setting.
>>> 
>>> What am I missing?
>>> 
>>> /Dick
>>> ᐧ
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 also aren’t 
consistently supported across all commonly used android browsers which causes 
further problems.

In general to do app2app oauth redirections securely on Android it’s necessary 
for both apps to fetch the /.well-known/assetlinks.json for the url they want 
to redirect to, and verify that the intent the app intends to launch to handle 
the url is signed using the expected certificate. Web2app flows are trickier, 
on both iOS and on Android. There were lengthy discussions on at least the 
Android case at OAuth Security Workshop this year (recordings available).

Joseph


> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
> 
> Hey Vittorio
> 
> (cc'ing OAuth list as this was brought up in the office hours today)
> 
> https://developer.android.com/training/app-links 
> 
> 
> An app is the default handler and the developer has verified ownership of the 
> HTTPS URL. While a user can override the app being the default handler in the 
> system settings -- I don't see how a malicious app can be the default setting.
> 
> What am I missing?
> 
> /Dick
> ᐧ
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 the lines of:

Although integrity protection is not necessary to prevent mixup, any 
authorization response method that includes a JWT with an ‘iss' (for example, 
JARM or OIDC hybrid flow) will prevent the attack (assuming the client is 
validating the iss).


I’m not entirely sure I understand what "MUST NOT allow multiple authorization 
servers to return the same issuer identifier during registration” means as I 
don’t think https://tools.ietf.org/html/rfc7591 returns the issuer?

It might be clearer to say something like “When 
https://tools.ietf.org/html/rfc8414 is used the client MUST implement the 
validation described in https://tools.ietf.org/html/rfc8414#section-3.3. When 
authorization server details can be manually configured in the client, the 
client must verify that all issuer values are unique.” (Or at least something 
along those lines, I’m sure my wording can be improved. But if the client is 
correctly implementing rfc8414 or OIDC discovery [and does not have any 
manually configured authorization servers] then there’s no requirement for any 
further checks that the issuer is unique.)

Joseph


> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov  wrote:
> 
> This can potentially occur. If JARM is used "iss" becomes redundant. To me 
> JARM is an "enhanced" iss.
> 
> If both are included a sensible client should make sure the iss and the JARM 
> iss match.
> 
> My suggestion is to not require iss when a JARM is present, but in case both 
> do occur to have the client check both.
> 
> Vladimir
> 
> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>> Hi Karsten,
>> 
>> The specification mentions JARM. Does this specification require the iss 
>> response parameter even when JARM is used? That is, should an authorization 
>> response look like below?
>> 
>> HTTP/1.1 302 Found
>> Location: https://client.example.com/cb?response={JWT}&iss={ISSUER} 
>> 
>> 
>> Or, can the iss response parameter be omitted when JARM is used?
>> 
>> A small feedback for the 3rd paragraph in Section 4: s/identifes/identifies/
>> 
>> Best Regards,
>> Taka
>>  
>> 
>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov > > wrote:
>> Thanks Karsten, looks good to me now, no further comments.
>> 
>> Vladimir
>> 
>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>> Hi all,
>>> 
>>> Daniel and I published a new version of the "iss" response parameter draft 
>>> to address the feedback from the WG.
>>> 
>>> Changes in -01:
>>> 
>>> Incorporated first WG feedback
>>> Clarifications for use with OIDC
>>> Added note that clients supporting just one AS are not vulnerable
>>> Renamed metadata parameter
>>> Various editorial changes
>>> 
>>> We would like to ask you for further feedback and comments on the new draft 
>>> version.
>>> 
>>> Best regards,
>>> Karsten
>>> 
>>>  Forwarded Message 
>>> Subject:New Version Notification for 
>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> Date:   Sun, 01 Nov 2020 23:31:42 -0800
>>> From:   internet-dra...@ietf.org 
>>> To: Karsten Meyer zu Selhausen  
>>> , Karsten zu Selhausen 
>>>  
>>> , Daniel Fett 
>>>  
>>> 
>>> 
>>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> has been successfully submitted by Karsten Meyer zu Selhausen and posted to 
>>> the
>>> IETF repository.
>>> 
>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>> Revision: 01
>>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization 
>>> Response
>>> Document date: 2020-11-01
>>> Group: Individual Submission
>>> Pages: 10
>>> URL: 
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>  
>>> 
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>>>  
>>> 
>>> Html: 
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>>>  
>>> 
>>> Htmlized: 
>>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 
>>> 
>>> Diff: 
>>> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>  
>>> 

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

[Joseph Heenan]

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 an OIDC server would process, but one compliant with JAR 
[or FAPI-RW] would ignore the value outside). I don’t see having one more case 
of this as an issue - some servers will not be JAR compliant, and hence would 
fail tests that test JAR-specific behaviour.

I also agree with Brian about requiring AS to reject request objects that have 
a sub that’s a client_id, this doesn’t seem to cause significant 
interoperability concerns as it is hopefully unlikely that any client is doing 
so. I could possibly see an argument for weakening the requirement for an AS to 
reject a request object with sub=client_id to a ’should’ (rather than a must) 
given there is a small chance it could end up breaking an ecosystem, but I’m 
not entirely convinced.

Joseph


> On 17 Aug 2020, at 23:55, Brian Campbell 
>  wrote:
> 
> I might suggest that thinking about it in the context of interoperability 
> would be more meaningful than certification tests. 
> 
> Saying that an AS MUST reject the Request object if it has a typ header and 
> the value of the header is not ‘oauth.authz.req+jwt’ [1] should allow for 
> interoperability with respect to JWT typing between all combinations of 
> existing and updated clients with existing and updated authorization servers. 
> 
> Saying that an AS MUST NOT include a sub with client id as the value would 
> break for an updated authorization server when receiving such a request 
> object JWT. But that's erroneous and potentially dangerous behaviour from the 
> client so I don't know that we need to try and maintain interoperability 
> there. 
> 
> [1] Unfortunately "typ":"JWT" would probably also need to be allowed. As best 
> I understand it "typ":"JWT" basically says "this JWT is a JWT", which isn't 
> useful for explicit typing and I think makes it effectively equivalent to an 
> untyped JWT. I've honestly never understood why one would use "typ":"JWT" but 
> it shows up in a lot of places including examples and explanations on sites 
> like jwt.io  so it seems very likely that it'd just get 
> copied over and show up in some amount of real world request object JWTs. 
> 
> 
> On Sat, Aug 15, 2020 at 10:41 AM Mike Jones 
>  > wrote:
> Answering Filip and Vladirmir’s question about adding normative language 
> around “typ” and “sub”:  Anytime you add a new required feature, you are 
> breaking existing deployments.  Suppose we added the normative requirement 
> “If a ‘typ’ header parameter is present, ASs MUST reject the Request object 
> if its value is not ‘oauth.authz.req+jwt’”.  One could then write a 
> certification test sending the AS a different “typ” value – which to pass, 
> ASs would have to reject the JWT.  Every existing deployment would fail this 
> test!  That’s exactly what we don’t want to have happen.
> 
>  
> 
> Brian asked for security considerations.  The IESG asked for security 
> considerations.  I added them in the PR – working with Nat and John.  They 
> point the way to the future without breaking existing deployments.  That’s as 
> it should be.
> 
>  
> 
>-- Mike
> 
>  
> 
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Warren Parad
> Sent: Saturday, August 15, 2020 9:27 AM
> To: Vladimir Dzhuvinov  >
> Cc: oauth mailto:oauth@ietf.org>>
> Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on 
> draft-ietf-oauth-jwsreq-26: (with COMMENT)
> 
>  
> 
> In the case of
> 
> if the Request Object includes a sub claim with the value of the client_id 
> the AS MUST reject the request
> 
>  
> 
> What would the expectation be in terms of a client_credentials grant?
> 
>  
> 
> From experience, the sub is frequently populated with the client_id value and 
> the client_id is not used. Which would mean breaking for that type of grant 
> wouldn't it?
> 
>  
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement 
> Authress .
> 
>  
> 
>  
> 
> On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov  > wrote:
> 
> +1 to make the "typ" check, as Filip suggested, normative, as existing client 
> and RP deployments with undefined "typ" will not be affected. New deployments 
> should be encouraged to type the JWT, and thus be made safer.
> 
>  
> 
> Regarding the "sub != client_id" check -- could a simple rejection of all 
> JWTs with "sub" present suffice?
> 
> I find it difficult to imagine what else a client could end up setting the 
> "sub" claim to, if it does end up populating it for some reason.
> 
>

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

[Joseph Heenan]

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/oauthstuff/draft-oauth-par/issues/59 
 - possible ambiguity 
in the text around error responses from new endpoint

https://github.com/oauthstuff/draft-oauth-par/issues/62 
 & 
https://github.com/oauthstuff/draft-oauth-par/issues/63 
 - minor typographical 
points


For info, Authlete has at least one deployed implementation of this spec.

Authlete has also assisted in getting tests for PAR added to the Open ID 
Foundation FAPI Certification test suite for Authorization Servers, and 
(although there’s still a few niggles in the tests to work out) the tests seem 
to interoperate with Authlete, Filip’s node-oidc-provider and a Ping 
implementation fine. (Many thanks to Filip & Ping for testing them! If anyone 
else would like to try them please let me know.)

Thanks

Joseph

> 
> On 11 Aug 2020, at 23:07, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is a WGLC on the Pushed Authorization Requests document:
> https://www.ietf.org/id/draft-ietf-oauth-par-03.html 
> 
> 
> Please, take a look and provide feedback on the list by August 25th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 ecosystem) venture in there.

There’s really no strong reason to use/allow full Unicode for items that are 
only exposed to developers, and there are significant reasons for applying the 
KISS principle - it makes life easy for AS, for clients, and closes an entire 
possible attack vector.

Joseph


> On 21 Jul 2020, at 19:05, Justin Richer  wrote:
> 
> I’m suggesting that API designers avoid using such glyphs in their “type” 
> values if they want to avoid such human-copy errors, like they would need to 
> do for most other strings in their system. If that means they stick to ASCII 
> or put a note on the developer page that says “hey copy and paste this value, 
> don’t try to re-type it” or whatever, that’s up to the AS. 
> 
> You’d have the same kind of issue around “similar-looking” characters, like 
> the semicolon vs. the greek question mark. Should the AS look for those and 
> try to “fix” the inputs? I would argue not: the AS should be strict in 
> matching these values because it could have security implications. 
> 
> This isn’t a problem unique to RAR, or OAuth for that matter. We can, and I 
> think should, add guidance to the RAR document for all of these points. 
> 
>  — Justin
> 
>> On Jul 21, 2020, at 1:55 PM, Dick Hardt > > wrote:
>> 
>> In unicode, a glyph can be represented by more than one code point. When 
>> reading the docs and entering a value, the developer will not know which 
>> code point the AS intended. 
>> 
>> Are you suggesting that AS documentation would have the bytes rather than 
>> glyphs? Or not use glyphs that have multiple code points? Or that they only 
>> use english?
>> 
>> 
>> 
>> On Tue, Jul 21, 2020 at 10:34 AM Justin Richer > > wrote:
>> Right, and I’m saying that all three of those would be DIFFERENT “type” 
>> values, because they’re different strings. The fact that when treated as 
>> URIs they would be equivalent is irrelevant. Just like “foo”, “Foo”, and 
>> “FOO” would be different “type” values, per the spec. Nothing is stopping an 
>> AS from treating them as equivalent internally, but that seems a bit 
>> dangerous to me. I’d love to see a formal breakdown of that, though.
>> 
>> As for the unicode example, if we define things as using byte comparisons, 
>> then that becomes an issue for proper documentation and configuration — and 
>> again, probably a good place to have recommendations for picking type value 
>> strings so as to avoid such problems.
>> 
>> In short, I don’t think we should have any requirements on canonicalization 
>> for these values.
>> 
>>  — Justin
>> 
>>> On Jul 21, 2020, at 1:03 PM, Dick Hardt >> > wrote:
>>> 
>>> 
>>> The following are the same URI, but are different strings:
>>> 
>>> “https://schema.example.org/v1 ”
>>> “HTTPS://schema.example.org/v1 ”
>>> “https://SCHEMA.EXAMPLE.ORG/v1 ”
>>> 
>>> Before comparing them to each other, they must be canonicalized so that 
>>> they become the same string.
>>> 
>>> From earlier in this thread, I am NOT suggesting that it must be a URI, nor 
>>> that it is required:
>>> 
>>> Since the type represents a much more complex object then a JWT claim, a 
>>> client developer's tooling could pull down the JSON Schema (or some such) 
>>> for a type used in their source code, and provide autocompletion and 
>>> validation which would improve productivity and reduce errors. An AS that 
>>> is using a defined type could use the schema for input validation. Neither 
>>> of these would be at run time. JSON Schema allows comments and examples.
>>> 
>>> What is the harm in non-normative language around a retrievable URI?
>>> 
>>> On Tue, Jul 21, 2020 at 9:58 AM Justin Richer >> > wrote:
>>> String comparison works just fine when the strings happen to be URIs, and 
>>> you aren’t treating them as URIs:
>>> 
>>> “https://schema.example.org/v1 ”
>>> 
>>> Is different from 
>>> 
>>> “https://schema.example.org/v2 ”
>>> 
>>> And both are different from
>>> 
>>> “https://schema.example.org:443/v1 /“
>>> 
>>> All of these are strings, and the strings happen to be URIs but that’s 
>>> irrelevant to the comparison process. Can you please help me understand why 
>>> doing a string comparison on these values does not work in exactly the same 
>>> way it would for “foo”, “bar”, and “baz” values? Why would these need to be 
>>> canonicalized to be compared? The definition of a JSON string is an ordered 
>>> set of 

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

[Joseph Heenan]

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: the mobile app to be used is selected purely based 
on the host/path segment.

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 
> AS to specify multiple authorization_endpoints?
> Confusing End User! A user is using the same credentials on a yellow styled 
> "https://loadsamoney/business/auth " and a 
> green styled "https://loadsamoney/consumer/auth 
> ". A well designed environment will have a 
> centralized page for login and account management like 
> "https://loadsamoney/accounts/auth " even 
> better "https://accounts.loadsamoney/auth 
> ".

In the cases Dave and I are thinking of, there’s no SSO between the different 
brands (sorry,I’m struggling to find a better word than brands!), which also 
have segmented user credentials - there’s no user confusion.

> 
> I can see that to avoid user confusion it would be necessary for the Client 
> to record which endpoint they redirected the user to, in case they need the 
> user to re-authorize - but I can't see any particular security issue?
> Let assume the "Client-Business" will record the business auth-endpoint and 
> keep sending RO to "https://loadsamoney/business/auth 
> " for reauthentication. If the user opens 
> his personal banking application on another tab, "Client-Consumer" will send 
> the user to "https://loadsamoney/consumer/auth 
> ". For SSO to work, the AS has to store 
> the SSO-Cookies under "https://loadsamoney/ 
> ". Now your AS SSO Cookies are also 
> accessible to "https://loadsamoney/blog "! 
> This problem is even worse if instead of path you use subdomains like 
> "https://business.loadsamoney/auth " and 
> "https://consumer.loadsamoney/auth " the 
> the SSO Cookie of your AS has to be set to: ".loadsamoney", providing access 
> to the SSO Cookies to all other subdomain hosted application like 
> "https://blog.loadsamoney/ ".
> Most AS I have used in customer projects use cookies to manage SSO?

I think this is either mainly an issue with the example urls, or solved by 
pointing out that you should not do SSO between different authorization 
endpoints for the reasons you say?

>  
> 
> No matter which authorization_endpoint the user was sent to, after the user 
> is redirected back to the Client's redirect_uri the process is the same as if 
> there had been 1 authorization_endpoint. 
> AS UI customization is being done today by many AS deployment because of:
> - Multitenancy of deployment
> - The need to have client identity disclosed to the RO in a consent page

> 
> I am in favour of Vladimir's suggestion of:
> 
> "alternative_authorization_endpoints": {
> "banking": {
>   "authorization_endpoint": "https://loadsamoney/business/auth 
> ",
>   "description": "loadsmoney business banking customers",
>   "logo_url": "https://loadsamoney/business/logo.png 
> "
> },
> "personal": {
>   "authorization_endpoint": "https://loadsamoney/consumer/auth 
> ",
>   "description": "loadsmoney personal customers",
>   "logo_url": "https://loadsamoney/consumer/logo.png 
> "
> }
>   }
> This use case is neither multi tenancy nor the disclosure of the client 
> identity in a consent page. Starting with the logo here, we will end up 
> adding css and js code snippets. This type of customizing shall be done in 
> the AS-Deployment without playing around with the public AS metadata. 

I don’t understand why “disclosure of the client identity in a consent page” is 
relevant here; that already happens, it will continue to happen in the same way 
and isn’t affected in any way by this suggestion.

Yes, there are other architectures that don’t require this. I don’t think it is 
the job of the protocol to disallow or make some architectures difficult just 
because other architectures are better.

I don’t think it’s even clear that having a client deal with 16 different 
issuers for a single bank (a real world example of what would happen if we 
forced ‘one authorization endpoint per issuer’) is actually “better”. It’s a 
pain for the client to manage 16 different issuers rather than 1 with 16 
authorization endpoints - it means 16 client registrations and 16 issuers to 
configure, and it obfuscates to the client that these are actually all the same 
system. I have a hard time saying that one architecture is clearly good and 
that

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

[Joseph Heenan]

I just realised that “client chooser” in the below is a very ambiguous term.

Please read it to mean “a chooser presented by the client”.. (And in the UK 
today, that chooser is manually populated by the client developer based on the 
central directory.)

Joseph

> On 22 May 2020, at 09:32, Joseph Heenan  wrote:
> 
> Thanks Vladimir/Torsten.
> 
> I agree, it would make sense to have some form of static id for each entry. 
> My first attempt started out similar but for some reason I decided to 
> simplify…
> 
> On the conceptual side for choosers (and biased towards how the UK 
> openbanking ecosystem works as that’s what I know best), what this allows for 
> is:
> 
> client chooser -> authorisation endpoint
> 
> Where the list is:
> 
> “Bank a”
> “Loadsamoney personal”
> “Loadsamoney business”
> “Bank c"
> 
> 
> Instead of the only ’standards compliant’ way to do app2app in this case 
> today of:
> 
> client chooser -> AS interstitial chooser on authorization endpoint -> real 
> authorization endpoint
> 
> Where the first chooser is:
> 
> “Bank a”
> “Loadsamoney”
> “Bank c”
> 
> And the second:
> 
> “Personal"
> “Business"
> 
> The first case is much better, particularly for the real multi-brand case 
> where the end user might not even associate the two bank brandnames with each 
> other.
> 
> What actually happens today is the first case (single RP chooser), but based 
> on banks emailing around lists of alternative authorization endpoints to the 
> RP, or publishing the details on obscure developer portals - which destroys 
> much of the convenience / agility / security the server metadata RFC was 
> trying achieve.
> 
> The issue of how the RP finds the server metadata document is unchanged from 
> today. (In the UK, we have a centralised directory that lists them.)
> 
> Joseph
> 
> 
> 
>> On 22 May 2020, at 08:52, Vladimir Dzhuvinov > <mailto:vladi...@connect2id.com>> wrote:
>> 
>> With that said it makes sense to devise a structure which can accommodate UI 
>> driven as well as automatic choice.
>> 
>> The UI driven chooser will need a human readable description and other UI 
>> hints. This can work for instance with "classic" OIDC Discovery.
>> 
>> The "auto" chooser will need some sort of an ID. For a bank chooser this 
>> means providing the issuer URI and an optional brand ID and both must get 
>> registered together. Or, one could define a standard brand ID (label) for 
>> banking operations and if the "alternative_authorization_endpoints" is 
>> present look for it in the structure, else fall back to the default 
>> "authorization_endpoint".
>> Here is one possible layout which has IDs and UI hints:
>> 
>> {
>>   ...
>>   "alternative_authorization_endpoints": {
>> "banking": {
>>   "authorization_endpoint": "https://loadsamoney/business/auth"; 
>> <https://loadsamoney/business/auth>,
>>   "description": "loadsmoney business banking customers",
>>   "logo_url": "https://loadsamoney/business/logo.png"; 
>> <https://loadsamoney/business/logo.png>
>> },
>> "personal": {
>>   "authorization_endpoint": "https://loadsamoney/consumer/auth"; 
>> <https://loadsamoney/consumer/auth>,
>>   "description": "loadsmoney personal customers",
>>   "logo_url": "https://loadsamoney/consumer/logo.png"; 
>> <https://loadsamoney/consumer/logo.png>
>> }
>>   }
>> }
>> 
>> 
>> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>>> I think an id or label per endpoint set would be needed to determine the 
>>> set of endpoints to be used by a certain client.
>>> 
>>> On the conceptual side, I’m asking myself how the complete process is 
>>> supposed to work. Who is deciding what issuer/endpoint set combination to 
>>> use. I assume in an open banking scenario, there will always be some kind 
>>> 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 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 brande

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

[Joseph Heenan]

Thanks Vladimir/Torsten.

I agree, it would make sense to have some form of static id for each entry. My 
first attempt started out similar but for some reason I decided to simplify…

On the conceptual side for choosers (and biased towards how the UK openbanking 
ecosystem works as that’s what I know best), what this allows for is:

client chooser -> authorisation endpoint

Where the list is:

“Bank a”
“Loadsamoney personal”
“Loadsamoney business”
“Bank c"


Instead of the only ’standards compliant’ way to do app2app in this case today 
of:

client chooser -> AS interstitial chooser on authorization endpoint -> real 
authorization endpoint

Where the first chooser is:

“Bank a”
“Loadsamoney”
“Bank c”

And the second:

“Personal"
“Business"

The first case is much better, particularly for the real multi-brand case where 
the end user might not even associate the two bank brandnames with each other.

What actually happens today is the first case (single RP chooser), but based on 
banks emailing around lists of alternative authorization endpoints to the RP, 
or publishing the details on obscure developer portals - which destroys much of 
the convenience / agility / security the server metadata RFC was trying achieve.

The issue of how the RP finds the server metadata document is unchanged from 
today. (In the UK, we have a centralised directory that lists them.)

Joseph



> On 22 May 2020, at 08:52, Vladimir Dzhuvinov  wrote:
> 
> With that said it makes sense to devise a structure which can accommodate UI 
> driven as well as automatic choice.
> 
> The UI driven chooser will need a human readable description and other UI 
> hints. This can work for instance with "classic" OIDC Discovery.
> 
> The "auto" chooser will need some sort of an ID. For a bank chooser this 
> means providing the issuer URI and an optional brand ID and both must get 
> registered together. Or, one could define a standard brand ID (label) for 
> banking operations and if the "alternative_authorization_endpoints" is 
> present look for it in the structure, else fall back to the default 
> "authorization_endpoint".
> Here is one possible layout which has IDs and UI hints:
> 
> {
>   ...
>   "alternative_authorization_endpoints": {
> "banking": {
>   "authorization_endpoint": "https://loadsamoney/business/auth"; 
> <https://loadsamoney/business/auth>,
>   "description": "loadsmoney business banking customers",
>   "logo_url": "https://loadsamoney/business/logo.png"; 
> <https://loadsamoney/business/logo.png>
> },
> "personal": {
>   "authorization_endpoint": "https://loadsamoney/consumer/auth"; 
> <https://loadsamoney/consumer/auth>,
>   "description": "loadsmoney personal customers",
>   "logo_url": "https://loadsamoney/consumer/logo.png"; 
> <https://loadsamoney/consumer/logo.png>
> }
>   }
> }
> 
> 
> On 22/05/2020 09:59, Torsten Lodderstedt wrote:
>> I think an id or label per endpoint set would be needed to determine the set 
>> of endpoints to be used by a certain client.
>> 
>> On the conceptual side, I’m asking myself how the complete process is 
>> supposed to work. Who is deciding what issuer/endpoint set combination to 
>> use. I assume in an open banking scenario, there will always be some kind 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 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 also allow inclusion of the op_policy_uri and op_tos_uri params 
>>> from Discovery.
>>> 
>>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery 
>>> <https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery>
>>> 
>>> Vladimir
>>> 
>>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>>> Thanks for your thoughts Vladimir!
>>>> 
>>>> The client_id based solution I wasn’t previously aware of - unfortunately 
>>>> it doesn’t solve the problem for app2app, as the mobile OS selects the app 
>>>> to use based purely on the URL (and in at least the iOS case will not 
>>>> offer 

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

[Joseph Heenan]

Thanks for your thoughts Vladimir!

The client_id based solution I wasn’t previously aware of - unfortunately it 
doesn’t solve the problem for app2app, as the mobile OS selects the app to use 
based purely on the URL (and in at least the iOS case will not offer the user a 
choice if multiple apps claim to handle the same url).

I think some kind of mapping like you suggest will work and fallback, I wonder 
about a structure in the authorization server metadata something like this:

{
  ...
  "alternative_authorization_endpoints": [
{
  "authorization_endpoint": "https://loadsamoney/business/auth";,
  "description": "loadsmoney business banking customers",
  "logo_url": "https://loadsamoney/business/logo.png";
},
{
  "authorization_endpoint": "https://loadsamoney/consumer/auth";,
  "description": "loadsmoney personal customers",
  "logo_url": "https://loadsamoney/consumer/logo.png";
}
  ]
}

And as you say, the existing authorization_endpoint can be a fallback for 
clients that are unaware of the new spec or prefer the simpler option of just 
using a single authorization endpoint. Supporting the new spec would allow a 
better UX though so there’s advantages to client to do so.
> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be 
> sensibly combined with the proposed multi-brand spec.
> 

I think that particular part is not really an issue as mtls isn’t used at the 
authorization endpoint.

Thanks

Joseph


> On 20 May 2020, at 16:07, Vladimir Dzhuvinov  wrote:
> 
> Hi Dave,
> 
> In the absence of such a "multi-brand" spec we have tackled this issue in the 
> past by letting the "brand" be encoded in the client_id. An alternative 
> scenario is to do a "brand" lookup by client_id. Then let the AS render the 
> "branded" authZ endpoint.
> 
> You're probably aware the mTLS spec is allowing for endpoint aliases, so this 
> is not the first time such as need has occurred:
> 
> https://tools.ietf.org/html/rfc8705#section-5 
> <https://tools.ietf.org/html/rfc8705#section-5>
> One could devise a similar JSON object with mappings "label" - 
> "authorization_endpoint".
> 
> Clients that are aware of the new spec will look it up, those that are not 
> will fall back to the std "authorization_endpoint".
> 
> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be 
> sensibly combined with the proposed multi-brand spec.
> 
> 
> 
> Vladimir
> 
> 
> 
> On 20/05/2020 15:07, Dave Tonge wrote:
>> Dear OAuth WG
>> 
>> We have an issue 
>> <https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>
>>  in the OpenID FAPI Working Group that we believe affects the wider OAuth 
>> community.
>> 
>> In summary: what is the recommended approach to discovery (RFC8414) for 
>> Authorization Servers who support multiple "brands" .
>> 
>> If brands are completely 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 document available at  
>> https://as/.well-known/ 
>> <https://as/.well-known/>oauth-authorization-server/brand1).
>> 
>> However in the real world it is not always so simple. We have many existing 
>> implementations in UK open banking that support multiple authorization 
>> endpoints. Here is an example (thanks to @Joseph Heenan 
>> <mailto:joseph.hee...@fintechlabs.io> )
>> 
>> > Bank “loadsamoney” has one idp and, for internet banking, one “login page” 
>> > for both business and personal customers.
>> 
>> > They have separate mobile apps for business/personal, and are required to 
>> > support app2app. This means they will definitely be exposing multiple 
>> > authorization endpoints (as there’s a 1:1 mapping of authorization 
>> > endpoints to mobile apps) - the choice is how they do this.
>> 
>> > Their choices are:
>> 
>> > 1. Multiple discovery endpoints (one for business, one for personal), each 
>> > with a different authorization endpoint, multiple issuers (if their vendor 
>> > allows this)
>> > 2. Single discovery endpoint, single issuer, multiple authorization 
>> > endpoints listed in one discovery doc (one for business, one for personal) 
>> > some of which are hardcoded by the 3

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

[Joseph Heenan]

I agree with that too.

Joseph

> On 12 Mar 2020, at 14:18, Mike Jones 
>  wrote:
> 
> I agree that we should restore the client_id functionality.  Thanks for 
> moving this forward!
>  
>-- Mike
>  
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Nat Sakimura
> Sent: Monday, February 24, 2020 6:18 PM
> To: John Bradley mailto:ve7...@ve7jtb.com>>
> Cc: oauth mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request 
> (JAR) vs OIDC request object
>  
> So, where should we take it to? 
> Just add back client_id as it used to be?
>  
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
>  
> -- Forwarded message -
> From: John Bradley mailto:ve7...@ve7jtb.com>>
> Date: Sat, Jan 18, 2020, 9:31 PM
> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request 
> (JAR) vs OIDC request object
> To: Benjamin Kaduk mailto:ka...@mit.edu>>
>  
> 
> If you put the iss in the JWE header it is integrity protected, as JWE only 
> supports AAD encryption algs.
>  
> It is more of a problem when the client is sending a requestURI in that case 
> having the clientID in the GET to the Authorization endpoint is useful.
>  
> I think there is a argument for explicitly allowing the clientID as long as 
> it exactly matches the clientID in the JAR.
>  
> John B.
>  
> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk  <mailto:ka...@mit.edu>> wrote:
> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> > I don’t agree with this stance from a security or implementation 
> > perspective. 
> > 
> > If there’s a clear order of precedence for the information, it’s not 
> > particularly problematic. Everything inside the request object is to be 
> > taken over things outside the request object. We have the exact same 
> > semantics and process with dynamic registration, where the software 
> > statement is carried alongside plain JSON claims, and the two are mixed 
> > with a very simple algorithm:
> > 
> >  - If a field is inside the signed payload, use that value and ignore any 
> > copy of it on the outside
> >  - If a field is not inside the signed payload and is outside the signed 
> > payload, use the outside value
> > 
> > Can someone please point out a concrete security issue with this algorithm? 
> > This is the extent of the “merge” semantics that we need here, and it would 
> > solve not only the ability to use this for use cases that call for a more 
> > static request object (perhaps signed by a third party and not the client) 
> > along side the plain parameters that can vary, but also the backwards 
> > compatibility issue that’s been discussed. With this algorithm in place, 
> > you could have OIDC clients actually be compliant with the spec, since OIDC 
> > requires replication of the values inside the request object on the outside 
> > with exact matches. An OIDC server wouldn’t be fully compliant with the new 
> > spec since it would reject some compliant JAR requests that are missing the 
> > external parameters, but that’s fairly easy logic to add on the OIDC side. 
> > And in that case you get a matrix of compatibility like:
> 
> I agree that the merge algorithm is simple and fairly straightforward to
> implement.  But, as Joseph has been alluding, it's only simple if you've
> already made the decision to use all the parameters, both from inside and
> from outside the signed payload.  The security risk lies about having to
> make the trust decision twice, more than the mundane details of actually
> doing the merge.  (Though there is still some latent risk, given that we've
> seen some really crazy quality of implementation out there.)
> 
> It's certainly *possible* that things end up fine in many well-deliniated
> cases where merging can be used.  But it's more complicated to reason
> about, and I don't remmber seeing much previous discussion about the
> specifics of the double trust decision.
> 
> -Ben
> 
> > 
> >   JAR Server | OIDC Server  |
> > ++--+
> > JAR Client  | YES|  NO  |
> > OIDC Client | YES| YES  |
> > 
> > Breaking 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 

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

[Joseph Heenan]

In my opinion it's still problematic if an attacker can inject claims that 
aren't in the request object.

A simple (albeit OIDC specific) example would injecting prompt=none or a 
login_hint, where the request object doesn't have a prompt/login_hint already. 
In that case if/when people design protocol extensions they have to consider in 
each case what will happen if a client doesn't specify it (and hence the 
attacker can inject it) rather than being sure that the values they get will 
always be genuinely sent by the client if the client is using JAR. (I’m not 
clear if injecting prompt/login_hint can actually be formed into a useful 
attack, but I’d don’t think that justifies leaving the whole vector open.)

If there’s really a case for having parameters outside the signed object, it 
feels like the signed object should explicitly list which unsigned parameters 
it allows to be used with it. That would mean existing OIDC clients aren’t 
compatible with JAR. I’m not sure the extra complexity is justified.

I think it’s also arguable that if using PAR the case for ignoring all 
parameters that are outside the request object is even stronger. We quickly 
give up some of the easy security gains of PAR if we allow it, and whilst I 
concede there may be some sensible use cases for pre-signed objects mixed with 
unsigned parameters (Justin mentioned one of combining a pre-signed request 
object containing scope/client_id/redirect_uri with unsigned 
nonce/state/code_challenge) I’m not sure there’s any reason to do this when 
using PAR.

Joseph


> On 18 Jan 2020, at 01:24, Richard Backman, Annabelle  
> wrote:
> 
> +1 to Justin’s comments. From a security standpoint parameters in the query  
> string are no different from those in JWT unprotected headers (or protected 
> if they’re also in the request object). Although I‘d amend Justin’s 
> suggestion to say that if a parameter is both inside the request object and 
> outside and they do not match, reject the request as suspicious.
> 
>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>> 
>>  I don’t agree with this stance from a security or implementation 
>> perspective. 
>> 
>> If there’s a clear order of precedence for the information, it’s not 
>> particularly problematic. Everything inside the request object is to be 
>> taken over things outside the request object. We have the exact same 
>> semantics and process with dynamic registration, where the software 
>> statement is carried alongside plain JSON claims, and the two are mixed with 
>> a very simple algorithm:
>> 
>>  - If a field is inside the signed payload, use that value and ignore any 
>> copy of it on the outside
>>  - If a field is not inside the signed payload and is outside the signed 
>> payload, use the outside value
>> 
>> Can someone please point out a concrete security issue with this algorithm? 
>> This is the extent of the “merge” semantics that we need here, and it would 
>> solve not only the ability to use this for use cases that call for a more 
>> static request object (perhaps signed by a third party and not the client) 
>> along side the plain parameters that can vary, but also the backwards 
>> compatibility issue that’s been discussed. With this algorithm in place, you 
>> could have OIDC clients actually be compliant with the spec, since OIDC 
>> requires replication of the values inside the request object on the outside 
>> with exact matches. An OIDC server wouldn’t be fully compliant with the new 
>> spec since it would reject some compliant JAR requests that are missing the 
>> external parameters, but that’s fairly easy logic to add on the OIDC side. 
>> And in that case you get a matrix of compatibility like:
>> 
>> 
>>   JAR Server | OIDC Server  |
>> ++--+
>> JAR Client  | YES|  NO  |
>> OIDC Client | YES| YES  |
>> 
>> Breaking 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 (neither of which 
>> are true in the case of PAR) makes me think we need to pull this back and 
>> rework those things, in a push back to the IESG’s comments.
>> 
>>  — Justin
>> 
>> 
>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan >> <mailto:jos...@authlete.com>> wrote:
>>> 
>>> I agree with this, particularly the security concerns of merging. If we 
>>> merge, we can much guarantee there will eventually be a

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

[Joseph Heenan]

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’t found 
inside the request object). Ruling out that case makes security analysis 
(particularly when creating new OAuth2 parameters) significantly simpler.

Putting the iss in the JWE header and having the client_id duplicated outside 
the request object seem to address all the concerns I’ve seen raised.

(It seems like it may be unnecessary to have the client_id duplicated outside 
if the request_uri is a PAR one though.)

Joseph



> On 16 Jan 2020, at 22:40, John Bradley  wrote:
> 
> I agree with the IESG reasoning that merging is problimatic.  Once we
> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.
> 
> Query paramaters can still be sent outside the JAR, but if they are in
> the OAuth registry the AS MUST ignore them.
> 
> Puting the iss in the JWE headder addresses the encryption issue without
> merging.
> 
> I understand that some existing servers have dependencys on getting the
> clientID as a query paramater.
> 
> Is that the only paramater that people have a issue with as oposed to a
> nice to have?
> 
> Would allowing the AS to not ignore the clientID as a query paramater as
> long as it matches the one inside the JAR, basicly the same as Connect
> request object but for just the one paramater make life easier for the
> servers?
> 
> I am not promising a change but gathering info before proposing something.
> 
> John B.
> 
> 
> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
 Well, embedding a client_id claim in the JWE header in order to
 achieve "request parameters outside the request object should not be
 referred to" is like "putting the cart before the horse". Why do we
 have to avoid using the traditional client_id request parameter so
 stubbornly?
 
 The last paragraph of Section 3.2.1
  of RFC 6749 says
 as follows.
 
/A client MAY use the "client_id" request parameter to identify
itself when sending requests to the token endpoint.  In the
"authorization_code" "grant_type" request to the token endpoint,
*an unauthenticated client MUST send its "client_id" to prevent
itself from inadvertently accepting a code intended for a client
with a different "client_id".*  This protects the client from
substitution of the authentication code.  (It provides no
additional security for the protected resource.)/
 
 
 If the same reasoning applies, a client_id must always be sent with
 request / request_uri because client authentication is not performed
 at the authorization endpoint. In other words, */an unauthenticated
 client (every client is unauthenticated at the authorization endpoint)
 MUST send its "client_id" to prevent itself from inadvertently
 accepting a request object for a client with a different "client_id"./*
 
>>> Identifying the client in JAR request_uri requests can be really useful
>>> so that an AS which requires request_uri registration to prevent DDoS
>>> attacks and other checks can do those without having to index all
>>> request_uris individually. I mentioned this before.
>>> 
>>> I really wonder what the reasoning of the IESG reviewers was to insist
>>> on no params outside the JAR JWT / request_uri.
>>> 
>>> I'm beginning to realise this step of the review process isn't
>>> particularly transparent to WG members.
>> Could you expand on that a bit more?  My understanding is that the IESG
>> ballot mail gets copied to the WG precisely so that there is transparency,
>> e.g., the thread starting at
>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>> Which admittely is from almost three years ago, but that's the earliest
>> that I found that could be seen as the source of this behavior.
>> 
>> -Ben
>> 
>> P.S. some other discussion at
>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
>> so on.
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

+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
> > 
> > On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov  > > wrote:
> > +1 for the adoption of RAR
> > 
> > On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
> >> This is a call for adoption for the OAuth 2.0 Rich Authorization Requests 
> >> document.
> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 
> >>  
> > ___
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth 
> > 
> > 
> > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> > material for the sole use of the intended recipient(s). Any review, use, 
> > distribution or disclosure by others is strictly prohibited..  If you have 
> > received this communication in error, please notify the sender immediately 
> > by e-mail and delete the message and any file attachments from your 
> > computer. Thank you.___
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth 
> > 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>  
> | stei...@udelt.no  | h...@udelt.no 
>   | +47 955 21 620 <> | www.udelt.no 
>  | 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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/ 
>  
> 
> There was a good support for this document during the Singapore meeting, and 
> on the mailing list in the Meeting Minutes thread.
> 
> Please, let us know if you support or object to adopting this document as a 
> working group document by Dec 27th.
> 
> If you have already indicated your support on the Meeting Minutes thread, you 
> do not need to do it again on this thread.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 8628

[Joseph Heenan]

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 [redirect_uri] field.

Exactly, and that same url should have been pre-registered with the 
authorization server.

>  
> By the way, most of the French banks will use Oauth2 AC and not OpenId 
> Connect. I guess that the sequence diagram is roughly the same, isn’t it?

Correct; pretty much exactly the same as I presume you’d still be using the 
authorization code flow.

The security concerns for app2app are very similar to basic OAuth2 / OpenID 
Connect, and to quickly sum those up for anyone reading this that's not 
familiar with those concerns: it’s very easy to do something that has 
undesirable security properties, and you should follow documents like FAPI-RW 
(an OpenID Connect based standard originally, but now JARM exists and has some 
vendor adoption OpenID Connect is not required) or the OAuth2 security BCP, to 
ensure your implementation is not vulnerable to the known attacks against 
OAuth2.

Cheers

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 8628

[Joseph Heenan]

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 two following 
>> flows for a mobile-based authentication
>> 
>> -  DECOUPLED : via a RFC8628-derived or CIBA approach (as suggested 
>> by Rob)
>> -  REDIRECT : via the flow specified in the OpenId link you gave.
>> 
>> The main issue encountered so far is to give back the focus on the third 
>> party app. Third Parties fear that their app will be kept in the back of the 
>> mobile screen.
> 
> @Joseph: what’s your take on this concern? 

In app2app, it really shouldn’t happen - if the device OS has not properly 
registered the universal link, the TPP website would open instead and 
authorization code can still be processed (though admittedly supporting this 
use case may require a bit more care to ensure session mixup attacks can’t 
happen).

> 
>> This could happen when the TPP app [app link]/[universal link] is not 
>> properly registered or forwarded to the bank app.
>> -  In the REDIRECT approach this means that the authorization code 
>> cannot be forwarded to the TPP

I don’t really understand how the ‘app link’ would not be properly registered 
to the bank app. The universal link should be the same URL as for the redirect 
uri on the TPP website. Obviously if the TPP registers their redirect uri 
incorrectly with the bank the flow won’t work, but this applies equally to the 
web based flows, and it’s not the kind of problem you see occur on a production 
system.

The evidence from the UK so far is that drop-off rates (where the user does not 
successfully complete the authentication and return to the third party) are far 
lower for app2app compared to a normal oauth2 browser based redirect flow; I 
can’t put my hand on the actual figures right now but from memory around 5 
times more users successfully completed an app2app flow than the usual web 
flows.

>> -  In the DECOUPLED approach it less critical since the TPP polls 
>> the bank and eventually gets its token once the PSU has authenticated.
> 
> But in the decoupled flow, the PSU first has to enter her PSU ID in order to 
> allow the TPP to identity the PSU towards the ASPSP. This is less convenient 
> and leaks PII.

Not necessarily the PSU ID, but generally something that can be used to 
identify the user. In theory it could be an ephemeral id, though in reality 
there’s all sorts of issues with implementing that, particularly on a ’same 
device’ flow. It’s definitely less convenient, particularly for the first 
TPP<->ASPSP interaction where the TPP will necessarily have to collect more 
info from the user than would be necessary in a redirect based flow.

The user also has to manually switch back to the TPP app at the end of the flow.

My general opinion is that for most use cases where the consumption and 
authentication devices are the same device a decoupled flow should not be used, 
as for that use case app2app presents a far better user experience - both in 
terms of the number of steps and the time taken to successfully complete all 
the steps.

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] embedded UA detection

[Joseph Heenan]

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” (or 
with good but misplaced intentions) using an embedded user agent.

In general the real state of the art would be for the party that owns the AS to 
have an associated first-party native mobile app, as that improves the user 
experience and greatly reduces the associated risks. I wrote about the pattern 
for doing this here:

https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authorisation.html

That said all the choices and risks here are very complex and interact with 
each other - from the information given I definitely can’t say whether app2app 
is a good approach in your use case.

Cheers

Joseph


> On 11 Oct 2019, at 15:44, Giada Sciarretta  wrote:
> 
> Hello,
>  
> We are working on a project that involves mobile native applications.
>  
> The OAuth for native apps (RFC8252) spec "requires that native apps MUST NOT 
> use embedded user-agents  to perform authorization requests and allows that 
> authorization endpoints MAY take steps to detect and block authorization 
> requests  in embedded user-agents".
>  
> We would like to integrate in our AS the state-of-the-art techniques for 
> detecting and blocking authorization requests in embedded user-agents. We are 
> aware of the following techniques (link 
> ):
> doing a string checking on the User agent string value. In the chromium 
> based-WebView
> in the older versions it adds the “Version/X.X” string into the UA field. For 
> example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) 
> AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
> in the newer version it will add, “;wv”. For example: Mozilla/5.0 (Linux; 
> Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like 
> Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
> checking the presence of X-Requested-With HTTP header, the value of this 
> header will be the application's name that is running the webview.
>  
> but we know that these detection methods can be bypassed by an attacker. Do 
> you have any suggestions in this regard?
>  
> Thank you in advance for your response.
>  
> Kind regards,
> Giada Sciarretta
>  
> 
> --
> Le informazioni contenute nella presente comunicazione sono di natura privata 
> e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai 
> destinatari indicati e per le finalità strettamente legate al relativo 
> contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di 
> eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente.
> --
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. If you received this in error, please contact the sender and delete 
> the material.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Device Authorization Grant Interval

[Joseph Heenan]

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 ‘invalid_request’ would 
be appropriate - ideally appropriate error_description to make it easy to 
understand what’s going on.

Cheers,

Joseph


> On 21 May 2019, at 06:21, Janak Amarasena  wrote:
> 
> Hi all,
> 
> In the OAuth2 Device Authorization Grant, what would be an appropriate 
> response if the client does not respect the set polling interval and keeps on 
> polling with a lower interval?
> 
> Thank you,
> Best Regards,
> 
> Janak Amarasena
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 optionally issued by an authorization
> server to a developer or client and used to authorize calls to the
> client registration endpoint.  The type and format of this token
> are likely service specific and are out of scope for this
> specification.  The means by which the authorization server issues
> this token as well as the means by which the registration endpoint
> validates this token are out of scope for this specification.  Use
> of an initial access token is required when the authorization
> server limits the parties that can register a client.

This can be used [for example] to bind a client to a specific user, though the 
bootstrapping can be a little involved and potentially the bootstrapping still 
has weaknesses. Use of white box crypto (or other tools like device 
attestations) can potentially also bring dynamically registered native apps up 
to a sufficiently trusted level.

Joseph


> On 29 Nov 2018, at 14:02, Christian Mainka 
>  wrote:
> 
> Hi,
> 
> thanks for pointing this out!
> This was exactly what confused us during reading - the main threat we see and 
> which is not addressed is related to the app impersonation attack.
> Even PKCE does not help against the app impersonation attack.
> 
> So a "Native App + Dynamic Client Registration" can be seen at a different 
> "confidentiality level" than a "public client", because every native App can 
> dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from an 
> malicious client starting an app impersonation attack.
> 
> We agree that, e.g., a leaked code cannot be redeemed unless you have the 
> respective client_id/client_secret.
> 
> But... we asked ourselfs, in which cases does a code leak?
> 
> 1) In the front-channel. In this case, it is true that no client credentials 
> leak and an attacker cannot redeem the code.
> 
> 2) In the back-channel. But if this channel is insecure, you directly get 
> client credentials (unless client_secret_jwt is used as pointed out by 
> George).
> 
> So, Dynamic Client Registration only helps if the code leaks alone (as in 
> 1.), or if it leaks on different levels (e.g. logfiles).
> 
> On the opposite site, if Dynamic Registration is available, an attacker can 
> very easily do an app impersonation attack by registering on the IdP. To be 
> clear, it is not "impersonation" as in the "one secret per software" 
> scenario, because different client_id and client_secret is used, but to the 
> best of my knowledge, the IdP cannot distinguish between an honest app and an 
> app impersonation client that has simply registered.
> 
> In addition, if the IdP supports the dynamic client registration:
> How can the IdP distinguish between confidential and public/native clients?
> With respect to the consent page, which must be shown every time for native 
> apps, this is an important issue, which should be addressed properly.
> 
> Best Regards
> Vladi/Christian 
> 
> Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
>> It should be noted that “traditional” confidential clients with registered 
>> return URLs and server-side secrets may provide a higher degree of 
>> confidence in the true identity of the client that doesn’t carry over to 
>> confidential native app clients. A native app instance’s registration call 
>> is necessarily unauthenticated (for the same reasons that statically 
>> registered native app clients are public clients), so the Client 
>> Impersonation concerns described in section 8.6 of 
>> RFC8252 
>>  still apply.
>> --
>> Annabelle Richard Backman
>> AWS Identity
>> 
>> 
>> From: OAuth   on 
>> behalf of Filip Skokan  
>> Date: Wednesday, November 28, 2018 at 9:11 AM
>> To: George Fletcher  
>> Cc: oauth  
>> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>> 
>> Apologies, I missed the issued in "issued a shared secret", just reading 
>> "shared secret" alone is the exact opposite of a per-instance secret. The 
>> rest is clear and as you say it brings the benefit of the secret never being 
>> sent over the wire (except during the initial registration via TLS).
>> 
>> Best,
>> Filip
>> 
>> 
>> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher >  
>> > wrote:
>> It's "confidential" in that the shared secret is unique to that app instance 
>> registration (as Dennis described in his response). If an attacker gets my 
>> phone and compromise

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

[Joseph Heenan]

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 parameters” means 
(particularly as it comes directly after a paragraph on the redirect_uri and I 
initially thought it was talking about that. Perhaps something along the lines 
of “avoid forwarding the user’s browser to a value from a uri query parameter” 
might be clearer.

" Clients SHALL ensure to only process “ could just be written ‘Client SHALL 
only process” I think.


2.1.1:

"Authorization servers SHALL consider the”  - is ’SHALL consider’ different to 
’SHOULD’? Or does it mean something like “SHALL implement at least one 
countermeasure from <…>”.

3.2.4:

This says "Authorization codes SHOULD be invalidated by the AS after their 
first use at the token endpoint”.

https://tools.ietf.org/html/rfc6749#section-10.5 says:

"Authorization codes MUST be short lived and single-use.”.

Does this "MUST be single-use” not effectively already require the code is 
invalidated after first use? If so why downgrade this to a “SHOULD”?


Cheers,

Joseph


> On 9 Nov 2018, at 09:42, Torsten Lodderstedt  wrote:
> 
> Hi all, 
> 
> the new revision incorporates the recommendation to use more secure grant 
> types instead of implicit we agreed to add during the WG session on Monday. 
> It also has more text around justifications for our recommendation. 
> Especially, there is a new section 3.6 on access token injection. 
> 
> I also posted about this topic on LinkedIn 
> (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/)
>  and Medium 
> (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926)
> 
> kind regards,
> Torsten. 
> 
>> Am 09.11.2018 um 09:32 schrieb internet-dra...@ietf.org:
>> 
>> 
>> 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 Security Best Current Practice
>>   Authors : Torsten Lodderstedt
>> John Bradley
>> Andrey Labunets
>> Daniel Fett
>>  Filename: draft-ietf-oauth-security-topics-09.txt
>>  Pages   : 35
>>  Date: 2018-11-09
>> 
>> Abstract:
>>  This document describes best current security practice for OAuth 2.0.
>>  It updates and extends the OAuth 2.0 Security Threat Model to
>>  incorporate practical experiences gathered since OAuth 2.0 was
>>  published and covers new threats relevant due to the broader
>>  application of OAuth 2.0.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-09
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 interest in mobile apps being 
dynamically (per-install) registered oauth2 private clients, and that model has 
a lot of advantages. (I’m not sure if we might see a similar model evolving for 
web apps.) 

The BCP for native apps does allow 
this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph





> On 6 Nov 2018, at 10:13, Aaron Parecki  wrote:
> 
> Thanks Hannes,
> 
> Since I wasn't able to give an intro during the meeting today, I'd like to 
> share a little more context about this here as well.
> 
> At the Internet Identity Workshop in Mountain View last week, I led a session 
> to collect feedback on recommendations for OAuth for browser based apps. 
> During the session, we came up with a list of several points based on the 
> collective experience of the attendees. I then tried to address all those 
> points in this draft.
> 
> The goal of this is not to specify any new behavior, but rather to limit the 
> possibilities that the existing OAuth specs provide, to ensure a secure 
> implementation in browser based apps.
> 
> Thanks in advance for your review and feedback!
> 
> Aaron Parecki
> aaronpk.com 
> 
> 
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig  > wrote:
> Hi all,
> 
> Today we were not able to talk about 
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for 
> Browser-Based Apps".
> 
> Aaron put a few slides together, which can be found here:
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>  
> 
> 
> Your review of this new draft is highly appreciated.
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> -- 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 responding to your assertion that PKCE is not required when TLS is 
in use. I believe that assertion was not right, as the above attack is against 
TLS enabled servers and PKCE would have made any stolen auth code useless, so 
PKCE still has value even when using TLS.

Thanks

Joseph


> On 23 May 2018, at 12:58, Denis  wrote:
> 
> Hi Joseph,
> 
> Among these 39 slides, to which attack(s) are you referring ?
> 
> I wrote:"It is quite hard to understand under which context(s) and conditions 
> OAuth 2.0 could be safely used".
> 
> For each counter-measure, it would be useful to explain under which 
> context(s) or under which assumptions 
> it should be used. 
> 
> Denis
> 
>> 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 
>>> response".
>>> 
>>> This is incorrect, since RFC7636 should be used when the authorization code 
>>> is returned from the authorization endpoint
>>> within a communication path that is not protected by Transport Layer 
>>> Security (TLS).
>>> 
>> That is not really the full story as we've seen attacks where URLs that you 
>> would expect to be protected by TLS are vulnerable; one example is:
>> 
>> https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf
>>  
>> 
>> 
>> IMHO it would be sane to use PKCE anywhere where a code is returned in the 
>> URL and there isn't another proof of possession / token binding mechanism in 
>> play.
>> 
>> Joseph
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

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 
> response".
> 
> This is incorrect, since RFC7636 should be used when the authorization code 
> is returned from the authorization endpoint
> within a communication path that is not protected by Transport Layer Security 
> (TLS).
> 
That is not really the full story as we've seen attacks where URLs that you 
would expect to be protected by TLS are vulnerable; one example is:

https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf

IMHO it would be sane to use PKCE anywhere where a code is returned in the URL 
and there isn't another proof of possession / token binding mechanism in play.

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Revocation error codes

[Joseph Heenan]

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 easier for the 
developer of the client app to see that they've done something wrong and need 
to fix their implementation seems like a worthwhile goal to me, and that would 
appear to explain what google are thinking with their responses.

An example of an easy to make error that would get a 200 response is getting 
the values the wrong way around, i.e. a body of:

 token=refresh_token&token_type_hint=45ghiukldjahdnhzdauz

(as token_type_hint may be ignored by the server.)

The example Sergey gave of the developer accidentally sending the id token 
instead of the intended token seems quite likely to happen in the real world 
too, and a 200 response in that case does seem wrong to me.


Joseph


> On 21 May 2018, at 22:29, Justin Richer  wrote:
> 
> I’m with George here: revocation is almost a best-effort request from the 
> client’s perspective. It sends a message to the server saying “hey I’m done 
> with this token, you can throw it out too”. If the server does revoke the 
> token, the client throws it out. If the server doesn’t revoke the token? Then 
> the client still throws it out. Either way the results from the client’s 
> perspective are the same: it’s already decided that it’s done with the token 
> before it talks to the server. It’s an optional cleanup step in most  OAuth 
> systems.
> 
>  — Justin
> 
>> On May 21, 2018, at 5:08 PM, George Fletcher 
>> > > wrote:
>> 
>> I'm not understanding how these different cases matter to the client? I 
>> doubt that the running code will be able to dynamically handle the error. So 
>> it seems this information is only relevant to the developers and not 
>> relevant from an end user and the client perspective.
>> 
>> Also, for the 5 states you define, the effect of calling revocation is still 
>> that the token is "revoked" because the token is already not valid.
>> 
>> So from an implementation perspective, where is the concern that developer 
>> will do the "wrong thing" without these more detailed error responses?
>> 
>> Thanks,
>> George
>> 
>> On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
>>> Hi,
>>> 
>>> I developing an implementation of back channel token revocation endpoint. 
>>> And I think we should reconsider and probably change the specification to 
>>> improve error handling.
>>> 
>>> Here we see several situations of error state:
>>> 1. token wasn't sent in request.
>>> 2. token is invalid by format i.e. not JWT or JWT with invalid signature
>>> 3. token is expired or token is even unknown
>>> 4. token was already revoked
>>> 5. token type is unsupported 
>>> 
>>> According to  RFC7009 OAuth 2.0 Token Revocation 
>>>   section 2.2 Revocation Response:
>>> 
>>> The authorization server responds with HTTP status code 200 if the token 
>>> has been revoked successfully or if the client submitted an invalid token.
>>> Note: invalid tokens do not cause an error response since the client cannot 
>>> handle such an error in a reasonable way.  Moreover, the purpose of the 
>>> revocation request, invalidating the particular token, is already achieved..
>>> 
>>> As you may see this section covers only case 3 and case 4 but it's very 
>>> unclear: calling token as "invalid" is very broad definition.
>>> I think we should take a look on each case separately:
>>> 
>>> 1. token wasn't sent in request. 
>>> Most implementations returns 400 status code, error: "invalid_request", 
>>> error_description": "Missing required parameter: token".
>>> Note that returned error is not "invalid_token" but "invalid_request" and I 
>>> think this should be correct behavior and should be clearly specified.
>>> 
>>> 2. token is invalid by format i.e. not JWT or JWT with invalid signature
>>> This error is mostly related to JWT but for reference (opaque) tokens can 
>>> be also applied (e.g. token is too long).
>>> Goolge OAuth returns 400 code with  "error": "invalid_token" and I think 
>>> this is correct behavior.
>>> The client can have a bug and sends invalid tokens so we should return an 
>>> error response instead of 200 status.
>>> 
>>> 3. token is expired or even unknown
>>> Spec says that IdP should return 200 in this case but in case of unknown 
>>> token this may be a symptom of a bug on client side. Even if IdP can 
>>> clearly determine that token is expired (in case of JWT) this is hard to 
>>> determine in case of reference token that was removed from DB.
>>> So personally I think that from security perspective it's better to 
>>> response with 400 status because client can have a bug when it's sends some 
>>> unknown token and think that it was revoked while it wasn't.
>>> 
>>> For

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

[Joseph Heenan]

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.org/html/rfc6749#section-4.1.2.1 defines several more 
potential errors that appear to fall into the same category. I understand to 
block the attack fully we need 'must not redirect's for all the kinds of error 
that could cause an automatic redirect back to the client's registered redirect 
uri without any user interaction - 'unauthorized_client' and 
'unsupported_response_type' seem to fall into that category. 'server_error' 
also seems dodgy (I would wager that on some servers that are known ways to 
provoke server errors), and I would have doubts about 'temporarily_unavailable' 
too.

Thanks

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth