[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

[Filip Skokan]

Hello Chaitanya.

The AS is to treat the state value as an opaque string, merely echoing it
back to the client, at most the AS is required to ensure the state's syntax
is within its ABNF definition, then send its exact value back with the
authorization response.

I don't find this particular AS implementation's documentation-defined
state use to fall outside of its intended use. Of course it could come with
more guidance on how to achieve those particular purposes securely, so that
the client doesn't become an Open Redirector
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-client-as-open-redirector>
.

S pozdravem,
*Filip Skokan*


On Mon, 1 Jul 2024 at 14:20, Chaitanya Reddy 
wrote:

> Hi Team,
>
> Hope you are doing well!
>
> I am writing this mail regarding the discussion of usage of *state*
> parameter in the OAuth implementation.
>
> As per the RFC 6749, "*An opaque value is used by the client to maintain
> state between the request and callback. And it should be used to prevent
> cross-site request forgery*". Since it's an opaque value, OAuth
> implementors usually don't sanitize the value.
>
> One of the OAuth 2.0 implementors (Google) have defined state as "*You
> can use this parameter for several purposes, such as directing the user to
> the correct resource in your application, sending nonces, and mitigating
> cross-site request forgery*"
>
> The issue arries here due to the fact that Google allows the use of state
> parameter for directing the users to the correct resource. Since the value
> in RFC is defined as *opaque, *they are not sanitizing the value for any
> possible malicious values. I have observed two instances where clients
> using Google's OAuth service directly use the state parameter value in 
> *Location
> header *to redirect the users hence resulting in header injection attacks.
>
> As per my understanding, this issue arises due to the fact that:
> 1. Google allows state parameter to be used for purpose not defined in RFC.
> 2. Google is not sanitizing the state paramater on their end.
> 3. Client is also not sanitizing the state paramater and directly using it
> in the *Location* header.
>
> I have raised this issue to google via google VRP but after weeks of
> communication over the ticket, the engineer feels like they are not in
> disagreement with the spec and have requested me to discuss it further with
> your team and hence i am reaching out to you.
>
> Please let me know your thoughts about this.
>
> Regards,
> Chaitanya Reddy
> ___
> 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

Re: [OAUTH-WG] Query on correct approach of calculating the "x5t#S256" parameter in the JWKS response

[Filip Skokan]

I agree and share Neil's position.

Furthermore, to answer your question, no you should not use or accept both
of the approaches as valid methods. Only Method 1 is valid.

S pozdravem,
*Filip Skokan*


On Tue, 16 Jan 2024 at 20:54, Neil Madden  wrote:

> JWS refers to FIPS 180-4 as the definition of SHA-256. That spec defines
> the message digest produced by SHA-256 as a 256-bit binary value, not a
> hex-encoded string. So the "base64url-encoded SHA-256 thumbprint (a.k.a.
> digest)" is your Method 1. Anyone doing Method 2 has a bug.
>
> -- Neil
>
> On 10 Jan 2024, at 04:10, Thamindu Dilshan Jayawickrama <
> thamindudill...@gmail.com> wrote:
>
> Hi all,
>
> I have initiated this mail thread to get your opinion on the correct
> approach of calculating the "x5t#S256" parameter in the JWKS response. JWS
> specification [1
> <https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.8>] defines
> the "x5t#S256" parameter as follows.
>
> """
> The "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header
> Parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest)
> of the DER encoding of the X.509 certificate [RFC5280] corresponding
> to the key used to digitally sign the JWS.
> """
>
> Different parties seem to be using two different methods when calculating
> this field.
>
> *Method 1:*
>
> 1. Take DER encoding of the certificate which produces a 32 byte array
> 2. Take the base64 url encoding
>
> In this method, we compute this "x5t#S256" parameter by directly url
> encoding the 32 byte array without taking the hex string. Example given at
> appendix A of the MTLS token spec [2
> <https://datatracker.ietf.org/doc/html/rfc8705#section-appendix.a>]
> appears to be following this method.
>
> *Method 2:*
>
> 1. Take DER encoding of the certificate which produces a 32 byte array
> 2. Convert it into a hexadecimal string and transform it into a 64 byte
> array
> 3. Take the base64 url encoding
>
> In some places I have seen the following approach is used to obtain a
> value equal to the "x5t#S256" field.
>
> 1. Display the certificate with a tool like Keytool Explorer and copy the
> SHA 256 fingerprint.
> 2. Remove colons (":"s) and convert it to all lowercase.
> 3. Base64url encode the value.
>
> This approach requires the above hexifing step (method 2) in order to
> produce a similar result when computing the "x5t#S256" field.
>
> Hence I would like to query about the correct approach to follow when
> calculating the "x5t#S256" parameter. Or can we accept both these forms as
> correct methods to calculate the mentioned field?
>
> Thanks in advance.
>
> [1] https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.8
> [2] https://datatracker.ietf.org/doc/html/rfc8705#section-appendix.a
>
> Best Regards,
> Thamindu Jayawickrama
>
> ___
> 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 for “web_message” Response Mode - Asking For Feedback

[Filip Skokan]

You may be right. I no longer have the setup for this at hand but I believe
it depended on relaxing the domain settings through the now deprecated (and
in some browsers already removed or otherwise void) document.domain
property.

If the flow is unrecoverable it makes no sense to spend effort on keeping
it around.

S pozdravem,
*Filip Skokan*


On Thu, 11 Jan 2024 at 16:07, Karsten Meyer zu Selhausen | Hackmanit <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> That's an interesting use-case for relay mode and might be a reason to
> cover it.
>
> However, we believe the current code for the relay mode in
> draft-sakimura-oauth-wmrm-01 does not work. The same-origin policy should
> prevent this line from working:
>
> messageTargetWindowReference =
> e.source.document.getElementById(web_message_target);
>
> "e.source" references the main window (e.g., client.example.com). This
> means the (un)authenticated window (e.g., as.example.com) tries to access
> "document.getElementById" for the cross-origin main window.
> Due to the SOP the browser should throw a DOMException ("Failed to read a
> named property 'document' from 'Window': Blocked a frame with origin
> "https://as.example.com"; <https://as.example.com> from accessing a
> cross-origin frame.")
>
> As I said in the other response, we would be really interested in taking a
> look at existing implementations of draft-sakimura-oauth-wmrm-01 to see
> how they solve this problem.
>
>
> Best regards,
> Karsten
>
>
> On 10.01.2024 10:15, Filip Skokan wrote:
>
> We do not consider the relay mode. The relay mode is motivated by the use
>> of the implicit grant which is discouraged nowadays.
>
>
> Motivation aside, if my memory serves right (and that's a big IF in this
> case), the relay mode was not limited to implicit responses and was useful
> regardless of the response type, e.g. in cases where the authorization
> request was triggered from an eTLD+1 top level window but the target was
> authenticating a service that ran on its subdomain, a landing page with a
> CTA to login sort of setup.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 10 Jan 2024 at 09:47, Filip Skokan  wrote:
>
>> our draft covers and is compatible to what's called "simple mode" (both
>>> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
>>
>>
>> So a client that's using a simple mode with web_message today could,
>> without change, utilize your draft as well? That doesn't seem likely given
>> the message structure is not the same as in draft-sakimura-oauth-wmrm. Is
>> that an omission or intentional?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit <
>> karsten.meyerzuselhau...@hackmanit.de> wrote:
>>
>>> Hello Filip,
>>>
>>> our draft covers and is compatible to what's called "simple mode" (both
>>> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
>>>
>>> We do not consider the relay mode. The relay mode is motivated by the
>>> use of the implicit grant which is discouraged nowadays.
>>>
>>> The main differences to draft-sakimura-oauth-wmrm-01 can be summarized
>>> as follows:
>>>
>>>- In general we do not focus on "modes" but instead on the actual
>>>communication using the postMessage API. Our draft contains examples for
>>>the format/structure for the messages sent using the postMessage API.
>>>- Our draft enables iframe flows with user interaction while 
>>> draft-sakimura-oauth-wmrm-01
>>>only covers iframe flows without user interaction.
>>>- Our draft contains security considerations describing threats and
>>>giving recommendations to address them.
>>>- Our draft briefly discusses the implications of the 3rd party
>>>cookie phaseout for iframes.
>>>
>>> Our main motivation is the belief that there is a need for a
>>> specification defining how to securely use the postMessage API for OAuth
>>> auth. responses. The research of my co-authors underlines this need [1].
>>>
>>> As I said, at the last OSW there was agreement that it would be a good
>>> idea to write an RFC for a postMessage-based response mode. 
>>> draft-sakimura-oauth-wmrm-00
>>> was expired years ago and seemed to be inactive when we started to work on
>>> our own draft. In our opinion it is not a great option to rely on an
>>> expired dra

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

[Filip Skokan]

>
> We do not consider the relay mode. The relay mode is motivated by the use
> of the implicit grant which is discouraged nowadays.


Motivation aside, if my memory serves right (and that's a big IF in this
case), the relay mode was not limited to implicit responses and was useful
regardless of the response type, e.g. in cases where the authorization
request was triggered from an eTLD+1 top level window but the target was
authenticating a service that ran on its subdomain, a landing page with a
CTA to login sort of setup.

S pozdravem,
*Filip Skokan*


On Wed, 10 Jan 2024 at 09:47, Filip Skokan  wrote:

> our draft covers and is compatible to what's called "simple mode" (both
>> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
>
>
> So a client that's using a simple mode with web_message today could,
> without change, utilize your draft as well? That doesn't seem likely given
> the message structure is not the same as in draft-sakimura-oauth-wmrm. Is
> that an omission or intentional?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit <
> karsten.meyerzuselhau...@hackmanit.de> wrote:
>
>> Hello Filip,
>>
>> our draft covers and is compatible to what's called "simple mode" (both
>> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
>>
>> We do not consider the relay mode. The relay mode is motivated by the use
>> of the implicit grant which is discouraged nowadays.
>>
>> The main differences to draft-sakimura-oauth-wmrm-01 can be summarized
>> as follows:
>>
>>- In general we do not focus on "modes" but instead on the actual
>>communication using the postMessage API. Our draft contains examples for
>>the format/structure for the messages sent using the postMessage API.
>>- Our draft enables iframe flows with user interaction while 
>> draft-sakimura-oauth-wmrm-01
>>only covers iframe flows without user interaction.
>>- Our draft contains security considerations describing threats and
>>giving recommendations to address them.
>>- Our draft briefly discusses the implications of the 3rd party
>>cookie phaseout for iframes.
>>
>> Our main motivation is the belief that there is a need for a
>> specification defining how to securely use the postMessage API for OAuth
>> auth. responses. The research of my co-authors underlines this need [1].
>>
>> As I said, at the last OSW there was agreement that it would be a good
>> idea to write an RFC for a postMessage-based response mode. 
>> draft-sakimura-oauth-wmrm-00
>> was expired years ago and seemed to be inactive when we started to work on
>> our own draft. In our opinion it is not a great option to rely on an
>> expired draft. As for customers I work with this is not an option at all;
>> they want to implement and use final RFCs whenever possible.
>>
>> We are looking for feedback from the WG and are open to collaborate with
>> the authors of draft-sakimura-oauth-wmrm if they want to join the efforts.
>>
>>
>> Best regards,
>> Karsten
>>
>> [1] https://distinct-sso.com/
>> On 04.01.2024 12:10, Filip Skokan wrote:
>>
>> Hello Karsten,
>>
>> Can you summarize in what ways is your draft compatible
>> with draft-sakimura-oauth-wmrm-00? Which of the described modes in Nat's
>> document does it cover?
>>
>> There are existing implementations (both partial and full)
>> of draft-sakimura-oauth-wmrm-00 so if your draft is not compatible I would
>> recommend not using the same response mode name/identifier in your proposal.
>>
>> What prompted you to start a new draft rather than
>> using draft-sakimura-oauth-wmrm-00?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit <
>> karsten.meyerzuselhau...@hackmanit.de> wrote:
>>
>>> Hi all,
>>>
>>> we would like to ask again for feedback on our draft for the
>>> "web_message" response mode:
>>> *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
>>> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/>
>>> *
>>>
>>> We think it would be very helpful for implementers and developers to
>>> specify a secure standard for a postMessage API-based response mode.
>>>
>>> Best regards,
>>> Karsten
>>> On 23.11.2023 10:11, Karsten Meyer zu Selhausen | 

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

[Filip Skokan]

>
> our draft covers and is compatible to what's called "simple mode" (both
> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.


So a client that's using a simple mode with web_message today could,
without change, utilize your draft as well? That doesn't seem likely given
the message structure is not the same as in draft-sakimura-oauth-wmrm. Is
that an omission or intentional?

S pozdravem,
*Filip Skokan*


On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hello Filip,
>
> our draft covers and is compatible to what's called "simple mode" (both
> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
>
> We do not consider the relay mode. The relay mode is motivated by the use
> of the implicit grant which is discouraged nowadays.
>
> The main differences to draft-sakimura-oauth-wmrm-01 can be summarized as
> follows:
>
>- In general we do not focus on "modes" but instead on the actual
>communication using the postMessage API. Our draft contains examples for
>the format/structure for the messages sent using the postMessage API.
>- Our draft enables iframe flows with user interaction while 
> draft-sakimura-oauth-wmrm-01
>only covers iframe flows without user interaction.
>- Our draft contains security considerations describing threats and
>giving recommendations to address them.
>- Our draft briefly discusses the implications of the 3rd party cookie
>phaseout for iframes.
>
> Our main motivation is the belief that there is a need for a specification
> defining how to securely use the postMessage API for OAuth auth. responses.
> The research of my co-authors underlines this need [1].
>
> As I said, at the last OSW there was agreement that it would be a good
> idea to write an RFC for a postMessage-based response mode. 
> draft-sakimura-oauth-wmrm-00
> was expired years ago and seemed to be inactive when we started to work on
> our own draft. In our opinion it is not a great option to rely on an
> expired draft. As for customers I work with this is not an option at all;
> they want to implement and use final RFCs whenever possible.
>
> We are looking for feedback from the WG and are open to collaborate with
> the authors of draft-sakimura-oauth-wmrm if they want to join the efforts.
>
>
> Best regards,
> Karsten
>
> [1] https://distinct-sso.com/
> On 04.01.2024 12:10, Filip Skokan wrote:
>
> Hello Karsten,
>
> Can you summarize in what ways is your draft compatible
> with draft-sakimura-oauth-wmrm-00? Which of the described modes in Nat's
> document does it cover?
>
> There are existing implementations (both partial and full)
> of draft-sakimura-oauth-wmrm-00 so if your draft is not compatible I would
> recommend not using the same response mode name/identifier in your proposal.
>
> What prompted you to start a new draft rather than
> using draft-sakimura-oauth-wmrm-00?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit <
> karsten.meyerzuselhau...@hackmanit.de> wrote:
>
>> Hi all,
>>
>> we would like to ask again for feedback on our draft for the
>> "web_message" response mode:
>> *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
>> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/>
>> *
>>
>> We think it would be very helpful for implementers and developers to
>> specify a secure standard for a postMessage API-based response mode.
>>
>> Best regards,
>> Karsten
>> On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit wrote:
>>
>> Hi everyone,
>>
>> at the last OSW the topic of a response mode based on the postMessage
>> API came up. This approach is already used by multiple parties (e.g.,
>> Google) but lacks standardization.
>>
>> There was some sense of agreement that it would be a good idea to create
>> an RFC defining this response mode to counter security flaws in individual
>> implementations and improve interoperability.
>>
>> Because the efforts in the past were long expired (draft -00 of
>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/ expired in
>> 2016) we took the initiative and started to work on a new ID for the
>> "web_message" response mode.
>>
>> *We would like to to ask the members of the working group for feedback on
>> our draft:
>> https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
>> <htt

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

[Filip Skokan]

Hello Karsten,

Can you summarize in what ways is your draft compatible
with draft-sakimura-oauth-wmrm-00? Which of the described modes in Nat's
document does it cover?

There are existing implementations (both partial and full)
of draft-sakimura-oauth-wmrm-00 so if your draft is not compatible I would
recommend not using the same response mode name/identifier in your proposal.

What prompted you to start a new draft rather than
using draft-sakimura-oauth-wmrm-00?

S pozdravem,
*Filip Skokan*


On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hi all,
>
> we would like to ask again for feedback on our draft for the "web_message"
> response mode:
> *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/>
> *
>
> We think it would be very helpful for implementers and developers to
> specify a secure standard for a postMessage API-based response mode.
>
> Best regards,
> Karsten
> On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit wrote:
>
> Hi everyone,
>
> at the last OSW the topic of a response mode based on the postMessage API
> came up. This approach is already used by multiple parties (e.g., Google)
> but lacks standardization.
>
> There was some sense of agreement that it would be a good idea to create
> an RFC defining this response mode to counter security flaws in individual
> implementations and improve interoperability.
>
> Because the efforts in the past were long expired (draft -00 of
> https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/ expired in
> 2016) we took the initiative and started to work on a new ID for the
> "web_message" response mode.
>
> *We would like to to ask the members of the working group for feedback on
> our draft:
> https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/>*
>
>
> I see that "draft-sakimura-oauth-wmrm" has been recently updated. However,
> there have not been any changes to its contents. What are the plans of the
> authors for this draft?
>
> Best regards
> Karsten
>
> --
> Karsten Meyer zu Selhausen
> Senior IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Multi-Factor Authentication (MFA) significantly increases the security of 
> your accounts.
> Learn in our blog posts what the best MFA options are and how FIDO2 goes one 
> step further to solve the world’s password 
> problem:https://www.hackmanit.de/en/blog-en/162-what-is-mfahttps://www.hackmanit.de/en/blog-en/165-what-is-fido2
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Prof. Dr. Marcus Niemietz
>
> --
> Karsten Meyer zu Selhausen
> Senior IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Multi-Factor Authentication (MFA) significantly increases the security of 
> your accounts.
> Learn in our blog posts what the best MFA options are and how FIDO2 goes one 
> step further to solve the world’s password 
> problem:https://www.hackmanit.de/en/blog-en/162-what-is-mfahttps://www.hackmanit.de/en/blog-en/165-what-is-fido2
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Prof. Dr. Marcus Niemietz
>
> ___
> 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] Proposed OAuth Security BCP text on the use of CORS

[Filip Skokan]

Hello Christopher,The wmrm specification use does not require CORS at the authorization endpoint. - Filip9. 3. 2023 v 10:12, Christopher Burroughs :Greetings,I apologize in advance if this question (my first in this list!) is silly :)Regarding CORS support for the authorization endpoint, what about "web message" silent refresh flows? While it never became an RFC, I reckon it is implemented in quite a few places. Is this pattern generally discouraged now? Perhaps even more due to the unavailability of same site cookies?Thanks for the interesting discussions, Best regards,Chris






Sent with Proton Mail secure email.



--- Original Message ---
On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci  wrote:

Ha, we chatted about this during yesterday's office hours meeting and I was chartered to propose new language, but I am not sure how to incorporate this new info. Let me try to summarize here and see your reactions, DW.Apps implemented in SPAs style can either handle token acquisition and renewal from the user agent code, via classic authorization code + PKCE, or delegate that to a backend (BFF or "TMI BFF") while retaining "SPA style" for every other app function (eg UX). CORS is required only for the former approach, and one could argue that the latter offers better security.We can either expand on that nuance, or more simply switch the SHOULD to MAY so that we inform the reader of what it takes to support (a style of SPA) but we don't appear to be advocating for the less secure option.On CORS for the authorization endpoint. I thought the MUST NOT was aimed at preventing programmatic access to the authorization endpoint from user agents. Flipping around: are there any other scenarios involving the authorization endpoint for which CORS support enables valid use cases? On Wed, Mar 8, 2023 at 10:50 AM David Waite 40alkaline-solutions@dmarc.ietf.org> wrote:

This message originated outside your organization.
  
I would suggest SHOULD guidance for CORS for OAuth token endpoints and authorization endpoints which are publicly accessible.There are a lot of misconceptions about the security properties of CORS, and in particular the security properties from disabling CORS for an otherwise safe resource. To my knowledge there is one benefit of disabling for solely internally-facing infrastructure.To detail, a public website interacting with a user agent bridging public and private networks can use IPs and DNS to attempt to scan internal web infrastructure. It may attempt to manipulate browser-accessible resources via GET/POST, and get some information on the shape of the network via error and timing-based analysis. Enabling or disabling CORS does not affect reachability for GET/form POST requests (which do not require CORS preflight), but does affect visibility of the response.In such an environment, having CORS enabled for a metadata resource might reveal additional information to an attacker - such as purpose of a particular system, and possibly the author/vendor of a particular product. Note that they may be able to get this from other heuristics of that product as well, through analysis of other GET/POST requests (such as to vendor-specific endpoints).There is an incubated effort ( https://wicg.github.io/local-network-access/ ) which has rather good introductory/explainer text for this class of issue. I believe Chrome has partially implemented (targeting roll out in 113) - I do not know other browser intention or status. As currently documented, this would effectively block API access across public and internal/private network ranges without a CORS pre-flight and a new pre-flight response. If adopted by other browsers, this provides a stronger ability to give SHOULD guidance for CORS, without distinctions between public and internal/private infrastructure.-DWOn Mar 8, 2023, at 8:36 AM, Aaron Parecki 40parecki@dmarc.ietf.org> wrote:Since that is my comment referenced in the OpenID thread, I should clarify that my intent was to have this language in the Security BCP with the caveat that it's only applicable if your AS intends on supporting SPAs. In other words, we're not saying all ASs SHOULD add CORS headers, only ASs that intend on supporting SPAs. However, even if the AS does not intend on supporting SPAs, it still MUST NOT enable CORS at the authorization endpoint.I don't know the best language to put in front of Mike's suggested text to make that clear, so suggestions are welcome.AaronOn Tue, Mar 7, 2023 at 11:16 PM Mike Jones 40microsoft@dmarc.ietf.org> wrote:






I propose adding the following section to the OAuth Security BCP specification: Usage of CORS   The Token Endpoint,  Authorization Server Metadata Endpoint,  jwks_uri Endpoint,  Dynamic Client Registration Endpoint,  and any other endpoints directly accessed by Clients  

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Filip Skokan]

I too believe the Errata should be verified. (Although I think the
parameter names request and client_id should be in quotes in the corrected
text?).

S pozdravem,
*Filip Skokan*


On Tue, 19 Jul 2022 at 15:44, Torsten Lodderstedt 
wrote:

> I’m not sure this requires an update. It basically says „stick the uri you
> get from step 1 into this parameter in step 2“. Does this really require
> use to re-state any further requirements of a proper JAR?
>
> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef  >:
>
> + Roman and Paul
>
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> I believe this should be verified. I'm also the one that reported it
>> though. But it's been sitting in reported status for a while now.
>>
>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System <
>> rfc-edi...@rfc-editor.org> wrote:
>>
>>> The following errata report has been submitted for RFC9126,
>>> "OAuth 2.0 Pushed Authorization Requests".
>>>
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6711
>>>
>>> --
>>> Type: Technical
>>> Reported by: Brian Campbell 
>>>
>>> Section: 3.
>>>
>>> Original Text
>>> -
>>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>>to push a Request Object JWT to the authorization server.  The rules
>>>for processing, signing, and encryption of the Request Object as
>>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>>given client authentication method are included in the "application/
>>>x-www-form-urlencoded" request directly and are the only parameters
>>>other than "request" in the form body (e.g., mutual TLS client
>>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>>while JWT assertion-based client authentication [RFC7523] uses
>>>"client_assertion" and "client_assertion_type").  All other request
>>>parameters, i.e., those pertaining to the authorization request
>>>itself, MUST appear as claims of the JWT representing the
>>>authorization request.
>>>
>>> Corrected Text
>>> --
>>>   Clients MAY use the request and client_id parameters as defined in
>>>   JAR [RFC9101] to push a Request Object JWT to the authorization
>>>   server. The rules for processing, signing, and encryption of the
>>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>>   required by a given client authentication method are included in the
>>>   application/x-www-form-urlencoded request directly and are the only
>>>   parameters other than request and client_id in the form body (e.g.,
>>>   JWT assertion-based client authentication [RFC7523] uses
>>>   "client_assertion" and "client_assertion_type") HTTP request
>>>   parameters). All authorization request parameters, i.e., those
>>>   pertaining to the authorization request itself, MUST appear as
>>>   claims of the JWT representing the authorization request.
>>>
>>> Notes
>>> -
>>> That first paragraph of Sec 3 was not properly updated to come inline
>>> with JAR (now RFC9101) when it changed in draft -21 to require "client_id"
>>> in the authorization request in addition to in addition to "request" or
>>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that
>>> "client_id" isn't required. But it is required based on how PAR works and
>>> RFC9101 requiring "client_id".
>>>
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --
>>> RFC9126 (draft-ietf-oauth-par-10)
>>> --
>>> Title   : OAuth 2.0 Pushed Authorization Requests
>>> Publication Date: September 2021
>>> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D.
>>> Tonge, F. Skokan
>>> Category: PROPOSED STANDARD
>>> Source  : Web Authorization Protocol
>>> Area: Security
>>> Stream  : IETF
>>> Verifying Party : IESG
>>>
>>
>> *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

Re: [OAUTH-WG] Step-up Authentication review

[Filip Skokan]

Hello Rifaat, Brian, Vittorio, everyone,

As a follow up to the last IETF meeting, I've reviewed the step up
authentication draft again.

Aside from a number of typos and what was shared and discussed at the IETF
meeting in person I believe the mechanism could use an AS discovery
component.

I believe that a call for adoption is in order so that this document may
get worked on under the working group process.

Best,
*Filip Skokan*


On Wed, 20 Apr 2022 at 18:31, Rifaat Shekh-Yusef 
wrote:

> Gentlemen,
>
> During the last IETF meeting, you volunteered to review the step-up
> authentication draft.
>
> https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-step-up-authn-challenge
>
> Can you please review the document and provide your feedback on the
> mailing list?
>
> Thanks,
>  Rifaat
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Regarding iat and nonce in DPoP Proofs

[Filip Skokan]

Hello Jacob, dear Authors,

If the server (AS or RS) utilizes the `nonce` mechanism to limit the
acceptance timeframe of DPoP Proof JWTs it would appear the need to check
the `iat` claim for "freshness" is redundant. If we're making the client
jump through hoops to enforce fresh proofs via `nonce` it seems counter
intuitive that the validation could still fail due to client or server side
clock skews (regardless of how unreasonable they may be).

Changes would need to be introduced in (source
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-07>)

   - section 4.3. point 11
  - the iat claim value is within an acceptable timeframe and, within a
  reasonable consideration of accuracy and resource utilization, a
proof JWT
  with the same jti value has not previously been received at the same
  resource during that time period (see Section 11.1)
  - section 11.1
  - To prevent this, servers MUST only accept DPoP proofs for a limited
  time window after their iat time, preferably only for a relatively brief
  period (on the order of seconds or minutes).

Proposal:

Section 4.3. point 11
*if the server did not provide a nonce value to the client that was
verified in the previous point*, that the iat claim value is within an
acceptable timeframe and, within a reasonable consideration of accuracy and
resource utilization, a proof JWT with the same jti value has not
previously been received at the same resource during that time period (see
Section 11.1)

Section 11.1 upon a second read may not need an update afteral due to the
following language "Server-provided nonces are an effective means of
preventing DPoP proof replay.". That being said, server-provided nonces do
nothing about replay within a short time window, they ensure freshness, so
may need a bit of language afterall.

S pozdravem,
*Filip Skokan*


On Tue, 29 Mar 2022 at 16:23, Jacob Ideskog  wrote:

> Hi all,
>
> We have encountered a situation in the wild which I would like to share
> and discuss with you.
>
> We have strict validation of the iat claim as per section 4.3 in the
> specification where we allow a reasonable skew.
>
> The problem we see is that some users (more than a few) have changed the
> clock on their mobile device. This is commonly done for users playing games
> where changing the clock gives them more credit in the game. This means
> that the drift is more than reasonable as per the specification. It can be
> hours to days.
>
> The solution is to use the newer "nonce" parameter (which wasn't in the
> early drafts) to be able to manage the TTL server side, since the server
> controls the nonce and can therefore control the TTL of any proof received.
>
> However, the wording in section 4.3 states that:
>
> the iat claim value is within an acceptable timeframe and,
> within a reasonable consideration of accuracy and resource
> utilization, a proof JWT with the same jti value has not
> previously been received at the same resource during that time
> period (see Section 11.1 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-07#section-11.1>),
>
> And in section 11.1 this limits it to seconds or minutes.
>
> So, even though using nonces could solve clock sync issues, it's not
> possible due to the strictness of the iat claim verification.
>
> Could we relax the wording of the iat claim verification to let the nonce
> be the main solution in some cases:
>
> Suggestion:
> the iat claim value is within an acceptable timeframe and,
> within a reasonable consideration of accuracy and resource
> utilization, a proof JWT with the same jti value has not
> previously been received at the same resource during that time
> period (see Section 11.1), *unless the clock syncronization can
> be made to depend on the issuance of the nonce values.*
>
> Regards
> Jacob
>
> --
> Jacob Ideskog
> CTO
> Curity AB
> ---
> Sankt Göransgatan 66, Stockholm, Sweden
> M: +46 70-2233664
> j a...@curity.io
> curity.io
> ---
> ___
> 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-bertocci-oauth-step-up-authn-challenge - how can an RS signal re-authenticate user, without concern for ACR?

[Filip Skokan]

I believe through the use of max_age.

- Filip

> 24. 3. 2022 v 15:59, Vladimir Dzhuvinov :
> 
> Given the suggested protocol for step up (I just watched the talk in Vienna, 
> thanks Vittorio & Brian) - how could an RS signal that it simply wants the 
> end-user re-authenticated, without being concerned about the ACR?
> 
> Vladimir
> 
> -- 
> Vladimir Dzhuvinov
> 
> ___
> 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 + Token Revocation

[Filip Skokan]

Hi Dmitry,

Sender-constrained access tokens via Client certificate (MTLS) likewise do
not require mtls to be used for revocation or introspection (unless it's
for client authentication).

- Filip


On Thu, 10 Feb 2022 at 09:08, Warren Parad  wrote:

> I'm a big fan of not arbitrarily adding security to paths that don't
> require it. The more complicated it is to do what you want without a
> concrete reason, the more likely there will be an introduced vulnerability.
>
> Consistency on adding requirements to endpoints that don't need it also
> makes them harder to use. In this case, I challenge that if the attacker
> could intercept login to get both a valid token and steal the DPoP key,
> that preventing refresh token revocation is meaningless. Being able to
> revoke the refresh token doesn't decrease the vulnerable surface, so adding
> protections there is unwise.
>
> I'm not saying it is defined on all the necessary endpoints already, but
> let's be deliberate on which ones get it.
>
> On Thu, Feb 10, 2022, 01:19 Dmitry Telegin  40backbase@dmarc.ietf.org> wrote:
>
>> Could we perhaps be a little bit more specific on the relationship
>> between DPoP and OAuth 2.0 Token Revocation (RFC 7009)?
>>
>> I believe that if we constrain *some* token lifecycle events (issuance,
>> refresh), we should constrain *all*, revocation included (please correct
>> me if I'm wrong).
>>
>> There seem to be no direct attack vectors here, but indirect ones might
>> be possible. For example, by revoking an exfiltrated refresh token, thus
>> killing the session, the attacker could force the user to reauthenticate at
>> the moment the attacker would be ready to steal credentials.
>>
>> Dmitry
>> Backbase / Keycloak
>> ___
>> 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] Authorization code reuse and OAuth 2.1

[Filip Skokan]

The Slide discussed in the interim proposed dropping multiple measures, not
just the single-use authorization code.

- #65 - single use, discussed in this thread

Normatively defining when and how to allow re-use is a nightmare.


> The authorization server MUST generate idempotent tokens from an
> authorization code. Additionally, authorization codes MUST be short lived,
> and if an authorization code is used outside the lifetime or with an
> invalid PKCE verifier, the authorization server MUST deny the request.
>

This sounds very simple in writing but the same cannot be said about an
implementation. If the same token must be issued from subsequent uses of
the same authorization code, albeit if PKCE verifier is the same this would
imply that the AS needs to store an issued opaque token value referenced
from the authorization code, likewise for a JWT Access Token it must store
its value because of random jtis, or non-deterministic algorithms, that are
at play - otherwise how would "the same" token be issued? One can argue
that its okay to issue a different value token so long as its jti and PoP
cnf, and other claims are the same but that's short-sighted given that
revocation schemes may be based either on jti values or digests of the
token value, the AS cannot know which it is for the client / RS. Then
there's the interplay with DPoP (or future PoP schemes) where it would need
to be the same proof that was passed previously, again having to store it.

Moving from a MUST to a SHOULD with concepts such as "idempotent tokens"
spelled out in security considerations for when the AS decides not to
enforce one-time usage sounds feasible. Leaving it as a MUST, which is, in
light of the above complexity, a way simpler measure is also fine.

But let's not also forget there are two other points on that slide that

- #82 - Should authorization codes be invalidated if used unsuccessfully
- #54 - redirect_uri in token request

It sounds like they should be separated discussions @Aaron Parecki
. I'd recommend approaching them separately, not under a
single umbrella. Including these changes in -05 may be premature.

Best,
*Filip Skokan*


On Sat, 16 Oct 2021 at 10:12, Warren Parad  wrote:

> I also support Annabelle's suggestion of idempotent tokens. That would
> prevent the relaxation and focus on solving the problem scenario, without
> opening the door for potential attacks:
>
>> The authorization server MUST generate idempotent tokens from an
>> authorization code. Additionally, authorization codes MUST be short lived,
>> and if an authorization code is used outside the lifetime or with an
>> invalid PKCE verifier, the authorization server MUST deny the request.
>>
>
> I'm actually a bit weary of adding the part:
>
>> and SHOULD revoke all tokens previously issued based on authorization
>> code.
>
>
> There are so many times when doing development that someone would have
> taken an authorization code and tested it. Causing problems with the user
> agent that correctly used the auth code doesn't make sense to me. We
> already have a way of denying future tokens, and there is no evidence that
> the original token generation was compromised. If it was, then the attacker
> should have the access token (and potentially refresh token) which is far
> worse.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Sat, Oct 16, 2021 at 8:20 AM Neil Madden 
> wrote:
>
>> Are we saying that network connections have got significantly worse over
>> the last decade that we need to drop a security feature? I have so far
>> never heard anyone complain about the one-time use nature of authorization
>> codes. (I hear it about refresh tokens, but not auth codes). I don’t think
>> that OAuth 2.1 is an appropriate place to be relaxing any security
>> conditions.
>>
>> — Neil
>>
>> On 16 Oct 2021, at 03:01, Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>> 
>> I see the formal reasoning behind the suggestion, and I agree it would be
>> the safest behavior, but I don’t think it’s a realistic expectation. The
>> end user experience necessary for obtaining a new authorization code (with
>> possible future complications if browsers start to see excess redirects
>> toward a domain as evidence of tracking and strip parameters out) and the
>> complexity of moving execution back from code to front channel as error
>> management IMO makes it very unlikely that developers would pursue that
>> approach (which I have never seen implemented in the wild).
>>
>> On Fri, Oct 15, 2021 at 16:42 Mike Jones > 40microsof

Re: [OAUTH-WG] DPoP 03 - access_token as a POST parameter + Bearer/DPoP multi-scheme protected resources

[Filip Skokan]

Hello Dmitry,

I believe it is the case that DPoP only defines Authorization Header use.
Sending a DPoP type access token in a POST body parameter or query string
is, unlike with Bearer, not defined.

Best,
*Filip*


On Fri, 3 Sept 2021 at 01:21, Dmitry Telegin  wrote:

> Hi,
>
> The Bearer Token Usage RFC allows
>  for an access
> token to be passed as a body form-encoded parameter. With DPoP, this leads
> to ambiguity if a protected resource supports DPoP and Bearer schemes
> simultaneously, as per DPoP Section 7.2.
>
> The ambiguity arises from the inability to derive the authentication
> scheme used with the token, as opposed to "Authorization: XXX" header use.
> In its turn, the scheme would be needed for the protected resource to form
> the correct "WWW-Authenticate" challenge in the case of invalid token. (For
> a protected resource supporting Bearer and DPoP in parallel, the challenge
> would include both schemes.)
>
> Example challenge for the Bearer scheme:
>
> 401 Unauthorized
> WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP
> realm="foo", algs="ES256"
>
> Example challenge for the DPoP scheme:
>
> 401 Unauthorized
> WWW-Authenticate: Bearer realm="foo", DPoP realm="foo",
> error="invalid_token", algs="ES256"
>
> (In a nutshell, we need to know which scheme in the challenge should be
> marked as failed, and thus include the "error=..." attribute.)
>
> Additionally, the knowledge of the scheme would be needed to properly
> prevent the downgraded usage of DPoP-bound tokens, as per DPoP Section 7.2.
>
> This might seem an insignificant edge case, but there is an important
> instance of such a protected resource, namely OIDC UserInfo endpoint. As
> per OpenID Connect Core, 5.3 UserInfo Endpoint
> :
>
> The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns
>> Claims about the authenticated End-User.
>> The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST
>> methods defined in RFC 2616 [RFC2616].
>> The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token
>> Usage [RFC6750].
>>
>
> The problem is that UserInfo is not bound to any client, and DPoP support
> would be normally enabled/disabled on a per client basis (rather than
> per-realm or per-server). Therefore, UserInfo won't be able to make a
> decision upon the default authentication scheme until it parses the token
> and resolves a client that it was issued for; it might not be able to do
> this at all in the case of invalid token. Hence, UserInfo must support (and
> advertise via WWW-Authenticate) both Bearer and DPoP schemes
> simultaneously, and to deduce which one has been used with the POST request
> containing access_token as a form-encoded param.
>
> I see the following possible approaches:
> - require that hybrid Bearer/DPoP protected resources honor a variant of
> the POST parameter, like e.g. "access_token+dpop=...", or
> - restrict the use of access_token POST param and require that
> "Authorization: XXX" header be always used with DPoP.
>
> What do you think?
> 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] RAR WGLC comment

[Filip Skokan]

I support such change.

Odesláno z iPhonu

> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
> :
> 
> 
> Hi Brian,
> 
> the idea was to use resource indicators as convenient short cut to support 
> audience restricted access tokens. However, I agree this can be achieved by 
> specifying authorization details in the token request as well.
> 
> So I‘m fine with dropping resource indicators for RAR at all. This means RAR 
> on one hand and scopes + resource indicators on the other hand are clearly 
> decoupled and independent.
> 
> best regards,
> Torsten.
> 
>>> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
>>> :
>>> 
>> 
>> In my reading and understanding of the text and intent, the content and 
>> meaning of a particular authorization details object are fully governed by 
>> its "type". And while the draft provides a set of common data elements 
>> intended to be usable across different types (locations, actions, datatypes, 
>> identifier, privileges) a specific type is free to define whatever suits its 
>> needs. A type definition may or may not involve those common elements and 
>> could even use the same name(s) with different meaning or structure. 
>> 
>> So, while I understand the motivation behind the RFC8707 resource parameter 
>> being usable in a token request to make the AS filter, the included 
>> authorization details of the resultant token based on the "locations" 
>> element[1], I'm a bit concerned about a layering problem here. The 
>> authorization details objects of the grant might not contain a "locations" 
>> element or might have one with a different meaning or structure.  
>> 
>> The draft also describes using the authorization_details token request 
>> parameter to specify the authorization details a client wants the AS to 
>> assign to a particular access token[2]. So the problematic resource 
>> parameter behaviour is also kind of redundant. I think maybe it should be 
>> removed.
>> 
>> [*] described in 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and 
>> mentioned at 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and 
>> in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1
>> 
>> [2] 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
>> 
>> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=162464483100&usg=AOvVaw1Ol8hiDotFufYe9jQCTi1m
> ___
> 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] TMI BFF - html meta tags over/alternative to discovery

[Filip Skokan]

Hello Vittorio, Brian, everyone

This is a followup to my feedback in the TMI BFF interim meeting on April
26th where I mentioned I'd bring this to the list for discussion.

I proposed an alternative to using fixed endpoint locations and/or
discovery. HTML  Tags <https://www.w3schools.com/tags/tag_meta.asp>.

These would be in the returned page HTML's head tag, e.g.


> 


The javascript SDK handing TMI BFF would know to look for these defined
meta tags to source the location of the different endpoints. I think this
could be the primary place an SDK would look at as it doesn't require any
upfront external requests.

For the SDK this is as simple as

var bffTokenPath =
> document.querySelector('meta[name="oauth-bff-token"]').content;


If this was the only mechanism defined by the document (to be bashed) I
think it can save the group a lot of time defining a client discovery
document which would be otherwise needed. If discovery as an alternative
solution is indeed inevitable, it can be a second in line mechanism the
javascript SDK would know to use.

As discussed in the interim, a well known set of endpoints (or even a
single root client discovery document) might not always be available for
control to the webpage depending on where and how it is hosted, on the
other hand the HTML it serves always, I hope, is.

Best,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt

[Filip Skokan]

I would support that too but only if the way it's calculated would get aligned 
as well. If it remains being a fixed sha256 of the whole token rather than what 
at_hash does, using a new claim makes sense. 

Odesláno z iPhonu

> 9. 4. 2021 v 5:38, Mike Jones :
> 
> 
> I had expected that we would use the existing member name “at_hash” for the 
> access token hash value, rather than the new name “ath”, since there’s 
> already precedent for using it.  Could we change to the standard name for 
> this when we publish the next version?
>  
>   Thanks,
>   -- Mike
>  
> From: OAuth  On Behalf Of Brian Campbell
> Sent: Wednesday, April 7, 2021 1:30 PM
> To: oauth 
> Subject: [OAUTH-WG] Fwd: New Version Notification for 
> draft-ietf-oauth-dpop-03.txt
>  
> A new revision of DPoP has been published. The doc history snippet is copied 
> below. The main change here is the addition of an access token hash claim.
> 
>-03
> 
>*  Add an access token hash ("ath") claim to the DPoP proof when used
>   in conjunction with the presentation of an access token for
>   protected resource access
> 
>*  add Untrusted Code in the Client Context section to security
>   considerations
> 
>*  Editorial updates and fixes
>  
> -- Forwarded message -
> From: 
> Date: Wed, Apr 7, 2021 at 2:16 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt
> 
> 
> A new version of I-D, draft-ietf-oauth-dpop-03.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
> 
> Name:   draft-ietf-oauth-dpop
> Revision:   03
> Title:  OAuth 2.0 Demonstrating Proof-of-Possession at the 
> Application Layer (DPoP)
> Document date:  2021-04-07
> Group:  oauth
> Pages:  32
> URL:https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Html:   https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
> Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03
> 
> Abstract:
>This document describes a mechanism for sender-constraining OAuth 2.0
>tokens via a proof-of-possession mechanism on the application level.
>This mechanism allows for the detection of replay attacks with access
>and refresh tokens.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> 
> 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

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

[Filip Skokan]

The Node.js open source openid-client project (
https://github.com/panva/node-openid-client) likewise implements PAR.

Best,
*Filip*


On Thu, 25 Mar 2021 at 10:40, Filip Skokan  wrote:

> Hello Hannes,
>
> the Node.js open source oidc-provider project (
> https://github.com/panva/node-oidc-provider) implements PAR behind a
> feature flag
>
> Best,
> *Filip Skokan*
>
>
> On Wed, 24 Mar 2021 at 20:54, Hannes Tschofenig 
> wrote:
>
>> Hi all,
>>
>>
>>
>> I am working on the shepherd writeup and I need information about the
>> implementation status of this specification.
>>
>>
>>
>> Can you share whether you are implementing, or planning to implement this
>> specification? If there is open source, please drop a link to the mailing
>> list. If you implement it in your product, please let us know as well.
>>
>>
>>
>> This information helps the steering committee to judge the quality and
>> maturity of the work.
>>
>>
>>
>> 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
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

[Filip Skokan]

Hello Hannes,

the Node.js open source oidc-provider project (
https://github.com/panva/node-oidc-provider) implements PAR behind a
feature flag

Best,
*Filip Skokan*


On Wed, 24 Mar 2021 at 20:54, Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> I am working on the shepherd writeup and I need information about the
> implementation status of this specification.
>
>
>
> Can you share whether you are implementing, or planning to implement this
> specification? If there is open source, please drop a link to the mailing
> list. If you implement it in your product, please let us know as well.
>
>
>
> This information helps the steering committee to judge the quality and
> maturity of the work.
>
>
>
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: IPR Confirmation

[Filip Skokan]

Hello Hannes. I am not aware of any IPR related to this document.

Cheers,
Filip

Odesláno z iPhonu

> 24. 3. 2021 v 20:52, Hannes Tschofenig :
> 
> 
> Hi Torsten, Brian, Nat, Dave, Filip,
>  
> I am working on the shepherd writeup for the "OAuth 2.0 Pushed Authorization 
> Requests"  specification.
>  
> One item in the shepherd template requires me to indicate whether each 
> document author has confirmed that any and all appropriate IPR disclosures 
> required for full conformance with the provisions of BCP 78 and BCP 79 have 
> already been filed.
>  
> Could you please confirm?
>  
> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Filip Skokan]

I don't share the same sentiment about at_hash being a pain, we already have 
the tools on the server. And browser side it's a matter of 15loc using 
webcrypto api since, well, the JWS algorithm support there is limited to the 
simple ones ending with the bitsize needed anyway. 

Nevertheless if we're saying sha256 of the key thumbprint is fine i don't see 
why we wouldn't be able to do the same for new AT hash property (no longer 
called at_hash i assume).

But if XSS is game over, let's not bother with trying to patch one particular 
scenario with a hash.

- Filip

Odesláno z iPhonu

> 19. 12. 2020 v 7:00, Vladimir Dzhuvinov :
> 
> 
> Thank you Justin for this honest account of your experience with DPoP.
> 
> To at_hash or not is maybe not solved yet, but at least it's clear there's 
> little enthusiasm about the OIDC style at_hash :)
> 
> Vladimir
> 
> On 15/12/2020 18:40, Justin Richer wrote:
>> I went and implemented this proposal of including a token hash in both an AS 
>> (java) and client (javascript) on a system that was already using DPoP and 
>> OpenID Connect. What I did there was just use the existing code we had on 
>> the AS-side to calculate the “at_hash” in the ID Token from OIDC, which I 
>> also used to verify on the token-accepting portions. I had to implement the 
>> function on the client side, but that was only a couple lines using a crypto 
>> library to do the heavy hash lift.
>> 
>> The most annoying part is dealing with the hash variability in the OIDC 
>> method. As Brian points out, this isn’t particularly robust, and it depends 
>> on the wrapper being JOSE. That’s not a huge deal because DPoP uses JOSE for 
>> its wrapper, but it’s still extra code to deal with — to the point where I 
>> just hardcoded the hash algorithm in my test so that I didn’t have to put 
>> together the switch case over the algorithm. 
>> 
>> So in at least my own experience, the addition is minimal on both client and 
>> server, and whatever we would decide for the hash algorithm would be simple 
>> enough to manage. I have a slight preference for just picking something like 
>> SHA256 and calling it a day (and defining other hashes in the future when 
>> SHA256 is broken), but that’s not a hill I care to die on.
>> 
>>  — Justin
>> 
>>> On Dec 14, 2020, at 4:27 PM, Brian Campbell 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov 
>>>  wrote:
 If the current DPoP has code complexity "X", the relative additional 
 complexity to include access token hashes doesn't seem like very much. An 
 app choosing DPoP means accepting the code complexity that comes with 
 dealing with keys, composing the signing inputs for the proofs, signing, 
 the necessary changes to the token and RS requests. On the other hand, for 
 some people that additional access token hash may become the straw that 
 breaks the camel's back, causing them to quit their jobs developing web 
 apps and never look back :)
 
>>> Yeah, the relative additional complexity to include an access token hash 
>>> maybe isn't too much but it's also not not nothing. It's a different kind 
>>> of operation than the other things you listed (yes, I know there's a hash 
>>> as part of the signing but it's abstracted away from the developer in most 
>>> cases) and something that can be quite difficult to troubleshoot when 
>>> different parties arrive at different hash values. Hence my lack of 
>>> conviction on this one way or the other. 
>>>  
 
 Have you thought about letting deployments decide about the access token 
 hash? To say look, there is also the option to bind an access token to the 
 DPoP proof, the security benefits can be such an such, and this is how it 
 can be done.
 
 What I don't like about that proposal: 
 
 It will complicate the spec
 
 The current spec doesn't require implementers / deployments to make any 
 decisions, apart from adopt / not DPoP (okay, also choose a JWS alg) - 
 which is actually a great feature to have
>>> 
>>> I also don't like it for basically the same reasons. I've definitely aimed 
>>> to keep it simple from that perspective of not having a lot of optionality 
>>> or switches. It is a nice feature to have, when possible. 
>>> 
>>>  
 Vladimir
 
 
 
 On 12/12/2020 01:58, Brian Campbell wrote:
> Any type of client could use DPoP and (presumably) benefit from 
> sender-constrained access tokens. So yeah, adding complexity specifically 
> for browser-based applications (that only mitigates one variation of the 
> attacks possible with XSS anyway)  has 'cost' impact to those clients as 
> well. And should be considered in the cost/benefit. Including the AT hash 
> isn't terribly complicated but it's not trivial either. I'm honestly 
> still unsure but am leaning towards it not being worth adding. 
> 
> On Fri, Dec 11, 2020 at 2:14 AM Philippe

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Filip Skokan]

>
> I'm failing to understand why binding the proof to the access token
> ensures freshness of the proof.


Because when access tokens issued to public browser based clients have a
short duration you need continued access to the private key to issue new
proofs. When I exfiltrate the RT and pre-generate tons of proofs while the
user is active on the page through XSS I can then use the RT and my
prepared proofs to talk to the AS to keep on refreshing the AT and use it
against the RS. When the value of the token is part of the proof, i cannot
pre-generate them for future issued access tokens. Short `iat` based
windows don't help here.

S pozdravem,
*Filip Skokan*


On Thu, 3 Dec 2020 at 12:59, Torsten Lodderstedt 
wrote:

> Hi,
>
> I'm failing to understand why binding the proof to the access token
> ensures freshness of the proof. I would rather think if the client is
> forced to create proofs with a reasonable short lifetime, chances for
> replay could be reduced.
>
> Beside that as far as I remember the primary replay counter measure is the
> inclusion of the endpoint URL and HTTP method in the proof, since it
> reduces the attack surface to a particular URL. So in the context of
> freshness, we are talking about using the same proof with the same URL
> again.
>
> best regards,
> Torsten.
>
> > Am 03.12.2020 um 10:20 schrieb Filip Skokan :
> >
> > Hi Brian, everyone,
> >
> > While the attack vector allows direct use, there is the option where a
> smarter attacker will not abuse the gained artifacts straight away. Think
> public client browser scenario with the non-extractable private key stored
> in IndexedDB (the only place to persist them really), they wouldn't use the
> tokens but instead, exfiltrate them, together with a bunch of pre-generated
> DPoP proofs. They'll get the refresh token and a bunch of DPoP proofs for
> both the RS and AS. With those they'll be able to get a fresh AT and use it
> with pre-generated Proofs after the end-user leaves the site. No available
> protection (e.g. RT already rotated) will be able to kick in until the
> end-user opens the page again.
> >
> > OTOH with a hash of the AT in the Proof only direct use remains.
> >
> > If what I describe above is something we don't want to deal with because
> of direct use already allowing access to protected resources, it's
> sufficiently okay as is (option #1). However, if this scenario, one
> allowing prolonged access to protected resources, is not acceptable, it's
> option #2.
> >
> > Ad #2a vs #2b vs #2c. My pre-emptive answer is #2a, simply because we
> already have the tools needed to generate and validate these hashes. But
> further thinking about it, it would feel awkward if this JWS algorithm
> driven at_hash digest selection wouldn't get stretched to the
> confirmations, when this are placed in a JWT access token, cool - we can do
> that, but when these are put in a basic token introspection response it's
> unfortunately not an option. So, #2b (just use sha-256 just like the
> confirmations do).
> >
> > Best,
> > Filip
> >
> >
> > On Wed, 2 Dec 2020 at 21:50, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> > There were a few items discussed somewhat during the recent interim that
> I committed to bringing back to the list. The slide below (also available
> as slide #17 from the interim presentation) is the first one of them, which
> is difficult to summarize but kinda boils down to how much assurance there
> is that the DPoP proof was 'freshly' created and that can dovetail into the
> question of whether the token is covered by the signature of the proof.
> > There are many directions a "resolution" here could go but my sense of
> the room during the meeting was that the contending options were:
> >   •  It's sufficiently okay as it is
> >   •  Include a hash of the access token in the DPoP proof (when an
> access token is present)
> >
> > Going with #2 would mean the draft would also have to define how the
> hashing is done and deal with or at least speak to algorithm agility.
> Options (that I can think of) include:
> >   • 2a) Use the at_hash claim defined in OIDC core
> https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using
> something that already exists is appealing. But its hash alg selection
> routine can be a bit of a pain. And the algorithm agility based on the
> signature that it's supposed to provide hasn't worked out as well as hoped
> in practice for "new" JWS signatures
> https://bitbucket.org/openid/connect/issues/1125/_hash-algorithm-for-eddsa-id-tokens
> >

Re: [OAUTH-WG] PAR error for redirect URI?

[Filip Skokan]

To be clear, I'm not advocating to skip the registration, just wanted to
mention a potential concern. If the process allows it and it will not
introduce more delay to publication, I think we should go ahead and
register the error code.

Best,
*Filip*


On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt 
wrote:

>
>
> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
> >
> > There are several documents already mentioning "invalid_redirect_uri" as
> an error code, specifically RFC7519 and OpenID Connect Dynamic Client
> Registration 1.0. But these don't register it in the IANA OAuth Extensions
> Error Registry, presumably because they're neither for the authorization or
> token endpoints.
> >
> > While I think it'd be great if we had this error code registered, I also
> worry that its registration could confuse implementers to think it's okay
> to return it from the authorization endpoint.
>
> I understand your concern. On the other hand, registering the error code
> is in my opinion the proper way forward. The registration is scoped to a
> usage location, should be pushed authorization endpoint then, and RFC6749
> gives clear guidance on how to treat errors related to the redirect URI at
> the authorization endpoint.
>
> "If the request fails due to a missing, invalid, or mismatching
>redirection URI, … authorization server ... MUST NOT automatically
> redirect the user-agent to the
>invalid redirection URI."
>
> I think if an implementor ignores this, it will ignore any advise.
>
> best regards,
> Torsten.
>
> >
> > Best,
> > Filip
> >
> >
> > On Thu, 3 Dec 2020 at 00:29, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> > During the course of a recent OIDF FAPI WG discussion (the FAPI profiles
> use PAR for authz requests) on this issue it was noted that there's no
> specific error code for problems with the redirect_uri (the example in
> https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3
> even shows a general error code with mention of the redirect_uri not being
> valid in the error description). Some folks on that call thought it would
> be worthwhile to have a more specific error code for an invalid
> redirect_uri and I reluctantly took an action item to raise the issue here.
> At the time I'd forgotten that PAR had already passed WGLC. But it's been
> sitting idle while awaiting the shepherd writeup since mid September so
> it's maybe realistic to think the window for a small change is still open.
> >
> > Presumably nothing like an "invalid_redirect_uri" error code was defined
> in RFC 6749 because that class of errors could not be returned to the
> client via redirection. But the data flow in PAR would allow for a
> "invalid_redirect_uri" so it's not an unreasonable thing to do.
> >
> > As I write this message, however, I'm not personally convinced that it's
> worth making a change to PAR at this point. But I did say I'd bring the
> question up in the WG list and I'm just trying to be true to my word. So
> here it is. Please weigh in, if you have opinions on the matter.
> >
> >
> >
> > 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=160759062900&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

[Filip Skokan]

Please note that this simple validation (in combination with web
application enforcing http(s) schemes) removes the need to implement and
maintain a blocklist of potentially malicious schemes such as
`javascript:/`, `vbscript:/`, and `data:/`.

More details:
https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/

Best,
*Filip*


On Thu, 3 Dec 2020 at 10:59, Filip Skokan  wrote:

> Hello everyone,
>
> Both RFC 8252 <https://tools.ietf.org/html/rfc8252#section-7.1> and OAuth
> 2.1 draft
> <https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-10.3.1>
> state that (paraphrasing)
>
> Apps MUST use a URI scheme based on a domain name under their control,
>> expressed in reverse order, as recommended by Section 3.8 of [RFC7595] for
>> private-use URI schemes. e.g. com.example.app:/
>
>
> My question is, is the AS right to reject client registrations that do not
> follow this specific requirement, to e.g. reject myapp:/oauth2/example-issuer
> on the account of it not being neither claimed https scheme, an http: +
> loopback interface, nor having a "." (dot) character suggesting it is a
> reverse domain scheme?
>
> Best,
> *Filip*
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

[Filip Skokan]

Hello everyone,

Both RFC 8252  and OAuth
2.1 draft
 state
that (paraphrasing)

Apps MUST use a URI scheme based on a domain name under their control,
> expressed in reverse order, as recommended by Section 3.8 of [RFC7595] for
> private-use URI schemes. e.g. com.example.app:/


My question is, is the AS right to reject client registrations that do not
follow this specific requirement, to e.g. reject myapp:/oauth2/example-issuer
on the account of it not being neither claimed https scheme, an http: +
loopback interface, nor having a "." (dot) character suggesting it is a
reverse domain scheme?

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR error for redirect URI?

[Filip Skokan]

There are several documents already mentioning "invalid_redirect_uri" as an
error code, specifically RFC7519 and OpenID Connect Dynamic Client
Registration 1.0. But these don't register it in the IANA OAuth Extensions
Error Registry, presumably because they're neither for the authorization or
token endpoints.

While I think it'd be great if we had this error code registered, I also
worry that its registration could confuse implementers to think it's okay
to return it from the authorization endpoint.

Best,
*Filip*


On Thu, 3 Dec 2020 at 00:29, Brian Campbell  wrote:

> During the course of a recent OIDF FAPI WG discussion (the FAPI profiles
> use PAR for authz requests) on this issue
> 
> it was noted that there's no specific error code for problems with the
> redirect_uri (the example in
> https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3
> even shows a general error code with mention of the redirect_uri not being
> valid in the error description). Some folks on that call thought it would
> be worthwhile to have a more specific error code for an invalid
> redirect_uri and I reluctantly took an action item to raise the issue here.
> At the time I'd forgotten that PAR had already passed WGLC. But it's been
> sitting idle while awaiting the shepherd writeup since mid September so
> it's maybe realistic to think the window for a small change is still open.
>
> Presumably nothing like an "invalid_redirect_uri" error code was defined
> in RFC 6749 because that class of errors could not be returned to the
> client via redirection. But the data flow in PAR would allow for a
> "invalid_redirect_uri" so it's not an unreasonable thing to do.
>
> As I write this message, however, I'm not personally convinced that it's
> worth making a change to PAR at this point. But I did say I'd bring the
> question up in the WG list and I'm just trying to be true to my word. So
> here it is. Please weigh in, if you have opinions on the matter.
>
>
>
> *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

Re: [OAUTH-WG] Shepherd writeup for the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens -- Information about Implementations

[Filip Skokan]

Hi Hannes, 

Node.js project oidc-provider (https://github.com/panva/node-oidc-provider) has 
an option to issue Access Tokens conform to this profile. 

Best, 
Filip

Odesláno z iPhonu

> 17. 9. 2020 v 14:56, Hannes Tschofenig :
> 
> Hi Vittorio, Hi all,
> 
> I am working on the shepherd writeup for  
> and you can find the latest version here:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JWT-Profile-for-AccessTokens.txt
> 
> I am in need for information about implementations that are conformant to 
> this specification. This information would be listed in this write-up, as 
> background information to the IESG.
> 
> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Filip Skokan]

+1 for keeping it simple. The design itself promotes unique-per-instance
keys, not pre-registration.

S pozdravem,
*Filip Skokan*


On Wed, 9 Sep 2020 at 00:46, Brian Campbell  wrote:

> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means, which makes the "jwk" header in the
> DPoP proof not strictly necessary. And while omitting the key in such cases
> would reduce the size of some messages (the DPoP proof anyway), such
> optionality would add complexity to implementations and deployments (and
> that kind of complexity can and often does degrade interoperability and
> even security). How, for example, would a client know if the access token
> includes the public key and thus whether or not to include the key with the
> proof? Sure the access token could always include the key (rather than
> thumbprint) but then there's the question of how to get the key to the AS.
> As well as the stated desire to utilize the same DPoP Proof structure for
> requests to both the AS and RS. There will be some clients that have public
> key(s) registered and some that won't (maybe a lot that won't as a driving
> use case for many for this is key binding access and refresh tokens for
> public clients). The protocol defined by the draft needs to account for
> both.
>
> Ultimately there are a number of different ways the necessary data could
> flow through the various protocol elements. And there are some tradeoffs
> with different approaches and/or trying to accommodate variations under one
> approach. The approach the draft has taken thus far is to prioritize
> consistency and simplicity as much as is possible. And that ethos has led
> to how it's currently defined, which is to always include the key in the
> proof and bind to a hash of the key in the access token.
>
>
> On Tue, Sep 8, 2020 at 3:29 AM  wrote:
>
>> Hi all,
>>
>> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
>> REQUIRED. However, there are some cases where "jwk" is not necessary in
>> theory.
>>
>> For example, consider a case where the client is registered with the
>> Authorization Server, and its one and only public key is also registered
>> with
>> the AS. In that case, when the AS receives a request on Token endpoint,
>> it can
>> just use the public key registered for the client to verify the DPoP
>> Proof.
>> There is no need to send the public key in DPoP Proof.
>>
>> The same goes for requests to the Resource Server, if the AS and RS share
>> the
>> storage for clients' public keys. Things are a little difficult if the AS
>> and RS
>> are separate. Probably the Access Token or its introspection result have
>> to
>> include the public key (instead of its thumbprint as described in section
>> 7).
>>
>> If the client registers multiple keys with the AS, it needs to specify
>> which key
>> it uses to sign the DPoP Proof. However, there is still no absolute need
>> to send
>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>> parameter to specify the key.
>>
>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
>> but I'm
>> not sure what happened to the discussion. There was also a comment on the
>> latest
>> draft about the "jwk" header parameter [*2]. I agree with using the same
>> DPoP
>> Proof structure for requests to AS and RS, but I think there are some
>> cases
>> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would
>> allow
>> those cases to reduce some messaging overhead.
>>
>> I'd like to hear your opinions about it.
>>
>>
>> [*1]:
>> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
>> [*2]:
>> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>>
>>
>> Best regards,
>> Toshio Ito
>>
>> -
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>>
>> ___
>> 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

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

[Filip Skokan]

Hi Mike, Nat,

I thought we would go as far as making these normative requirements

   - if the Request Object includes a sub claim with the value of the
   client_id the AS MUST reject the request
   - if the Request Object is explicitly typed (typ) its value MUST be ...

First rejects client assertions to be passed as Request Objects. Second
rejects all future typed JWT profiles from being used as Request Objects
without worrying about the claims they may or may not contain.

Or is that breaking?

S pozdravem,
*Filip Skokan*


On Fri, 14 Aug 2020 at 00:59, Mike Jones  wrote:

> At Nat's request, I've created a pull request addressing Cross-JWT
> Confusion security considerations.  It addresses both Brian's comment and
> the IESG comments about explicit typing.  See the full PR at
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10.  See the source
> diffs at
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.
> Please review!
>
> This is only the first commit, albeit, one that addresses some of the must
> substantive issues.  More commits will follow addressing additional IESG
> comments.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Benjamin Kaduk
> Sent: Thursday, August 13, 2020 2:59 PM
> To: Brian Campbell 
> Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; The IESG <
> i...@ietf.org>; oauth 
> Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on
> draft-ietf-oauth-jwsreq-26: (with COMMENT)
>
> Oops, that's my bad.  Thanks for the correction -- I've linked to your
> message in the datatracker (but didn't bother to have the datatracker send
> a third copy of my updated-again ballot position).
>
> -Ben
>
> On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> > While some discussion of why explicit typing was not used might be
> > useful to have, that thread started with a request for security
> > considerations prohibiting use of the "sub" with a client ID value.
> > Because such a request JWT could be repurposed for JWT client
> > authentication. And explicit typing wouldn't help in that situation.
> >
> > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <
> > nore...@ietf.org> wrote:
> >
> > >
> > > 
> > > --
> > > COMMENT:
> > > 
> > > --
> > >
> > > [updated to note that, per
> > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0
> > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit
> > > typing is not used would be in order]
> > >
> > >
> >
> > --
> > _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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

[Filip Skokan]

Denis, PAR is arguably not the document that should retrofit OAuth 2.0 with
a full blown Privacy Consideration section. Now, do you find the draft
introduces anything new from a privacy perspective? Does the AS get
anything other than what it already does via the authorization_endpoint
today?

For the record i'm not arguing OAuth 2.0 should be without privacy
considerations, i'm just saying - if it did, or rather, regardless if it
does or doesn't - PAR does not expand on those in any way.

S pozdravem,
*Filip Skokan*


On Tue, 11 Aug 2020 at 17:17, Denis  wrote:

> Hi Filip,
>
> I don’t think there’s anything new introduced in PAR that would alter
> existing status quo of privacy consiserations.
> As such if privacy consideration was to be added for completeness it
> should be along the lines of “this document
> does not expand on or otherwise alter the privacy considerations” or
> “there are no new privacy considerations introduced by this document”.
>
> OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was
> issued before RFC 6973 (Privacy Considerations for Internet Protocols)
> existed.
>
> I browsed through the RFCs published by this WG and the guidance provided
> in RFC 6973 has not really be used and followed.
>
> So adding no text to nearly zero text will not help that much. I believe
> that a Privacy considerations section will be added to the OAuth 2.1 draft.
> While doing that exercise, a shorter version of it could be included in
> PAR.
>
> Hereafter is my detailed analysis:
>
> RFC 6973 (Privacy Considerations for Internet Protocols) has been issued
> in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy
> Considerations section.
>
> This is the case for :
> -  RFC 6749 (The OAuth 2.0 Authorization Framework) -  RFC
> 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) -
> RFC 6755 (An IETF URN Sub-Namespace for OAuth) -  RFC 6819 (OAuth
> 2.0 Threat Model and Security Considerations) For RFCs issued after RFC
> 6973, six of them don't have a have a Privacy Considerations section. This
> is the case for:
> -  *RFC 7009 *(OAuth 2.0 Token Revocation) - *  RFC 7519*
> updated by RFC 8725 (JSON Web Token Best Current Practices) -  *RFC
> 7636* (Proof Key for Code Exchange by OAuth Public Clients) -  *RFC
> 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations
> section -  *RFC 8414 *(OAuth 2.0 Authorization Server Metadata) -
> *RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a
> Privacy Considerations section. They are enumerated below, with a copy of
> these sections. -  *RFC 7521* (Assertion Framework for OAuth 2.0
> Client Authentication and Authorization Grants) 8.4.  Privacy
> Considerations An assertion may contain privacy-sensitive information
> and, to prevent disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as TLS.  In
> cases where it is desirable to prevent disclosure of
> certain information to the client, the assertion (or portions of it)
> should be encrypted to the authorization server. Deployments should
> determine the minimum amount of information necessary to complete the
> exchange and include only
> such information in the assertion.  In some cases, the Subject identifier
> can be a value representing an anonymous or pseudonymous
> user, as described in Section 6.3.1. -  *RFC 7522* (Security
> Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7. Privacy Considerations
>
> A SAML Assertion may contain privacy-sensitive information and, to prevent 
> disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as Transport Layer 
> Security (TLS).  In cases where it is desirable to prevent
> disclosure of certain information to the client, the Subject and/or 
> individual attributes of a SAML Assertion should be encrypted to the
> authorization server.
>
> Deployments should determine the minimum amount of information necessary to 
> complete the exchange and include only that information
> in an Assertion (typically by limiting what information is included in an 
>  or by omitting it altogether).  In some cases,
> the Subject can be a value representing an anonymous or pseudonymous user, as 
> described in Section 6.3.1 
> <https://tools.ietf.org/html/rfc7522#section-6.3.1> of the OAuth Assertion 
> Framework [RFC7521 <https://tools.ietf.org/html/rfc7521>].
>
> -  *RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7.  Privacy Conside

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

[Filip Skokan]

I don’t think there’s anything new introduced in PAR that would alter existing 
status quo of privacy consiserations. As such if privacy consideration was to 
be added for completeness it should be along the lines of “this document does 
not expand on or otherwise alter the privacy considerations” or “there are no 
new privacy considerations introduced by this document”. 

Filip

Odesláno z iPhonu

> 10. 8. 2020 v 19:21, Aaron Parecki :
> 
> 
> I agree that there is nothing unique to PAR that would justify adding the 
> privacy considerations mentioned to that draft. I wouldn't oppose adding a 
> privacy considerations section to OAuth 2.1 though.
> 
> Aaron
> 
> 
>> On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt  wrote:
>> In the PAR meeting today, Denis requested there be a privacy considerations 
>> section in PAR. I don't think there is anything specific in PAR that would 
>> change the privacy considerations of OAuth, and am checking if there is WG 
>> interest, and consensus, on including a Privacy Considerations section in 
>> the OAuth 2.1 draft.
>> 
>> /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] ECDH-1PU encryption algorithm

[Filip Skokan]

Hi Neil,

I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how
to go about it tho since JOSE is a concluded WG.

Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider
the need to further maintain/expand the JOSE algorithms as time goes on?

S pozdravem,
*Filip Skokan*


On Mon, 10 Aug 2020 at 10:29, Neil Madden  wrote:

> Thanks Vladimir,
>
> Responses below
>
> > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov 
> wrote:
> >
> > Hi Neil,
> >
> > I definitely like the elegance of the proposed alg for JOSE, it provides
> > something that isn't currently available in the various classes of algs
> > made standard in JOSE.
> >
> > I also wanted to ask what's happening with AES SIV for JOSE, if there's
> > traction / feedback / support there as well?
> >
> > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02
>
> Thanks for bringing this up. I’ve not received much feedback about this
> one, and I haven’t been very good at pushing it. If there is interest then
> I’d certainly be interested in bringing this forward too.
>
> That draft might be a better fit for eg the COSE WG though, which could
> then also register identifiers for JOSE. What do you think?
>
> >
> > Vladimir
> >
> >
> >>> On 05/08/2020 13:01, Neil Madden wrote:
> >> Hi all,
> >> You may remember me from such I-Ds
> >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
> >> proposes adding a new encryption algorithm to JOSE. I’d like to
> >> reserve a bit of time to discuss it at one of the upcoming interim
> >> meetings.
> >> The basic idea is that in many cases in OAuth and OIDC you want to
> >> ensure both confidentiality and authenticity of some token - for
> >> example when transferring an ID token containing PII to the client
> >> through the front channel, or for access tokens intended to be handled
> >> by a specific RS without online token introspection (such as the JWT
> >> access token draft). If you have a shared secret key between the AS
> >> and the client/RS then you can use symmetric authenticated encryption
> >> (alg=dir or alg=A128KW etc). But if you need to use public key
> >> cryptography then currently you are limited to a nested
> >> signed-then-encrypted JOSE structure, which produces much larger token
> >> sizes.
> >> The draft adds a new “public key authenticated encryption” mode based
> >> on ECDH in the NIST standard “one-pass unified” model. The primary
> >> advantage for OAuth usage is that the tokens produced are more compact
> >> compared to signing+encryption (~30% smaller for typical access/ID
> >> token sizes in compact serialization). Performance-wise, it’s roughly
> >> equivalent. I know that size concerns are often a limiting factor in
> >> choosing whether to encrypt tokens, so this should help.
> >> In terms of implementation, it’s essentially just a few extra lines of
> >> code compared to an ECDH-ES implementation. (Some JOSE library APIs
> >> might need an adjustment to accommodate the extra private key needed
> >> for encryption/public key for decryption).
> >> I’ve received a few emails off-list from people interested in using it
> >> for non-OAuth use-cases such as secure messaging applications. I think
> >> these use-cases can be accommodated without significant changes, so I
> >> think the OAuth WG would be a good venue for advancing this.
> >> I’d be interested to hear thoughts and discussion on the list prior to
> >> any discussion at an interim meeting.
> >> — Neil
>
> ___
> 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] OAuth Request JSON Encoding

[Filip Skokan]

Apologies Justin, i read it in a rush. 

But, even more so after your clarification, if the ID means responses are 
unmodified it’s just confusing - as you say - at odds with each other, since 
i’d send in scope as array and get it back as a string from the token response. 

Odesláno z iPhonu

> 13. 7. 2020 v 18:09, Justin Richer :
> 
> The intent was to only affect the request, not the response, though I can 
> see the confusion that would arise in having those be at odds with each 
> other. 
> 
>  — Justin
> 
>>> On Jul 13, 2020, at 11:47 AM, Filip Skokan  wrote:
>>> 
>>> Hello Justin, 
>>> 
>>> Your ID changes both how a client sends a request as well as how the, 
>>> already a json, token response is structured (as far as i can see it 
>>> changes scope from a space separated value to an array). 
>>> 
>>> The response morphing will be confusing to clients.
>>> 
>>> I don’t think there’s much to explore here, apart from 
>>> authorization_details param sent to the token endpoint form encoded i don’t 
>>> find much unnatural about the existing oauth interface. 
>>> 
>>> Filip
>>> 
>>> Odesláno z iPhonu
>>> 
>>> 9. 7. 2020 v 21:29, Justin Richer :
>>> 
>>> 
>>> In the ten years since OAuth started, we’ve seen a huge shift away from 
>>> form encoding to JSON encoding for sending data to a server. And yet, OAuth 
>>> is stuck with form encoding. So I thought, why can’t we change that?
>>> 
>>> I put together a quick proposal for how this would work.
>>> 
>>> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html
>>> 
>>> The basic idea is that you take the map of form inputs and make it into a 
>>> JSON object. For some fields, like scope and authorization_details, you can 
>>> define a JSON-specific encoding to make use of object and array structures 
>>> native to JSON. You also don’t have to url-encode values inside the JSON 
>>> strings. 
>>> 
>>> Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
>>> to be that difficult for either the client or server side of things. At 
>>> worst it seems like it’d be a pretty simple middleware function. 
>>> Functionality can be detected at the AS by the content negotiation in HTTP 
>>> (client sends content-type of JSON), and can be advertised as an option in 
>>> the metadata (or in an OPTIONS call to the token endpoint, to be more 
>>> HTTP-friendly).
>>> 
>>>  — Justin
>>> ___
>>> 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] OAuth Request JSON Encoding

[Filip Skokan]

Hello Justin, 

Your ID changes both how a client sends a request as well as how the, already a 
json, token response is structured (as far as i can see it changes scope from a 
space separated value to an array). 

The response morphing will be confusing to clients.

I don’t think there’s much to explore here, apart from authorization_details 
param sent to the token endpoint form encoded i don’t find much unnatural about 
the existing oauth interface. 

Filip

Odesláno z iPhonu

> 9. 7. 2020 v 21:29, Justin Richer :
> 
> 
> In the ten years since OAuth started, we’ve seen a huge shift away from form 
> encoding to JSON encoding for sending data to a server. And yet, OAuth is 
> stuck with form encoding. So I thought, why can’t we change that?
> 
> I put together a quick proposal for how this would work.
> 
> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html
> 
> The basic idea is that you take the map of form inputs and make it into a 
> JSON object. For some fields, like scope and authorization_details, you can 
> define a JSON-specific encoding to make use of object and array structures 
> native to JSON. You also don’t have to url-encode values inside the JSON 
> strings. 
> 
> Caveat, I haven’t tried implementing this yet, but I think it’s not likely to 
> be that difficult for either the client or server side of things. At worst it 
> seems like it’d be a pretty simple middleware function. Functionality can be 
> detected at the AS by the content negotiation in HTTP (client sends 
> content-type of JSON), and can be advertised as an option in the metadata (or 
> in an OPTIONS call to the token endpoint, to be more HTTP-friendly).
> 
>  — Justin
> ___
> 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] client_id in PAR and JAR

[Filip Skokan]

It already is in the new revision of JAR, PAR will follow it too. 

Technically tho, since authorization requests can also use POST its not 
strictly a query string parameter, it may be contained in the request body too. 
Let’s call it authorization endpoint parameters and leave the “how its 
transferred” mechanism out. 

Odesláno z iPhonu

> 30. 6. 2020 v 10:15, Thiloshon Nagarajah :
> 
> 
> Hi Filip,
> 
> So I'm assuming client_id will be mandated as a query param in PAR as well?
> 
> Regards 
> 
>> On Tue, Jun 30, 2020 at 1:09 PM Filip Skokan  wrote:
>> Hi Thiloshon,
>> 
>> Not quite the way it went down but we have this adressed in a future PAR 
>> draft. 
>> 
>> Thank you ;)
>> 
>> Filip
>> 
>> Odesláno z iPhonu
>> 
>>> 30. 6. 2020 v 9:25, Thiloshon Nagarajah 
>>> :
>>> 
>>> 
>>> Hi All,
>>> 
>>> In OAuth JAR specification, client_id is a required query parameter of 
>>> authorisation call, in both request and request_uri flows 
>>> [https://tools.ietf..org/html/draft-ietf-oauth-jwsreq-23#section-5].
>>> 
>>> But in OAuth PAR specification, which is a complimentary spec to JAR, it is 
>>> specified "Clients are encouraged to use the request URI as the only 
>>> parameter (in the authorisation call) in order to use the integrity and 
>>> authenticity provided by the pushed authorization request." 
>>> [https://tools.ietf.org/html/draft-ietf-oauth-par-01#section-4]
>>> 
>>> Taking into account these both are building upon OAuth spec, which also 
>>> mandates client_id query param in authorisation call, it seems like PAR is 
>>> not compatible with OAuth and JAR specs. 
>>> 
>>> Is this intentional? If it is may I know the rationale behind this 
>>> decision? 
>>> 
>>> Regards,
>>> -- 
>>> Thiloshon Nagarajah
>>> Software Engineer,
>>> Financial Solutions
>>> WSO2
>>> +94774209947
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Thiloshon Nagarajah
> Software Engineer,
> Financial Solutions
> WSO2
> +94774209947
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] client_id in PAR and JAR

[Filip Skokan]

Hi Thiloshon,

Not quite the way it went down but we have this adressed in a future PAR draft. 

Thank you ;)

Filip

Odesláno z iPhonu

> 30. 6. 2020 v 9:25, Thiloshon Nagarajah 
> :
> 
> 
> Hi All,
> 
> In OAuth JAR specification, client_id is a required query parameter of 
> authorisation call, in both request and request_uri flows 
> [https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section-5].
> 
> But in OAuth PAR specification, which is a complimentary spec to JAR, it is 
> specified "Clients are encouraged to use the request URI as the only 
> parameter (in the authorisation call) in order to use the integrity and 
> authenticity provided by the pushed authorization request." 
> [https://tools.ietf.org/html/draft-ietf-oauth-par-01#section-4]
> 
> Taking into account these both are building upon OAuth spec, which also 
> mandates client_id query param in authorisation call, it seems like PAR is 
> not compatible with OAuth and JAR specs. 
> 
> Is this intentional? If it is may I know the rationale behind this decision? 
> 
> Regards,
> -- 
> Thiloshon Nagarajah
> Software Engineer,
> Financial Solutions
> WSO2
> +94774209947
> 
> ___
> 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] OAuth services/libraries wanted for security evaluation...

[Filip Skokan]

Hello Pieter, 

I’m interested for my open source project. 

Filip

Odesláno z iPhonu

> 22. 6. 2020 v 15:51, Pieter Philippaerts :
> 
> 
> Hello everyone,
> 
> As part of a research project, I've created a test suite to test OAuth 2.0 
> implementations and measure how well they implement the various 
> MAY/SHOULD/MUST security recommendations in the OAuth standards. (It also 
> includes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is 
> practically finished and will be made available to the public in a few months.
> 
> I'm currently working on a security analysis of the OAuth2 ecosystem (i.e. 
> I'm using the tool to test various OAuth/OIDC implementations) and I'm still 
> looking for more candidates to test. If you are the author of an OAuth 
> library or if you are running an OAuth service, feel free to contact me to 
> get involved. Apart from my gratitude, I can offer you a free security audit 
> of your product :-)
> 
> Regards,
> Pieter
> 
> 
> 
> ___
> 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] Product Support for RFC8414 well-known URIs

[Filip Skokan]

Preemptive send, sorry. That question was not clear from your text to me. 

When it comes to client’s discovery, at least my software does the following - 
when issuer is passed in it does oidc’s well known (openid-configuration) as a 
suffix and 8414’s well known (oauth-authorization-server) as an infix. 
According to both specs. Whichever returns first gets used as they as far as i 
can tell should be aliases. 

When discovery is performed with a URL that contains the keyword well-known, it 
just fetches that resource directly. 

This way the software is working as intended for conform ASs’ and developers 
can still use the non conform ones by passing the well known location directly.

Odesláno z iPhonu

> 8. 6. 2020 v 11:47, Filip Skokan :
> 
> That question was not clear from your text, you 
> 
> Odesláno z iPhonu
> 
>> 8. 6. 2020 v 11:15, Daniel Fett :
>> 
>> 
>> Hi Filip,
>> 
>> Thanks for your answers!
>> 
>> I'm not quite sure if the wording in my question was clear: My main concern 
>> is the difference between 
>> https://example.com/some/path/.well-known/oauth-authorization-server and 
>> https://example.com/.well-known/oauth-authorization-server/some/path, i.e., 
>> the usage of the well-known URI as a postfix or as an infix. 
>> 
>> Am 08.06.20 um 09:54 schrieb Filip Skokan:
>>> Some products publish both, but they don’t always return the same content, 
>>> eventho as far as i can tell they should be aliases. 
>>> The uri normalization of 8414 is also implemented wrong in some cases, 
>>> since it differs from OIDC as far as issuer path component is concerned.
>> This is where I'm not sure whether all products follow RFC8414 and properly 
>> use the well-known part as an infix.
>>> 
>>> I find it best for AS to have just one or both with the same content, 
>>> client software doing discovery can check both locations. 
>> That would be the safe implementation, but I was wondering if prescribing 
>> this is a good choice for an ecosystem. That would mean that all 
>> authorization servers in the ecosystem would need to implement both 
>> https://example.com/some/path/.well-known/oauth-authorization-server and 
>> https://example.com/.well-known/oauth-authorization-server/some/path. Even 
>> if it is only an alias this could mean a considerable overhead for some 
>> implementations.
>> 
>> -Daniel
>> 
>>> 
>>> Odesláno z iPhonu
>>> 
>>>> 8. 6. 2020 v 9:46, Daniel Fett :
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> RFC8414 says that the URI where the OAuth metadata document is published is
>>>> 
>>>> formed by inserting a well-known URI string into the authorization
>>>>server's issuer identifier between the host component and the path
>>>>component, if any.  By default, the well-known URI string used is
>>>>"/.well-known/oauth-authorization-server".
>>>> 
>>>> I found that some OAuth servers and clients instead follow the convention 
>>>> used by OpenID Connect, where the suffix 
>>>> "/.well-known/openid-configuration" (or 
>>>> "/.well-known/oauth-authorization-server") is appended to the issuer URL.
>>>> 
>>>> Is this a common deviation from the spec? 
>>>> 
>>>> Do you know how specific products handle this? 
>>>> 
>>>> Does it make sense to serve the metadata document from both locations?
>>>> 
>>>> -Daniel
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> -- 
>> https://danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Filip Skokan]

Some products publish both, but they don’t always return the same content, 
eventho as far as i can tell they should be aliases. 

The uri normalization of 8414 is also implemented wrong in some cases, since it 
differs from OIDC as far as issuer path component is concerned.

I find it best for AS to have just one or both with the same content, client 
software doing discovery can check both locations. 

Odesláno z iPhonu

> 8. 6. 2020 v 9:46, Daniel Fett :
> 
> 
> Hi all,
> 
> RFC8414 says that the URI where the OAuth metadata document is published is
> 
> formed by inserting a well-known URI string into the authorization
>server's issuer identifier between the host component and the path
>component, if any.  By default, the well-known URI string used is
>"/.well-known/oauth-authorization-server".
> 
> I found that some OAuth servers and clients instead follow the convention 
> used by OpenID Connect, where the suffix "/.well-known/openid-configuration" 
> (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.
> 
> Is this a common deviation from the spec? 
> 
> Do you know how specific products handle this? 
> 
> Does it make sense to serve the metadata document from both locations?
> 
> -Daniel
> 
> ___
> 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] Downgrade attacks on PKCE

[Filip Skokan]

I also have #2 in place since ages like others have, or are about to. 

It just made sense to me to have it that way based on PKCE Section 4.4.  The 
challenge and method are bound to the code to be verified later. 

When the server issues the authorization code in the authorization
   response, it MUST associate the "code_challenge" and
   "code_challenge_method" values with the authorization code so it can
   be verified later.

“Empty”, “Undefined” and the like are values to be verified too. The trigger to 
verify PKCE in the token request is presence of pkce params in either the code 
bound data or the request. Which would be the case described in Daniel’s blog 
post. 

- Filip

Odesláno z iPhonu

> 30. 5. 2020 v 9:59, Daniel Fett :
> 
> 
> Hi all,
> 
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] 
> and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that 
> we have two options:
> 
> 1. "Static" Solution
> 
> For every client_id that is registered with an AS, the AS MUST either always 
> enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or 
> nonce is enforced can be part of the client registration or configured in 
> other ways.
> 
> In other words: A single client is not allowed to switch between using PKCE 
> and using nonce.
> 
> Note that the client is allowed to use the respective other mechanism on top 
> of the enforced one.
> 
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the authorization 
> request.
> Not compatible to deployments where clients sometimes use nonce and sometimes 
> use PKCE with the same client_id. 
> 2. "Dynamic" Solution
> 
> Each AS that supports PKCE MUST check whether a code challenge is contained 
> in the authorization request. This information MUST be bound to the code that 
> is issued.
> 
> When a code arrives at the token endpoint, the AS MUST do the following check:
> 
> If there was a code_challenge in the authorization request for which this 
> code was issued, there must be a code_verifier in the token request and it 
> must be verified according to RFC7636. (This is no change from the current 
> behavior in RFC7636.)
> If there was no code_challenge in the authorization request, any request to 
> the token endpoint containing a code_verifier MUST be rejected.
> Properties:
> 
> No change in behavior needed for properly implemented clients. Backwards 
> compatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoint, token 
> endpoint, and a new data field in the authorization session maintained by the 
> AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on these two 
> solutions before proceeding to propose wording for the affected documents.
> 
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
> 
> -Daniel
> 
> ___
> 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 - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Filip Skokan]

, decision to break
   backwards compatibility amongst the authors
   - ML
   
<https://mailarchive.ietf.org/arch/browse/oauth/?q=%22DPoP%20-%20new%20authorization%20scheme%20%2F%20immediate%20usability%20concerns%22&gbt=1&index=>
thread,
   in my opinion inconclusive, no consensus


S pozdravem,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

[Filip Skokan]

Hello Brian,

can you share the slide deck from yesterday so that we may continue
the discussion on the mentioned open questions here on the list?

Thank you,

Best,
*Filip*


On Wed, 13 May 2020 at 20:43, Brian Campbell  wrote:

> Just wanted to note that there is a newer -01 revision of the document on
> the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html
>
> On Wed, May 13, 2020 at 6:16 AM IESG Secretary 
> wrote:
>
>> The Web Authorization Protocol (oauth) Working Group will hold
>> a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna
>> (16:00 to 17:00 UTC).
>>
>> Agenda:
>> DPOP
>> https://tools.ietf.org/html/draft-ietf-oauth-dpop-00
>>
>> Information about remote participation:
>> https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b
>>
>> https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/
>>
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>
> *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

Re: [OAUTH-WG] PAR - Can AS/client require request object?

[Filip Skokan]

I think require_request_objects has its place, that place should be JAR,
PAR as a backup. I believe doing only the "PAR-specific" name / meaning of
it would be a missed opportunity.

S pozdravem,
*Filip Skokan*


On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt  wrote:

> Hi all,
>
> I initially raised the question whether the AS should be able to require
> request objects for all clients (in the same way as we decided to let the
> AS required PAR for all clients) but this topic was never discussed later
> on.
>
> I suggest to add a server metadata parameter “require_request_objects” so
> the AS can indicate its policy to clients.
>
> I think the best place to define this parameter would be JAR, if that is
> not possible any longer, we could use a different PAR-specific name and add
> it to PAR.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 1. May 2020, at 17:56, Mike Jones  40microsoft@dmarc.ietf.org> wrote:
> >
> > Works for me.
> >
> >
> >
> > From: OAuth  On Behalf Of Torsten Lodderstedt
> > Sent: Friday, May 1, 2020 2:51 AM
> > To: Brian Campbell 
> > Cc: oauth 
> > Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> >
> >
> >
> > Filip´s proposal works for me.
> >
> >
> >
> > Are there any objections?
> >
> >
> >
> > Brian Campbell  schrieb am
> Mo. 27. Apr. 2020 um 20:57:
> >
> > While there are certainly different permutations and contexts of use
> that could be imagine, I tend to agree with Filip here in not seeing a
> strong need to define new PAR specific metadata around signing/encryption
> of the request object.
> >
> >
> >
> > On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote:
> >
> > Considering there's going to be a setting that forces clients to use PAR
> (other mailinglist thread), then we should rely on the existing
> `request_object_signing_alg` presence to indicate a Request Object must be
> used (as suggested by this upcoming OIDC Core errata), regardless of it
> being PAR or JAR. I don't see the need for a PAR specific metadata, for one
> - implementations wouldn't be easily able to re-use of existing pipelines,
> two - yes the contexts differ but do you think clients will be using both
> channels at the same time? And even if so, the Request Object is the same
> therefore its applicable to both channels the same.
> >
> >
> > Best,
> > Filip Skokan
> >
> >
> >
> >
> >
> > On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
> >
> > Hi all,
> >
> > this is one of the topics we quickly flipped through in the virtual
> meeting last week.
> >
> > I see the following open questions:
> > - Can the client require its instances to use request objects only.
> > - Are there further requirements on the properties of these objects?
> Signed only, Signed and encrypted, algorithms?
> > - Can an AS require ALL clients to use request objects only?
> > - Further requirements here as well?
> > - Is this tied to PAR or relevant for JAR as well?
> >
> > In my opinion, client as well as AS should be able to control enforced
> use of request objects.
> >
> > I could imagine the setting for JAR request objects (“request"
> parameter) and request objects in the PAR context differ, as the first case
> goes through the user’s browser whereas the PAR case goes direct from
> client to AS via a TLS protected channel. I therefore feel the settings
> should be PAR specific.
> >
> > What do you think?
> >
> > best regards,
> > Torsten.
> > ___
> > 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
> >
> >
> > 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

Re: [OAUTH-WG] PAR and client metadata

[Filip Skokan]

Alternatively, `require_pushed_authorization_requests`. Since we already
have the `*require_*request_uri_registration` server and `*require_*
auth_time` client metadata properties.

WDYT?

S pozdravem,
*Filip Skokan*


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn’t this also mean it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this as
> the same?
> - Who decides whether PAR and request_uri are required? The client for its
> instances or the AS for the whole deployment?
>
> I’m in favour of coupling enforced PAR use with enforced request_uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare forced
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs for
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter “pushed_authorization_requests_only” of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter “pushed_authorization_requests_only”
> - It requires this client to use PAR only. The AS won’t accept any
> authorization request containing more than request_uri + client_id for that
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR for
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
> >>
> >> As I tried to articulate in the original email and Filip also mentioned
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that’s the case then presumably a malicious party could register
> their own client that doesn’t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically registered
> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz request
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Filip Skokan]

I believe implementers should be free to devise their own URIs and not be
locked down to one by the spec, at the same time,
and RFC6755 subnamespace would be good for guidance.

So, I would suggest it be RECOMMENDED to use e.g.
`urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
that any URN or URL will do if the circumstances call for it.

Best,
*Filip*


On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  wrote:

> Hi all,
>
> another topic from last week’s virtual meeting.
>
> Shall there be guidance on the request URI structure?
>
> Please state your opinion.
>
> thanks in advance,
> Torsten.
> ___
> 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 - Can AS/client require request object?

[Filip Skokan]

Considering there's going to be a setting that forces clients to use PAR
(other mailinglist thread), then we should rely on the existing
`request_object_signing_alg` presence to indicate a Request Object must be
used (as suggested by this upcoming OIDC Core errata
<https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must>),
regardless of it being PAR or JAR. I don't see the need for a PAR specific
metadata, for one - implementations wouldn't be easily able to re-use of
existing pipelines, two - yes the contexts differ but do you think clients
will be using both channels at the same time? And even if so, the Request
Object is the same therefore its applicable to both channels the same.

Best,
*Filip Skokan*


On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  wrote:

> Hi all,
>
> this is one of the topics we quickly flipped through in the virtual
> meeting last week.
>
> I see the following open questions:
> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects?
> Signed only, Signed and encrypted, algorithms?
> - Can an AS require ALL clients to use request objects only?
> - Further requirements here as well?
> - Is this tied to PAR or relevant for JAR as well?
>
> In my opinion, client as well as AS should be able to control enforced use
> of request objects.
>
> I could imagine the setting for JAR request objects (“request" parameter)
> and request objects in the PAR context differ, as the first case goes
> through the user’s browser whereas the PAR case goes direct from client to
> AS via a TLS protected channel. I therefore feel the settings should be PAR
> specific.
>
> What do you think?
>
> best regards,
> Torsten.
> ___
> 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 - new authorization scheme / immediate usability concerns

[Filip Skokan]

I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:

> The idea of “Continuing to work without taking advantage of sender
> constraints” is, I would argue, a security hole. Systems are allowed to
> fail security checks but still offer functionality. This is exactly the
> pattern behind allowing an unsigned JWT because you checked the “alg"
> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
> that, but maybe we could’ve also made this more explicit within JOSE. By
> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
> says to the RS “either you know to look for this or you don’t know what it
> is”.
>
> It’s one of the problems I have with how the OAuth MTLS spec was written.
> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
> allows things to fall through in an insecure fashion. The same argument
> against it — ease of porting existing deployments — was raised there as
> well, and it won in the end. I hope we can do better this time.
>
>  — Justin
>
> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>
> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>
> If we had stuck "bearer" than i wouldn't have raised this topic, since
> existing RS would most likely ignore the cnf claim and the resource server
> calls would continue to work, obviously without taking advantage of the
> available sender check.
>
> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't support
>> DPoP. Which isn't really what you were asking about. But maybe would cover
>> some of the same ground.
>
>
> I agree.
>
>  The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help the
>> situation?
>
>
> :facepalm: indeed, sorry.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
> wrote:
>
>> Hi Filip,
>>
>> My attempts at responses to your questions/comments are inline:
>>
>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>
>>> I've wondered about the decision to use a new scheme before
>>> <https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> 
>>> but
>>> this time i'd like to challenge the immediate usability of the future spec
>>> for one specific case - sender constraining public client Refresh Tokens.
>>>
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>>
>>>
>>> If at all, it is going to take time for RS implementations to recognize
>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>> meantime, i'd still like to have the option to bind issued public client
>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>> i get an immediate win in sender constraining the refresh tokens but not
>>> introducing a breaking change for the RS.
>>>
>>>
>>>- Do you see this as something an AS implementation is just free to
>>>do since it's both the issuer and recipient of a refresh token?
>>>
>>> That's my first thought, yes.
>>
>>
>>>
>>>- Should this be somehow baked in the draft?
>>>
>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>> say though.
>>
>> In such a case the AS could bind the RT to the given dpop proof and
>> either not bind the AT while returning token_type=Bearer or bind the AT
>> while returning token_type value DPoP. In the latter case the AT would
>> almost certainly still work as a bearer to

Re: [OAUTH-WG] PAR and client metadata

[Filip Skokan]

I would support defining a client level property. I would also support an
AS discovery property for an AS-wide policy that is signalled to all
clients (and maybe that one would be enough).

FWIW (and this touches my earlier responses about the dpop scheme) defining
metadata (both AS and Client) is beneficial not only for runtime (DCR,
discovery) but in general supports developers using these specs, when they
read about a possible behaviour in the document and there's a mentioned
metadata property, they know what to look for in readmes, API
documentation, UI etc. It saves time, theirs, and mine when i develop those
behaviour toggles - i don't have to start mixing configuration objects so
far composed entirely of IANA registered properties with proprietary ones,
i don't need to come up with property names (and we know what a PITA that
is) and it also saves time in the long run because it's less likely someone
will open an issue about it.

Best,
*Filip*


On Tue, 14 Apr 2020 at 22:09, Brian Campbell  wrote:

> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *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

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan]

>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>

If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.


I agree.

 The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?


:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
wrote:

> Hi Filip,
>
> My attempts at responses to your questions/comments are inline:
>
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>
>> I've wondered about the decision to use a new scheme before
>> <https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> 
>> but
>> this time i'd like to challenge the immediate usability of the future spec
>> for one specific case - sender constraining public client Refresh Tokens.
>>
>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>
>
>>
>> If at all, it is going to take time for RS implementations to recognize
>> the new `DPoP` authorization scheme, let alone process it properly. In the
>> meantime, i'd still like to have the option to bind issued public client
>> refresh tokens using DPoP without affecting the access tokens. In doing so
>> i get an immediate win in sender constraining the refresh tokens but not
>> introducing a breaking change for the RS.
>>
>>
>>- Do you see this as something an AS implementation is just free to
>>do since it's both the issuer and recipient of a refresh token?
>>
>> That's my first thought, yes.
>
>
>>
>>- Should this be somehow baked in the draft?
>>
>> I'm not sure. Do you think it needs to be? I'm not sure what it would say
> though.
>
> In such a case the AS could bind the RT to the given dpop proof and either
> not bind the AT while returning token_type=Bearer or bind the AT while
> returning token_type value DPoP. In the latter case the AT would almost
> certainly still work as a bearer token at the RS and the client that knew
> the RS's needs could send it as such with an `Authorization: Bearer `.
> Or if it didn't know the RS's needs, it could start with `Authorization:
> DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
> point it could send `Authorization: Bearer `.
>
> As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.
>
>
>
>>
>>- Do you think client registration metadata could be used to signal
>>such intent?
>>
>> I think it certainly could. But it seems maybe too specific to warrant
> metadata.
>
>
>>
>>- Do you think the protocol should have signals in the messages
>>themselves to say what the client wants to apply DPoP to?
>>
>> My initial thought here is no. Take the case of a client working with an
> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
> really even think what signaling might look like there or how it could be
> made to be generally useful.
>
>
>>
>>- What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>Do we disqualify such cases or allow for sending two proofs, one for the 
>> AS
>>to bind refresh tokens to, one for the RS to bind access tokens to?
>>
>> The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?
>
>
> *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-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan]

I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.

If at all, it is going to take time for RS implementations to recognize the
new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to do
   since it's both the issuer and recipient of a refresh token? Should this be
   somehow baked in the draft?
   - Do you think client registration metadata could be used to signal such
   intent?
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?
   - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
   we disqualify such cases or allow for sending two proofs, one for the AS to
   bind refresh tokens to, one for the RS to bind access tokens to?


Best,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Filip Skokan]

Ad 1) the language is tricky but it does not say forbid the client from
sending in two resource values to the authorization endpoint, it says that
when access token is issued (i.e. the authorization_code grant at the token
endpoint) one of the granted resource values must be part of the request or
default to end up with an access token with a single audience. A resulting
refresh token contains all granted resource values. I don't see this as a
conflict but rather further profiling.

Ad 2) I disagree with making `aud` optional.

S pozdravem,
*Filip Skokan*


On Tue, 24 Mar 2020 at 07:48, Takahiko Kawasaki  wrote:

> (1)
> The requirement in the paragraph below excerpted from "3. Requesting a JWT
> Access Token":
>
> *If it receives a request for an access token containing more than one
> resource parameter, an authorization server issuing JWT access tokens MUST
> reject the request and fail with "invalid_request" as described in section
> 4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
> [RFC8707].  See Section 2.2 and Section 5 for more details on how this
> measure ensures there's no confusion on to what resource the access token
> granted scopes apply.*
>
>
> apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
> 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.
>
> (2)
> Regarding another paragraph shown below from the same section.
>
> *If the request does not include a resource parameter, the authorization
> server MUST use in the aud claim a default resource indicator.  If a scope
> parameter is present in the request, the authorization server SHOULD use it
> to infer the value of the default resource indicator to be used in the aud
> claim.  The mechanism through which scopes are associated to default
> resource indicator values is outside the scope of this specification.  If
> the values in the scope parameter refer to different default resource
> indicator values, the authorization server SHOULD reject the request with
> invalid_scope as described in section 4.1.2.1 of [RFC6749].*
>
>
> The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible. In addition, I don't think the rule
> referring to the "scope" parameter is worth being defined. That "aud" is
> missing but "scope" is available is enough for resource servers. In other
> words, if "aud" is determined based on the "scope", why do we have to set
> "aud" redundantly?
>
> Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".
>
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou  wrote:
>
>> Hi all,
>>
>>
>>
>> Allow me some comments and forgive me if some of them are naïve.
>>
>> - In Section 2.2 why nbf claim (
>> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>> <https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered?
>> I can imagine some interesting applications of this claim.
>>
>> - In the same section, it is not clear why some claims are required,
>> especially exp, sub, and client_id. The last two claims are not even used
>> during token validation.
>>
>> - RFC7519 specifies that, in the general case, the aud claim is an array
>> of StringOrURI values. In this draft it is not clear if this still the
>> case, or here aud is a simple string (e.g., in page 5 it is stated: the
>> resource indicated in the aud claim, rather than the resource*s*).
>>
>> - In the token validation procedure, i.e., Section 4, is there any reason
>> why the resource server first checks the aud claim, then the signature, and
>> finally the exp claim? Given the fact that Error responses are not
>> specified, returning something like “invalid aud claim” even for tokens
>> with invalid signature may result in privacy/security attacks.
>>
>> - IMHO The token validation procedure it too bound to the particular
>> discovery mechanisms mentioned at the beginning of this section. E.g., Step
>> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
>> Identifier” which must much the iss claim. Moreover, I think it should be
>> explicitly mentioned that the resource server “must validate that the JWT
>> access token has been singed with a signin

Re: [OAUTH-WG] Call for Adoption: DPoP

[Filip Skokan]

I support the adoption of DPoP. 

Best,
Filip

> 17. 3. 2020 v 13:21, Rifaat Shekh-Yusef :
> 
> 
> All,
> 
> As per the conclusion of the PoP interim meeting, this is a call for adoption 
> for the OAuth 2.0 Demonstration of Proof-of-Possession at the Application 
> Layer (DPoP) document:
> https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
>  
> Please, let us know if you support or object to the adoption of this document 
> as a working group document by March 31st.
> 
> 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] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Filip Skokan]

Yes, that sounds good to me.

Best,
Filip


On Tue, 25 Feb 2020 at 03:18, Nat Sakimura  wrote:

> 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  wrote:
>
>>
>> -- Forwarded message -
>> From: John Bradley 
>> 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 
>>
>>
>> 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  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 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 
>>> wrote:
>>> > >
>>> > > 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 

Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

[Filip Skokan]

Hi Mike,

Thank you for the implicit dpop draft, quick questions

- what htu and htm should be used when used with PAR?
- is it fair to say that authorization request provided dpop parameters only 
apply to authorization endpoint issued access tokens and in case of hybrid flow 
- the client sends a new proof with the access token request to the token 
endpoint?

Best,
Filip

Odesláno z iPhonu

> 10. 3. 2020 v 1:12, Mike Jones 
> :
> 
> 
> As I previously described, members of the OAuth working group have developed 
> a simplified approach to providing application-level proof-of-possession 
> protections for OAuth 2.0 access tokens and refresh tokens.  This approach is 
> called OAuth 2.0 Demonstration of Proof-of-Possession at the Application 
> Layer (DPoP).  Among other benefits, it does not require a complicated and 
> error-prone procedure for signing HTTP requests, as some past approaches have.
>  
> However, the DPoP specification to date has assumed that the client is using 
> the OAuth authorization code flow.  As promised at the last IETF meeting, 
> we’ve now published a simple companion specification that describes how DPoP 
> can be used with the OAuth implicit flow – in which access tokens are 
> returned directly from the authorization endpoint.  The specification is 
> mercifully brief because very little had to be added to supplement the 
> existing DPoP spec to enable use of DPoP with the implicit flow.  Thanks to 
> Brian Campbell and John Bradley for whiteboarding this solution with me.
>  
> Finally, in a related development, it was decided during the OAuth virtual 
> interim meeting today to call for working group adoption of the core DPoP 
> draft.  That’s an important step on the journey towards making it a standard.
>  
> The specification is available at:
> https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00
>  
> An HTML-formatted version is also available at:
> https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html
>  
>-- Mike
>  
> P.S.  This notice was also posted at https://self-issued.info/?p=2063 and as 
> @selfissued.
>  
> ___
> 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] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

I guess what i meant to call out is that while you and the spec says how
omitted fields should be handled, but in the same section earlier it states
that all fields must be included.

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 17:35, Justin Richer  wrote:

> I’m not sure what you’re asking — the text is not left over from anything
> and is intentionally included. That text is saying that if I leave out the
> field then the server treats it just like as if I had sent in a null value.
> So the following are equivalent:
>
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
>
> And
>
> {
>   “client_name”: “foo”,
> }
>
>
> In both cases, it’s a signal that the client is removing the value from
> the “tos_uri” field. It does not mean that the AS leaves the “tos_uri”
> field with the value that it previously was (ie, a PATCH style request).
>
> The AS can reject the update request if it doesn’t want to allow the
> client to blank out that field, for whatever reason.
>
>  — Justin
>
>
> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
>
> So the following
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> Does not mean the server needs to accept requests where fields are
> omitted? Is that a left over from previous drafts then?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:
>
>> Your interpretation was our intent with that. It’s a full replace of the
>> object. We had debating having PATCH style semantics, but ultimately
>> decided that that was too complex for the most common update actions that a
>> client would have.
>>
>>  — Justin
>>
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>>
>> Hello everyone,
>>
>> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2>
>> (Dynamic Client Registration Management Protocol) has the following two
>> statements that oppose one another.
>>
>> This request MUST include all client metadata fields as returned to the
>>> client from a previous registration, read, or update operation.
>>
>>
>> Omitted fields MUST be treated as null or empty values by the server,
>>> indicating the client's request to delete them from the client's
>>> registration.
>>
>>
>> What's the intention here? Should a server be accepting requests that are
>> missing client properties it has either on the record or "resolved" or not?
>>
>> Personally I like to always make sure the client submits everything and
>> to remove properties it must pass null or empty string as the values. That
>> way the request is 100% intentional about the final state of the record it
>> wants to update to.
>>
>> What do you think?
>>
>> Best,
>> *Filip*
>> ___
>> 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] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Sorry, i meant - is top level jti required as well?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 19:15, Filip Skokan  wrote:

> Torsten, let's make sure we call out the required top level JWT claims -
> iss, iat, aud, what else? is top level iat required as well?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt 
> wrote:
>
>> Hi all,
>>
>> based on the recent feedback, Vladimir and I propose the following
>> changes to draft-ietf-oauth-jwt-introspection-response:
>>
>> - the token data are encapsulated in a container element “_token_data”
>> - beyond this, the top-level container only contains meta data pertinent
>> to the JWT representing the signed (encrypted) introspection response
>> - we need to add text to the spec to point out that replay detection must
>> be based on the jti in the “_token_data” container not the top level claim
>>
>> That’s example of how it would look like:
>>
>> {
>>"iss":"https://as.example-bank.com";,
>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>"iat":1532452100,
>>"_token_data":{
>>   "active":true,
>>   "iss":"https://as.example-bank.com";,
>>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>   "iat":1532452084,
>>   "exp":1532453100,
>>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>   "cnf":{
>>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>   },
>>   "sub":"123456789087632345678"
>>}
>> }
>>
>> The response for inactive tokens would look like this:
>>
>> {
>>"iss":"https://as.example-bank.com";,
>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>"iat":1532452100,
>>"_token_data":{
>>   "active":false
>>}
>> }
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>>
>> > On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>> >
>> > +1, this encapsulation is much cleaner.
>> >
>> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>> >>
>> >> Perhaps we should consider leaving the root level JWT claims as-is per
>> JWT and push the introspection response unmodified as if it was regular
>> json response to a JWT claim called "introspection". Since regular
>> introspection uses the same claim names as JWT this would get around all
>> the conflicts.
>> >>
>> >> Last time i brought it up the authors didn't want to consider it
>> because of existing implementations.
>> >>
>> >> S pozdravem,
>> >> Filip Skokan
>> >>
>> >>
>> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki 
>> wrote:
>> >> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed
>> the same concerns in this mailing list about 6 months ago (on Sep. 4,
>> 2019). RFC 8707 didn't exist then, though.
>> >>
>> >> Re: [OAUTH-WG] Question regarding
>> draft-ietf-oauth-jwt-introspection-response-05
>> >>
>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>> >>
>> >> A JWT puts both (a) information about itself and (b) other data in its
>> payload part. When the "other data" have the same claim names as are used
>> to express information about the JWT itself, conflicts happen.
>> >>
>> >> Also, it should be noted that Ben pointed out in other thread that the
>> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
>> says "jti" is a unique identifier for the access token that MUST be stable
>> for all introspection calls, contradicts the definition of "jti", which
>> should be unique for each JWT.
>> >>
>> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
>> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>> >>
>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>> >>
>> >> draft-ietf-oauth-jwt-introspection-response needs to be modified to
>> solve the conflicts.
>> >>
>> >> Taka
&

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Torsten, let's make sure we call out the required top level JWT claims -
iss, iat, aud, what else? is top level iat required as well?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt 
wrote:

> Hi all,
>
> based on the recent feedback, Vladimir and I propose the following changes
> to draft-ietf-oauth-jwt-introspection-response:
>
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent
> to the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must
> be based on the jti in the “_token_data” container not the top level claim
>
> That’s example of how it would look like:
>
> {
>"iss":"https://as.example-bank.com";,
>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>"iat":1532452100,
>"_token_data":{
>   "active":true,
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>   "iat":1532452084,
>   "exp":1532453100,
>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>   "cnf":{
>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>   },
>   "sub":"123456789087632345678"
>}
> }
>
> The response for inactive tokens would look like this:
>
> {
>"iss":"https://as.example-bank.com";,
>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>"iat":1532452100,
>"_token_data":{
>   "active":false
>}
> }
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 4. Mar 2020, at 16:37, Justin Richer  wrote:
> >
> > +1, this encapsulation is much cleaner.
> >
> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
> >>
> >> Perhaps we should consider leaving the root level JWT claims as-is per
> JWT and push the introspection response unmodified as if it was regular
> json response to a JWT claim called "introspection". Since regular
> introspection uses the same claim names as JWT this would get around all
> the conflicts.
> >>
> >> Last time i brought it up the authors didn't want to consider it
> because of existing implementations.
> >>
> >> S pozdravem,
> >> Filip Skokan
> >>
> >>
> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki 
> wrote:
> >> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the
> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019).
> RFC 8707 didn't exist then, though.
> >>
> >> Re: [OAUTH-WG] Question regarding
> draft-ietf-oauth-jwt-introspection-response-05
> >>
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
> >>
> >> A JWT puts both (a) information about itself and (b) other data in its
> payload part. When the "other data" have the same claim names as are used
> to express information about the JWT itself, conflicts happen.
> >>
> >> Also, it should be noted that Ben pointed out in other thread that the
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
> says "jti" is a unique identifier for the access token that MUST be stable
> for all introspection calls, contradicts the definition of "jti", which
> should be unique for each JWT.
> >>
> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> >>
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
> >>
> >> draft-ietf-oauth-jwt-introspection-response needs to be modified to
> solve the conflicts.
> >>
> >> Taka
> >>
> >> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki 
> wrote:
> >> Hello,
> >>
> >> I'm wondering if the following conflicts in "JWT Response for OAuth
> Token Introspection" (draft 8) have already been pointed out.
> >>
> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an
> introspection response hold the values of the 'resource' request
> parameters, whereas "JWT Response for OAuth Token Introspection" says that
&

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

Got it, thanks!

Best,
Filip


On Wed, 4 Mar 2020 at 17:35, Justin Richer  wrote:

> I’m not sure what you’re asking — the text is not left over from anything
> and is intentionally included. That text is saying that if I leave out the
> field then the server treats it just like as if I had sent in a null value.
> So the following are equivalent:
>
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
>
> And
>
> {
>   “client_name”: “foo”,
> }
>
>
> In both cases, it’s a signal that the client is removing the value from
> the “tos_uri” field. It does not mean that the AS leaves the “tos_uri”
> field with the value that it previously was (ie, a PATCH style request).
>
> The AS can reject the update request if it doesn’t want to allow the
> client to blank out that field, for whatever reason.
>
>  — Justin
>
>
> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
>
> So the following
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> Does not mean the server needs to accept requests where fields are
> omitted? Is that a left over from previous drafts then?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:
>
>> Your interpretation was our intent with that. It’s a full replace of the
>> object. We had debating having PATCH style semantics, but ultimately
>> decided that that was too complex for the most common update actions that a
>> client would have.
>>
>>  — Justin
>>
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>>
>> Hello everyone,
>>
>> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2>
>> (Dynamic Client Registration Management Protocol) has the following two
>> statements that oppose one another.
>>
>> This request MUST include all client metadata fields as returned to the
>>> client from a previous registration, read, or update operation.
>>
>>
>> Omitted fields MUST be treated as null or empty values by the server,
>>> indicating the client's request to delete them from the client's
>>> registration.
>>
>>
>> What's the intention here? Should a server be accepting requests that are
>> missing client properties it has either on the record or "resolved" or not?
>>
>> Personally I like to always make sure the client submits everything and
>> to remove properties it must pass null or empty string as the values. That
>> way the request is 100% intentional about the final state of the record it
>> wants to update to.
>>
>> What do you think?
>>
>> Best,
>> *Filip*
>> ___
>> 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] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

So the following

Omitted fields MUST be treated as null or empty values by the server,
> indicating the client's request to delete them from the client's
> registration.


Does not mean the server needs to accept requests where fields are omitted?
Is that a left over from previous drafts then?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:

> Your interpretation was our intent with that. It’s a full replace of the
> object. We had debating having PATCH style semantics, but ultimately
> decided that that was too complex for the most common update actions that a
> client would have.
>
>  — Justin
>
> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>
> Hello everyone,
>
> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2>
> (Dynamic Client Registration Management Protocol) has the following two
> statements that oppose one another.
>
> This request MUST include all client metadata fields as returned to the
>> client from a previous registration, read, or update operation.
>
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> What's the intention here? Should a server be accepting requests that are
> missing client properties it has either on the record or "resolved" or not?
>
> Personally I like to always make sure the client submits everything and to
> remove properties it must pass null or empty string as the values. That way
> the request is 100% intentional about the final state of the record it
> wants to update to.
>
> What do you think?
>
> Best,
> *Filip*
> ___
> 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] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

Hello everyone,

Section 2.2 of RFC 7592 
(Dynamic Client Registration Management Protocol) has the following two
statements that oppose one another.

This request MUST include all client metadata fields as returned to the
> client from a previous registration, read, or update operation.


Omitted fields MUST be treated as null or empty values by the server,
> indicating the client's request to delete them from the client's
> registration.


What's the intention here? Should a server be accepting requests that are
missing client properties it has either on the record or "resolved" or not?

Personally I like to always make sure the client submits everything and to
remove properties it must pass null or empty string as the values. That way
the request is 100% intentional about the final state of the record it
wants to update to.

What do you think?

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Perhaps we should consider leaving the root level JWT claims as-is per JWT
and push the introspection response unmodified as if it was regular json
response to a JWT claim called "introspection". Since regular introspection
uses the same claim names as JWT this would get around all the conflicts.

Last time i brought it up the authors didn't want to consider it because of
existing implementations.

S pozdravem,
*Filip Skokan*


On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:

> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the
> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019).
> RFC 8707 didn't exist then, though.
>
> *Re: [OAUTH-WG] Question regarding
> draft-ietf-oauth-jwt-introspection-response-05*
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>
> A JWT puts both (a) information about itself and (b) other data in its
> payload part. When the "other data" have the same claim names as are used
> to express information about the JWT itself, conflicts happen.
>
> Also, it should be noted that Ben pointed out in other thread that the
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
> says "jti" is a unique identifier for the access token that MUST be stable
> for all introspection calls, contradicts the definition of "jti", which
> should be unique for each JWT.
>
> *Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)*
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve
> the conflicts.
>
> Taka
>
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  > wrote:
>
>> Hello,
>>
>> I'm wondering if the following conflicts in "JWT Response for OAuth Token
>> Introspection" (draft 8
>> <https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08>)
>> have already been pointed out.
>>
>> RFC 8707 <https://tools.ietf.org/html/rfc8707> (Resource Indicators for
>> OAuth 2.0) requires that 'aud' in an introspection response hold the values
>> of the 'resource' request parameters, whereas "JWT Response for OAuth Token
>> Introspection" says that 'aud' MUST identify the resource server receiving
>> the token introspection response. The definitions conflict.
>>
>> RFC 7662 <https://tools.ietf.org/html/rfc7662> (OAuth 2.0 Token
>> Introspection) requires that 'iat' in an introspection response indicate
>> when the access/refresh token was issued, whereas "JWT Response for OAuth
>> Token Introspection" says that 'iat' indicates when the introspection
>> response in JWT format was issued. The definitions conflict.
>>
>> Best Regards,
>> Takahiko Kawasaki
>> Authlete, Inc.
>>
>>
>>
>> ___
> 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] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Filip Skokan]

I also agree and support that client_id outside of the request object be usable 
for the purposes described earlier, given that it is also a MUST it be present 
in the request object with the same value as outside. 

Odesláno z iPhonu

> 31. 1. 2020 v 15:31, Mike Jones 
> :
> 
> I also agree that we must allow client_id to be expressed outside of the 
> signed request, as described by Nat.
> 
>-- Mike
> 
> -Original Message-
> From: OAuth  On Behalf Of John Bradley
> Sent: Friday, January 31, 2020 6:25 AM
> To: Nat Sakimura ; Benjamin Kaduk 
> Cc: oauth ; oauth-cha...@ietf.org; The IESG ; 
> draft-ietf-oauth-jws...@ietf.org
> Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
> 
>> From the discussions I have had, I agree with Nat's assment.
> 
> John B.
> 
>> On 1/31/2020 12:06 AM, Nat Sakimura wrote:
>> Hi
>> 
>> Re: JWT
>> I understand your concern and we can put some explanatory notes. 
>> Having said that, JAR is still a valid JWT, I think :-)
>> 
>> Re: client_id
>> We actually discussed client_id issues with OpenID Connect WG Call 
>> yesterday as well.
>> I hear a pretty strong voice from the developer community that they 
>> want client_id as a query parameter and it should not pose a security 
>> issue as long as it is required to match what is in the JWT. In fact, 
>> that was the position taken in the WG last call. So, in effect, WG is 
>> actually pushing back the change IESG wanted.
>> 
>> As I understand it, there are two points to be made:
>> (1) If client_id is not in the query parameter, then it MUST be in the 
>> JWT header OR MUST be supplied as a query parameter in some encrypted 
>> JAR case
>> (2) To check if requst_uri is a registered and valid URI, not having 
>> client_id in the query parameter will have performance impacts in a 
>> large AS.
>> 
>> The encryption case (1) can be solved by adding client_id in the JWT 
>> Header but it will not solve (2).
>> So, IMHO, putting client_id back to the query parameter (and MUST 
>> match the value in JWT) is a way to go.
>> Since that was the position by the WG at the WG Last Call, I do not 
>> feel that it needs to be brought back to the WG last call, but that is 
>> your call.
>> 
>> Best,
>> 
>> Nat Sakimura
>> 
>>> On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk  wrote:
>>> 
>>> Hi Nat,
>>> 
>>> Now it is my turn to apologize for taking a long time.
>>> 
>>> I think I see the general direction these changes are going in, and 
>>> it's a reasonable approach to the unfortunate situation we find 
>>> ourselves in with respect to JWT claims vs. OAuth parameters.  In 
>>> effect, what we're doing is making a "profile" (for lack of a better 
>>> term) of JWT, that leverages the mechanisms and algorithms of JWT but 
>>> uses a different registry for interpreting the claims in the token 
>>> (that is, OAuth Parameters vs. JWT Claims).  We can tell that this 
>>> "profile" of JWT is being used because of the context in which the JWT is 
>>> transferred/received: if it's the "request"
>>> parameter, that's part of the definition of the OAuth Parameter, and 
>>> if it's the result of dereferencing a "request_uri", the 
>>> application/oauth.authz.req+jwt media-type clearly indicates how the 
>>> contents should be interpreted.
>>> 
>>> However, the changes in the -20 do not give the reader much of any 
>>> hint as to this being what's expected to happen, and that stock RFC 
>>> 7519 JWT is
>>> *not* what's in use.  So I'd request that we take a close look at how 
>>> the document uses "JWT" vs. "JWT encoding" (etc.); add an explicit 
>>> statement that while the JWT encoding is in use, the contents are to 
>>> be interpreted by interpreting the JWT claims as OAuth Parameters 
>>> (and not as per the IANA registry of JWT claims); and add some 
>>> discussion (similar to the above) about how the application context 
>>> makes it unambiguous whether the JWT-encoded claims are standard JWT 
>>> claims or OAuth Parmaters as per this document.
>>> 
>>> With respect to my second ("discuss discuss") point, Nat and I did 
>>> have a discussion in-person and I accept that there may be some 
>>> scenarios in which skipping the authorization dialogue is 
>>> appropriate, so the example can remain.
>>> 
>>> 
>>> Moving on from my Discuss position, I do get the sense from the 
>>> ongoing discussion on the list that there's not clear agreement about 
>>> the current formulation that requires all parameters (but "request" 
>>> and "request_uri") to be in the JAR, especially with respect to 
>>> "client_id" that might be needed to unpack the JAR in some cases!  So 
>>> I'm not sure whether the WG wants to bring the document back to the 
>>> WG to iron out those issues before it returns to the IESG.  I'm a 
>>> little reluctant to switch my position to "No Objection" until we 
>>> have a clearer picture of what the WG wants to do on this front -- in 
>>> my understand

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Filip Skokan]

A 30x redirect to what is designed to be an authenticated backend client
call? Doesn't seem right to me.

S pozdravem,
*Filip Skokan*


On Thu, 16 Jan 2020 at 17:37, Neil Madden  wrote:

> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the Location header? That way the AS can
> decide for itself how to communicate any id from the PAR endpoint to the
> authorization endpoint.
>
> This also has the side effect that you can kick off an OAuth2 flow with a
> simple HTML form pointed at the PAR endpoint (with hidden fields for
> state/code_challenge etc).
>
> If actually performing the redirect is a bit problematic then at least the
> idea of returning a full URL for the authorization endpoint (hyperlink)
> rather than returning an id/URI and requiring the client to construct one
> seems reasonable to me and would seem to avoid some of the difficulties
> being discussed with JAR etc as the exact mechanism of communication
> becomes an implementation detail that the client needn't know about.
>
> -- Neil
>
> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> +1 to this approach, and it sounds like JAR might need to come back to go
> through another round anyway thanks to the breaking changes the IESG pushed
> into it after it left WGLC.
>
> I’d rather see us get this right than publish something many of us think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  — Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document..
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can’t fix
> the draft that hasn’t actually been published yet.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I’m not saying we suggest a particular form, and I agree that
> we shouldn’t specify that “it’s a JWT” or something of that nature. But if
> we call the result of PAR “thing X” and the target of request_uri “thing X”
> in JAR, then we’re compatible without saying what “thing X” needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want “thing X” to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believe
> that’s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  — Justin
>
>
> On Jan 11, 2020, at 5:28 A

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Filip Skokan]

Thinking of all the new edge cases we'd have to cover, i don't believe its
a good idea, as-is i see it elegant, capable of re-using existing
pipelines, the moment you change the parameter name new edge cases and
conditions start to popup. As an implementer i don't care that JAR says the
request_uri must reference a JWT, i know that requirement is in place for
the client<>AS contract. I'm fine with a language lifting that particular
requirement being present in PAR but i see that as a nitpick that adds
little to no real value to the final specification.

S pozdravem,
*Filip Skokan*


On Thu, 16 Jan 2020 at 17:25, Torsten Lodderstedt  wrote:

> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> +1 to this approach, and it sounds like JAR might need to come back to go
> through another round anyway thanks to the breaking changes the IESG pushed
> into it after it left WGLC.
>
> I’d rather see us get this right than publish something many of us think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  — Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document..
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can’t fix
> the draft that hasn’t actually been published yet.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I’m not saying we suggest a particular form, and I agree that
> we shouldn’t specify that “it’s a JWT” or something of that nature. But if
> we call the result of PAR “thing X” and the target of request_uri “thing X”
> in JAR, then we’re compatible without saying what “thing X” needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want “thing X” to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believe
> that’s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  — Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint and
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" a

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

[Filip Skokan]

Vladimir, 

For that very case the payload claims may be repeated in the JWE protected 
header. An implementation wanting to handle this may look for iss/client_id 
there. 

Odesláno z iPhonu

> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
> 
> I just realised there is one class of JARs where it's practially
> impossible to process the request if merge isn't supported:
> 
> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
> for that and specs a method for deriving the shared key from the
> client_secret:
> 
> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> 
> If the JAR is encrypted with the client_secret, and there is no
> top-level client_id parameter, there's no good way for the OP to find
> out which client_secret to get to try to decrypt the JWE. Unless the OP
> keeps an index of all issued client_secret's.
> 
> 
> OP servers which require request_uri registration
> (require_request_uri_registration=true) and don't want to index all
> registered request_uri's, also have no good way to process a request_uri
> if the client_id isn't present as top-level parameter.
> 
> 
> Vladimir
> 
> 
>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> 
 Am 10.01.2020 um 16:53 schrieb John Bradley :
>>> 
>>> I think Torsten is speculating that is not a feature people use.   
>> I’m still trying to understand the use case for merging signed and unsigned 
>> parameters. Nat once explained a use case, where a client uses parameters 
>> signed by a 3rd party (some „certification authority“) in combination with 
>> transaction-specific parameters. Is this being done in the wild? 
>> 
>> PS: PAR would work with both modes.
> 
> 
> ___
> 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] [UNVERIFIED SENDER] Re: PAR metadata

[Filip Skokan]

e but
> not all examples of such). There's no reason for PAR to make a one-off
> exception. And should there be some deployment specific reason that truly
> requires that kind of isolation, there are certainly implementation options
> that aren't compatibility-breaking. And having said all that, I'm honestly
> a little surprised anyone is thinking much about encrypted request objects
> with PAR as, at least with my limited imagination, there's not really a
> need for it.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
> PAR introduces an added wrinkle for encrypted request objects: the PAR
> endpoint and authorization endpoint may not have access to the same
> cryptographic keys, even though they're both part of the "authorization
> server." Since they're different endpoints with different roles, it's
> reasonable to put them in separate trust boundaries. There is no way to
> support this isolation with just a single "jwks_uri" metadata property.
>
> The two options that I see are:
>
> 1. Define a new par_jwks_uri metadata property.
> 2. Explicitly state that this separation is not supported.
>
> I strongly perfer #1 as it has a very minor impact on deployments that
> don't care (i.e., they just set par_jwks_uri and jwks_uri to the same
> value) and failing to support this trust boundary creates an artificial
> limit on implementation architecture and could lead to
> compatibility-breaking workarounds.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <
> oauth-boun...@ietf.org on behalf of torsten=
> 40lodderstedt@dmarc.ietf.org> wrote:
>
> Hi Filip,
>
> > On 31. Dec 2019, at 16:22, Filip Skokan  wrote:
> >
> > I don't think we need a *_auth_method_* metadata for every endpoint
> the client calls directly, none of the new specs defined these (e.g. device
> authorization endpoint or CIBA), meaning they also didn't follow the scheme
> from RFC 8414 where introspection and revocation got its own metadata. In
> most cases the unfortunately named `token_endpoint_auth_method` and its
> related metadata is what's used by clients for all direct calls anyway.
> >
> > The same principle could be applied to signing (and encryption)
> algorithms as well.
> >
> > This I do not follow, auth methods and their signing is dealt with
> by using `token_endpoint_auth_methods_supported` and
> `token_endpoint_auth_signing_alg_values_supported` - there's no encryption
> for the `_jwt` client auth methods.
> > Unless it was meant to address the Request Object signing and
> encryption metadata, which is defined and IANA registered by OIDC. PAR only
> references JAR section 6.1 and 6.2 for decryption/signature validation and
> these do not mention the metadata (e.g. request_object_signing_alg) anymore
> since draft 07.
>
> Dammed! You are so right. Sorry, I got confused somehow.
>
> >
> > PS: I also found this comment related to the same question about
> auth metadata but for CIBA.
>
> Thanks for sharing.
>
> >
> > Best,
> > Filip
>
> thanks,
> Torsten.
>
> >
> >
> > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> > Hi all,
> >
> > Ronald just sent me an email asking whether we will define metadata
> for
> >
> > pushed_authorization_endpoint_auth_methods_supported and
> > pushed_authorization_endpoint_auth_signing_alg_values_supported.
> >
> > The draft right now utilises the existing token endpoint
> authentication methods so there is basically no need to define another
> parameter. The same principle could be applied to signing (and encryption)
> algorithms as well.
> >
> > What’s your opinion?
> >
> > best regards,
> > Torsten.
>
>
>
> ___
> 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
>
___
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

[Filip Skokan]

I support the WG adoption of RAR.

Best,
*Filip*


On Mon, 6 Jan 2020 at 20:38, Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> 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] JWT Secured Authorization Request (JAR) vs OIDC request object

[Filip Skokan]

I don't think we have the separation of OAuth and non-OAuth parameters and
let's please not. Even OIDC parameters are part of the OAuth parameters
registry
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters>
and
I cannot imagine the hardship if we were to explain that to developers.

With passing time I believe it should be up to the profile or application
of JAR to define how to treat *recognized* parameters outside of the
request object. In my personal OSS project the AS can be configured to be
*strict* (jar), *lax* (oidc merge all) or *whitelist* (merge only
whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir
is describing.

S pozdravem,
*Filip Skokan*


On Mon, 6 Jan 2020 at 07:05, n-sakimura  wrote:

> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if
> duplicated.
>
> As of -13 (Mar 30, 2017), it was changed that the server does not have to
> do the merge, at least for OAuth Authorization request parameters. It says
> nothing about other parameters.
>
> As of -14 (Jul 21, 2017), the wording was further strengthened by adding
>
>
>
> The Authorization Server MUST only use the parameters in the Request
> Object even if the same parameter is provided in the query parameter.
>
>
>
> So, the entire 6.3 now became
> 6.3 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>.
> Request Parameter Assembly and Validation
>
>The Authorization Server MUST extract the set of Authorization
>
>Request parameters from the Request Object value.  The Authorization
>
>Server MUST only use the parameters in the Request Object even if the
>
>same parameter is provided in the query parameter.  The Authorization
>
>Server then validates the request as specified in OAuth 2.0
>
>[RFC6749 <https://tools.ietf.org/html/rfc6749>].
>
>
>
> It says nothing on the non-OAuth parameters that came with the
> authorization request.
>
> My take on the text is that all OAuth Authorization Request parameters
> MUST be in the request object.
>
> Behaviors towards other parameters that happens to have come together with
> the authorization request outside of request object will be treated as
> non-OAuth parameters.
>
>
>
> Nat Sakimura
>
> Research Fellow, Nomura Research Institute
>
> E: n-sakim...@nri.co.jp
>
> T: +81(90)60136276
>
> -
>
> PLEASE READ:This e-mail is confidential and intended for the named
> recipient only.
>
> If you are not an intended recipient, please notify the sender and delete
> this e-mail.
>
>
>
> *From:* OAuth  *On Behalf Of *Justin Richer
> *Sent:* Friday, January 3, 2020 2:35 AM
> *To:* Takahiko Kawasaki 
> *Cc:* Brian Campbell ; oauth
> ; Nat Sakimura 
> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC
> request object
>
>
>
> For solution [2], this is the behavior that’s required for OIDC today, so
> I would say that’s the New Client behaving like an Old Client in order to
> talk to an Old Server. So in reality, (2) causes the request to be
> rejected, and that’s OK.
>
>
>
> I don’t think it’s viable to require parameters to exist inside the
> request object at all times. Nor should we try to enumerate which
> parameters go inside and outside at all times — at least from the JAR/OAuth
> level of things. I think there are too many things that are application and
> deployment specific for us to make this call. The very nature of the
> request object changes for people — some have a static object that’s
> deployed with clients and some have something that the client creates at
> runtime for each request.
>
>
>
> If the instead the New Server requires that any parameters duplicated
> between the two places have to match (the OIDC method) or that in a
> conflict the request object values take precedence (the merge method), then
> problems 3-1 and 3-2 go away.
>
>
>
> With the merge-and-precedence behavior, which is what I thought that JAR
> had during WGLC, [3-1] is well-defined. The request is processed the same
> way every time because this is a New Server. The client is going to do
> OIDC’s “duplicate” method, so “merge with precedence” is effectively a
> no-op.
>
>
>
> With the merge-and-precedence behavior, [3-2] doesn’t happen because the
> required parameters aren’t required to be in the request object itself. As
> long as the request object is valid, it protects all parameters within it..
> I don’t think it’s up to us to determine what makes sense to put in that
> object. Security guidance is probably a good idea here.
>
>
>
> Solution [3] is wh

Re: [OAUTH-WG] PAR metadata

[Filip Skokan]

I don't think we need a *_auth_method_* metadata for every endpoint the
client calls directly, none of the new specs defined these (e.g. device
authorization endpoint or CIBA), meaning they also didn't follow the scheme
from RFC 8414 where introspection and revocation got its own metadata. In
most cases the unfortunately named `token_endpoint_auth_method` and its
related metadata is what's used by clients for all direct calls anyway.

The same principle could be applied to signing (and encryption) algorithms
> as well.


This I do not follow, auth methods and their signing is dealt with by using
`token_endpoint_auth_methods_supported` and
`token_endpoint_auth_signing_alg_values_supported` - there's no encryption
for the `_jwt` client auth methods.
Unless it was meant to address the Request Object signing and encryption
metadata, which is defined and IANA registered

by
OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signature
validation and these do not mention the metadata (e.g.
request_object_signing_alg) anymore since draft 07.

PS: I also found this comment
 related
to the same question about auth metadata but for CIBA.

Best,
*Filip*


On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt 
wrote:

> Hi all,
>
> Ronald just sent me an email asking whether we will define metadata for
>
> pushed_authorization_endpoint_auth_methods_supported and
> pushed_authorization_endpoint_auth_signing_alg_values_supported.
>
> The draft right now utilises the existing token endpoint authentication
> methods so there is basically no need to define another parameter. The same
> principle could be applied to signing (and encryption) algorithms as well..
>
> What’s your opinion?
>
> best regards,
> Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

[Filip Skokan]

Encrypted JARM responses are in a very similar position. Access Token value is 
not part of the URL and the response itself is protected. Such response is 
usually only consumed by a server side application. Same as any form_post 
response. 

We could go into further clarifying the client application topology to enable 
these uses but i don’t think it’s worth it. Why make excuses to keep implicit 
issued access tokens around in when code flow is the way the WG has decided to 
go. (Here we go again...)

Best,
Filip

> 27. 12. 2019 v 21:41, Torsten Lodderstedt 
> :
> 
> 
> As Brian said, we have discussed this several times and this text found 
> consensus.
> 
> Using post reduces the attack surface but does not allow to bind the access 
> token to the legitimate client. We are recommending sender constrained access 
> tokens in the BCP. So recommending a flow that does not support sender 
> constrained access tokens is a contradiction.
> 
> What do other WG members think?
> 
>>> Am 27.12.2019 um 21:28 schrieb Mike Jones 
>>> :
>>> 
>> 
>> I agree with Brian. Please update the text to describe this already safe 
>> usage.
>> 
>> -- Mike
>> 
>> From: OAuth  on behalf of Brian Campbell 
>> 
>> Sent: Friday, December 27, 2019 11:03:30 AM
>> To: oauth 
>> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + 
>> form_post response mode
>>  
>> We have a-sometimes used scenario where a client makes an 
>> authorization/authentication request with a "token id_token" response type 
>> and "form_post" response mode (nonce is also sent and exact redirect URI 
>> matching is done at the AS). The access token is never exposed in any URLs 
>> and access token injection is prevented by the at_hash claim in the id 
>> token. 
>> 
>> That seems to me like a legitimate and reasonable usage scenario. However, 
>> it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the 
>> Security BCP-to-be, which has:
>> 
>>In order to avoid these issues, clients SHOULD NOT use the implicit
>>grant (response type "token") or any other response type issuing
>>access tokens in the authorization response, such as "token id_token"
>>and "code token id_token", unless the issued access tokens are
>>sender-constrained and access token injection in the authorization
>>response is prevented.
>> 
>> I know this particular text has been discussed over and over again so I hate 
>> to revisit it. But based on the aforementioned scenario I think maybe it 
>> still doesn't quite hit the mark. Access token injection is prevented. The 
>> token leakage scenarios mentioned in that section are all avoided. And while 
>> I know sender-constrained is recommended elsewhere in the draft, it's not 
>> really a realistic option for the majority of deployments. 
>> 
>> 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

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

[Filip Skokan]

I support the WG adoption of PAR.

Best, Filip


On Tue, 17 Dec 2019 at 14:01, Daniel Fett  wrote:

> I support the adoption of PAR.
>
> -Daniel
>
> Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef:
>
> 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 listOAuth@ietf.orghttps://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] New Version Notification for draft-fett-oauth-dpop-03.txt

[Filip Skokan]

Rob, I agree that managing roots of trust, validating/OCSP etc is not
"easy" per se, but the MTLS setup gets really simple with the Self-Signed
Certificate Mutual-TLS Method
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-17#section-2.2> and we
made sure combined traffic is simple to signal by the AS and simple to
detect and use by clients using the mtls_endpoint_aliases discovery
metadata.

S pozdravem,
*Filip Skokan*


On Fri, 22 Nov 2019 at 09:10, Rob Otto  wrote:

> Hi Torsten - thanks for the reply..
>
> Responses in line.
>
> Grüsse
> Rob
>
> On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi Rob,
>>
>> > On 22. Nov 2019, at 15:52, Rob Otto > 40pingidentity@dmarc..ietf.org <40pingidentity@dmarc.ietf.org>>
>> wrote:
>> >
>> > Hi everyone
>> >
>> > I'd agree with this. I'm looking at DPOP as an alternative and
>> ultimately simpler way to accomplish what we can already do with MTLS-bound
>> Access Tokens, for use cases such as the ones we address in Open Banking;
>> these are API transactions that demand a high level of assurance and as
>> such we absolutely must have a mechanism to constrain those tokens to the
>> intended bearer. Requiring MTLS across the ecosystem, however, adds
>> significant overhead in terms of infrastructural complexity and is always
>> going to limit the extent to which such a model can scale.
>>
>> I would like to unterstand why mTLS adds “significant overhead in terms
>> of infrastructural complexity”. Can you please dig into details?
>>
>
> I guess it's mostly that every RS-endpoint (or what sits in front of it)
> has to have a mechanism for accepting/terminating mTLS, managing roots of
> trust, validating/OCSP, etc and then passing the certificates downstream as
> headers. None of it is necessarily difficult or impossible to do in
> isolation, but I meet many many people every week who simply don't know how
> to do any of this stuff. And these are typically "network people", for want
> of a better word. There are quite a few SaaS API management and edge
> solutions out there that don't even support mTLS at all. You also have the
> difficulty in handling a combination of MTLS and non-MTLS traffic to the
> same endpoints. Again, it's possible to do, but far from straightforward.
>
>
>
>>
>> Our experience so far: It can be a headache to set up in a microservice
>> architecture with TLS terminating proxies but once it runs it’s ok. On the
>> other side, it’s easy to use for client developers and it combines client
>> authentication and sender constraining nicely.
>>
>
> I do think its an elegant solution, don't get me wrong. It's just that
> there are plenty of moving parts that you need to get right and that can be
> a challenge, particularly in large, complex environments.
>
>
>
>>
>> >
>> > DPOP, to me, appears to be a rather more elegant way of solving the
>> same problem, with the benefit of significantly reducing the complexity of
>> (and dependency on) the transport layer. I would not argue, however, that
>> it is meant to be a solution intended for ubiquitous adoption across all
>> OAuth-protected API traffic. Clients still need to manage private keys
>> under this model and my experience is that there is typically a steep
>> learning curve for developers to negotiate any time you introduce a
>> requirement to hold and use keys within  an application.
>>
>> My experience is most developer don’t even get the URL right (in the
>> signature and the value used on the receiving end). So the total cost of
>> ownership is increased by numerous support inquiries.
>>
> I'll not comment, at the risk of offending developers :)
>
>>
>> best regards,
>> Torsten.
>>
>> >
>> > I guess I'm with Justin - let's look at DPOP as an alternative to
>> MTLS-bound tokens for high-assurance use cases, at least initially, without
>> trying to make it solve every problem.
>> >
>> > Best regards
>> > Rob
>> >
>> >
>> > On Fri, 22 Nov 2019 at 07:24, Justin Richer  wrote:
>> > I’m going to +1 Dick and Annabelle’s question about the scope here.
>> That was the one major thing that struck me during the DPoP discussions in
>> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
>> (including the authors, it seems) see it as a quick point-solution to a
>> specific use case. Others see it as a general PoP mechanism.
>> >
>> >

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Filip Skokan]

I agree with Torsten,

plus we're getting sender-constrained refresh tokens for said public
clients and SPAs so that the AS doesn't have to (according to the browser
based apps draft) rotate them, we all know the pain SPA developers have
with those.

S pozdravem,
*Filip Skokan*


On Fri, 22 Nov 2019 at 08:54, Torsten Lodderstedt  wrote:

>
>
> > On 22. Nov 2019, at 15:24, Justin Richer  wrote:
> >
> > I’m going to +1 Dick and Annabelle’s question about the scope here. That
> was the one major thing that struck me during the DPoP discussions in
> Singapore yesterday: we don’t seem to agree on what DPoP is for. Some
> (including the authors, it seems) see it as a quick point-solution to a
> specific use case. Others see it as a general PoP mechanism.
> >
> > If it’s the former, then it should be explicitly tied to one specific
> set of things. If it’s the latter, then it needs to be expanded.
>
> as a co-author of the DPoP draft I state again what I said yesterday: DPoP
> is a mechanism for sender-constraining access tokens sent from SPAs only.
> The threat to be prevented is token replay.
>
> The general mechanism for sender constrained access token should be
> TLS-based as recommended by the Security BCP (see
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3..2
> ).
>
> Why: that’s the easiest way from a client developer's perspective..
>
> Application level signatures, on the other hand, are inherently more
> fragile as illustrated by the OAuth 1 experience. They also require
> additional effort (and state) on the server side to implement replay
> detection.
>
> As kind of an entertaining read I added two posts/threads from 2010, when
> this WG discussed whether TLS/SSL should be the primary OAuth 2.0 security
> mechanism.
>
> https://mailarchive.ietf.org/arch/msg/oauth/crVvDNtbdN0E0ccmk5fLdNS66v0
>
> https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=xvlxuly1DjQiZgWZpHwgj7q2k0g
>
> The decision to go with TLS only was, in my opinion, one of the key
> success factors that made OAuth 2 so incredibly successful.
>
> To re-state: From my perspective, DPoP is intended to be used by SPA
> developers only for token replay detection (or better put to provide RSs
> with the pre-requisites to do so).
>
> Why? Because we unfortunately currently lack a TLS-based mechanism for
> sender-constraining.
>
> Building it on asymmetrical crypto only makes it easier to implement and
> to handle than methods based on shared secrets.
>
> I also think we must look for alternative methods to enable TLS-based
> methods in the browser.
>
>
> >
> > I’ll repeat what I said at the mic line: My take is that we should
> explicitly narrow down DPoP so that it does exactly one thing and solves
> one narrow use case. And for a general solution? Let’s move that discussion
> into the next major revision of the protocol where we’ll have a bit more
> running room to figure things out.
> >
> >  — Justin
> >
> >> On Nov 22, 2019, at 3:13 PM, Dick Hardt  wrote:
> >>
> >>
> >>
> >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden 
> wrote:
> >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
> >>> There are key distribution challenges with that if you are doing
> validation at the RS, but validation at the RS using either approach means
> you’ve lost protection against replay by the RS. This brings us back to a
> core question: what threats are in scope for DPoP, and in what contexts?
> >>
> >> Agreed, but validation at the RS is premature optimisation in many
> cases. And if you do need protection against that the client can even
> append a confirmation key as a caveat and retrospectively upgrade a bearer
> token to a pop token. They can even do transfer of ownership by creating
> copies of the original token bound to other certificates/public keys.
> >>
> >> While validation at the RS may be an optimization in many cases, it is
> still a requirement for deployments.
> >>
> >> I echo Annabelle's last question: what threats are in scope (and out of
> scope) for DPoP?
> >>
> >>
> >> ___
> >> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] IETF 106 IETF video stream

[Filip Skokan]

Hi,

I can hear an audio stream but no video has been started yet?

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Filip Skokan]

That’s already kind of dealt with in JWE by having claims required for 
decryption duplicated in the JWE header.

Odesláno z iPhonu

> 10. 10. 2019 v 19:01, Justin Richer :
> 

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

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Filip Skokan]

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the
request, if several client authentication methods are provided (header +
secret or secret + assertion, etc) you generally reject the request, don't
you?

Then there's the requirement for the client_id given by authentication
method (none is still an "authentication" method - client_id in the body)
to match the `iss` and `client_id` in the request object. That's already
required by JAR processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request
object, it also seems like you could pass in just the request object with
no other parameters, if I’m reading this right, which would imply that you
could be expected to glean the client ID from the request object itself
without it being in either a parameter or in another part of the request
that’s easily accessed.

It was only in the original FAPI revision of PAR that allowed the request
object's signature to substitute client authentication, in the individual
draft published to IETF that's not the case anymore - hence if "only" a
request object is passed - with no client authentication (header, client_id
in body, mtls) you fail the request.

As far as requiring client_id, here's what my implementation does

> When providing form-encoded parameters - client_id must be present in the
form.
> When providing signed/encrypted request object - client_id must be
present in the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it
not matching e.g. the authorization header because the client
authentication middleware in place already takes care of that.

S pozdravem,
*Filip Skokan*


On Thu, 10 Oct 2019 at 03:13, Justin Richer  wrote:

> So in doing an implementation of this, I ran into this problem as well.
> Specifically, we need to know which client we’re dealing with to fully
> validate the encrypted request object as well as perform the
> authentication. Currently, things are a little underspecified, and part of
> that comes from the history of this document: in the previous FAPI spec,
> the (required) signature of the request object acted as de-facto
> authentication for the client. In PAR, we not only can’t rely on the
> request itself being signed, we also require handling of client
> authentication in its many forms. That means the client ID could show up in
> any combination of:
>
>  - Form parameter
>  - Authorization header
>  - Client assertion’s “iss" field
>  - Request object’s “client_id” (and “iss”) field
>
> If several of these are sent, they need to be consistent. And whatever
> value comes out needs to be consistent with the client’s authentication
> method.
>
> But because JAR allows you to send in a request that is only a request
> object, it also seems like you could pass in just the request object with
> no other parameters, if I’m reading this right, which would imply that you
> could be expected to glean the client ID from the request object itself
> without it being in either a parameter or in another part of the request
> that’s easily accessed.
>
> So herein lies the problem. In order to properly process the request
> object, you need to know which client you’re dealing with so you can
> validate the signing algs, keys, and all that. For signed requests that’s
> simple enough — parse in one step, then authenticate the client, then
> validate the signatures. But for encrypted JWTs it’s less clear: some
> methods would use only the server’s public key, but symmetric encryption
> algorithm/encoding pairs would use the client secret as the pairwise secret
> for the encryption. Which means that we need to know which client sent the
> request before the decryption happens.
>
> Which in turn implies one of two things are true:
>
>  - You can’t do a request object when it’s encrypted using a symmetric
> algorithm
>  - You have to require the client ID from some other part of the request,
> such as a form parameter, auth header, or client assertion; the client_id
> in the request object cannot be counted on as being sufficient
>
> In our current draft implementation of PAR, I’m turning off support for
> symmetric encryption in this one code path. If we can somehow count on
> being able to find a client_id every time, then we can refactor our
> implementation to parse and handle all the client stuff :before: handling
> the request object itself. In other words, if I always have to send
> something that identifies the client in addition to the request object,
> then I can count on that.
>
> Thoughts?
>
> — Justin
>
> On Sep 30, 2019, at 11:21 AM, Brian Campbell <
> bcampbell=40pingidentity@

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Filip Skokan]

I find this to be an implementation detail, an optimization. As a matter of 
fact depending on the Request Object flavor the AS implements a second round of 
validation may be required.

Odesláno z iPhonu

> 23. 9. 2019 v 20:46, Janak Amarasena :
> 

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

Re: [OAUTH-WG] client authentication

[Filip Skokan]

Hello Jaap,

There are currently 7 registered

client authentication methods that are defined by various RFC's.

There are the three from RFC6749 which got their names registered in
RFC7591 - none, client_secret_basic and client_secret_post. (Please note
that RFC2617 IS NOT EQUAL to client_secret_basic - there are additional
requirements when it comes to encoding the username:password tokens defined
RFC 6749 Appendix B)

Then the two _jwt ones from RFC7523 that got their names registered as part
of OIDC Core 1.0 (yes, they're the same).

The two remaining are from draft-ietf-oauth-mtls and use mutual-TLS client
certificates for authentication.

RFC6750 does not define client authentication method. It defines different
means of using a Bearer Token obtained through any of the available flows
to access a protected resource.

Ad RFC7662) its at the discretion of the AS to require either a Bearer
Token or Client Authentication to access the introspection response, it may
or may not support both in which case the claims it returns may be limited
and also the means of obtaining that Bearer Token is out of scope of the
document.

Hope this helps,

Best,
*Filip*


On Tue, 17 Sep 2019 at 15:21, Jaap Francke 
wrote:

> Hi all,
>
> I was exploring the topic of client authentication in various RFCs.
> A few things are not 100% clear to me, I would be interested to get your
> feedback.
>
> RFC7591 sets up the registry for client authentication methods on the
> token endpoint and adds:
> - none
> - client_secret_basic (RFC2617)
> - client_secret_post (RFC6749)
>
> I don’t understand why that registry seems limited to the token-endpoint.
> Client authentication also applies to other protected (OAuth) endpoints
> such as token introspect, so it makes sense to have a generic (OAuth)
> client authentication method registry.
>
> OIDC specs indicate a few more:
> - client_secret_jwt
> - private_key_jwt
> Is my understanding correct that client_secret_jwt refers to the same
> client authentication method as described in
> https://tools.ietf.org/html/rfc7523#section-2.2 ?
>
> Furthermore there is RFC6750 which suggest 3 client authentication
> mechanisms which are not included in the registry:
> - Bearer / authorisation request header
> - bearer / URI query parameter
> - bearer / form encoded body parameter
> For example, the RFC7662 suggests to use the “bearer / authorisation
> request header” mechanism as client authentication/authorisation mechanism.
> Any reason why this was not done?
>
> Thanks in advance for any related feedback, regards,
>
> Jaap Francke
> ___
> 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] Public client cloning

[Filip Skokan]

A claimed HTTPS URI would tho, right?

Odesláno z iPhonu

10. 9. 2019 v 19:22, Marius Scurtescu 
:

> If the phone is compromised, original app replaced by malicious app, then 
> RFC8252 will not help. The assumption is that the phone is not compromised.
> 
>> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA  
>> wrote:
>> Hi,
>> 
>> I've read rfc8252 and have questions about native apps, that I couldn't find 
>> answers on Internet.
>> 
>> Imagine an attacker doing:
>> 1. original app and authorization server conforms to rfc8252 4.1.  
>> Authorization Flow for Native Apps Using the Browser
>> 2. clone the original app, name it malicious app and install on the target 
>> phone
>> 3. remove the original app from the target phone
>> 4. use the malicious app and authorize, OS will invoke malicious app using 
>> custom URL scheme
>> 5. now malicious app has access to the access token
>> 
>> How should we think about this?
>> What am I missing?
>> 
>> ___
>> 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] JWT Secured Authorization Request (JAR) vs OIDC request object

[Filip Skokan]

It would be fine not allowing that across the board but rather through a 
language like so

‘Authorization Servers MAY allow per-transaction parameters such as “state” and 
“nonce” to be sent outside of the Request Object using regular OAuth 2.0 
parameter syntax, the specific parameters are at the implementer’s discretion’

Odesláno z iPhonu

28. 8. 2019 v 23:23, Filip Skokan :

> Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere 
> in the mailing list archive around the time this was changed.
> 
> My take on satisfying both worlds looks like this
> 
> - allow just JAR - no other params when possible.
> (which btw isn't possible to do with request_uri when enforcing client 
> based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or 
> client_id is in request object it must either be missing or the same in 
> regular request).
> - allows merging request object and regular parameters with request object 
> taking precedence since it is a very useful feature when having pre-signed 
> request object that's not one time use and clients using it wish to vary 
> state/nonce per-request.
> 
> I wish the group reconsidered making this breaking change from OIDC's take on 
> request objects - allow combination of parameters from the request object 
> with ones from regular parameters (if not present in request object).
> 
> S pozdravem,
> Filip Skokan
> 
> 
>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell  
>> wrote:
>> Filip, for better or worse, I believe your assessment of the situation is 
>> correct. I know of one AS that didn't choose which of the two to follow but 
>> rather implemented a bit of a hybrid where it basically ignores everything 
>> outside of the request object per JAR but also checks for and enforces the 
>> presence and value of the few regular parameters (client_id, response_type) 
>> that OIDC mandates. 
>> 
>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  wrote:
>>> Hello everyone,
>>> 
>>> in an earlier thread I've posed the following question that might have 
>>> gotten missed, this might have consequences for the existing 
>>> implementations of Request Objects in OIDC implementations - its making 
>>> pure JAR requests incompatible with OIDC Core implementations.
>>> 
>>> draft 14 of jwsreq (JAR) introduced this language
>>> 
>>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.  However, the authorization server supporting this
>>>> specification MUST only use the parameters included in the request
>>>> object. 
>>> 
>>>> Server MUST only use the parameters in the Request Object even if the
>>>> same parameter is provided in the query parameter.  The Authorization
>>> 
>>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.  However, the authorization server supporting this
>>>> specification MUST only use the parameters included in the request
>>>> object. 
>>> 
>>> Nat, John, everyone - does this mean a JAR compliant AS ignores everything 
>>> outside of the request object while OIDC Request Object one merges the two 
>>> with the ones in the request object being used over ones that are sent in 
>>> clear? The OIDC language also includes sections which make sure that some 
>>> required arguments are still passed outside of the request object with the 
>>> same value to make sure the request is "valid" OAuth 2.0 request 
>>> (client_id, response_type), something which an example in the JAR spec does 
>>> not do. Not having this language means that existing authorization request 
>>> pipelines can't simply be extended with e.g. a middleware, they need to 
>>> branch their codepaths.
>>> 
>>> Is an AS required to choose which of the two it follows?
>>> 
>>> Thank you for clarifying this in advance. I think if either the behaviour 
>>> is the same as in OIDC or different this should be called out in the 
>>> language to avoid confusion, especially since this already exists in OIDC 
>>> and likely isn't going to be read in isolation, especially because the 
>>> Request Object is even called out to be already in place in OIDC in the JAR 
>>> draft.
>>> 

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

[Filip Skokan]

Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere
in the mailing list archive around the time this was changed.

My take on satisfying both worlds looks like this

- allow just JAR - no other params when possible.
(which btw isn't possible to do with request_uri when enforcing client
based uri whitelist and the jwsreq 5.2.2 shows as much)
- enforce the "dupe behaviours" defined in OIDC (if response_type or
client_id is in request object it must either be missing or the same in
regular request).
- allows merging request object and regular parameters with request object
taking precedence since it is a very useful feature when having pre-signed
request object that's not one time use and clients using it wish to vary
state/nonce per-request.

I wish the group reconsidered making this breaking change from OIDC's take
on request objects - allow combination of parameters from the request
object with ones from regular parameters (if not present in request object).

S pozdravem,
*Filip Skokan*


On Wed, 28 Aug 2019 at 23:02, Brian Campbell 
wrote:

> Filip, for better or worse, I believe your assessment of the situation is
> correct. I know of one AS that didn't choose which of the two to follow but
> rather implemented a bit of a hybrid where it basically ignores everything
> outside of the request object per JAR but also checks for and enforces the
> presence and value of the few regular parameters (client_id, response_type)
> that OIDC mandates.
>
> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  wrote:
>
>> Hello everyone,
>>
>> in an earlier thread I've posed the following question that might have
>> gotten missed, this might have consequences for the existing
>> implementations of Request Objects in OIDC implementations - its making
>> pure JAR requests incompatible with OIDC Core implementations.
>>
>> draft 14 of jwsreq (JAR) introduced this language
>>
>> The client MAY send the parameters included in the request object
>>> duplicated in the query parameters as well for the backward
>>> compatibility etc.
>>>
>>> *However, the authorization server supporting thisspecification MUST
>>> only use the parameters included in the requestobject. *
>>
>>
>> Server MUST only use the parameters in the Request Object even if the
>>> same parameter is provided in the query parameter.  The Authorization
>>
>>
>> The client MAY send the parameters included in the request object
>>> duplicated in the query parameters as well for the backward
>>> compatibility etc.
>>>
>>> *However, the authorization server supporting thisspecification MUST
>>> only use the parameters included in the requestobject. *
>>
>>
>> Nat, John, everyone - *does this mean a JAR compliant AS ignores
>> everything outside of the request object while OIDC Request Object one
>> merges the two with the ones in the request object being used over ones
>> that are sent in clear?* The OIDC language also includes sections which
>> make sure that some required arguments are still passed outside of the
>> request object with the same value to make sure the request is "valid"
>> OAuth 2.0 request (client_id, response_type), something which an example in
>> the JAR spec does not do. Not having this language means that existing
>> authorization request pipelines can't simply be extended with e.g. a
>> middleware, they need to branch their codepaths.
>>
>> Is an AS required to choose which of the two it follows?
>>
>> Thank you for clarifying this in advance. I think if either the behaviour
>> is the same as in OIDC or different this should be called out in the
>> language to avoid confusion, especially since this already exists in OIDC
>> and likely isn't going to be read in isolation, especially because the
>> Request Object is even called out to be already in place in OIDC in the JAR
>> draft.
>>
>> Best,
>> *Filip*
>> ___
>> 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

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

[Filip Skokan]

I can get by not having to have the minimum oauth request parameters, but the 
current language does not imply that one can use the parameters if they’re not 
present in the Request Object. 

That derails JAR from its OIDC variant. 

Odesláno z iPhonu

28. 8. 2019 v 10:48, Torsten Lodderstedt :

> Hi Filip,
> 
> In my understanding, duplication of request parameters outside of the request 
> object was necessary in the OIDC variant in order to retain OAuth compliance. 
> JAR as an OAuth extension will not require the client to duplicate OAuth 
> request parameters outside of the request object.  
> 
> There might potentially be reasons for merging (different) URI request 
> parameters with parameters passed in the request object in cases where long 
> living request objects are used.  
> 
> kind regards,
> Torsten. 
> 
>> On 27. Aug 2019, at 13:46, Filip Skokan  wrote:
>> 
>> Hello everyone,
>> 
>> in an earlier thread I've posed the following question that might have 
>> gotten missed, this might have consequences for the existing implementations 
>> of Request Objects in OIDC implementations - its making pure JAR requests 
>> incompatible with OIDC Core implementations.
>> 
>> draft 14 of jwsreq (JAR) introduced this language
>> 
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object. 
>> 
>> Server MUST only use the parameters in the Request Object even if the
>> same parameter is provided in the query parameter.  The Authorization
>> 
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object. 
>> 
>> Nat, John, everyone - does this mean a JAR compliant AS ignores everything 
>> outside of the request object while OIDC Request Object one merges the two 
>> with the ones in the request object being used over ones that are sent in 
>> clear? The OIDC language also includes sections which make sure that some 
>> required arguments are still passed outside of the request object with the 
>> same value to make sure the request is "valid" OAuth 2.0 request (client_id, 
>> response_type), something which an example in the JAR spec does not do. Not 
>> having this language means that existing authorization request pipelines 
>> can't simply be extended with e.g. a middleware, they need to branch their 
>> codepaths.
>> 
>> Is an AS required to choose which of the two it follows?
>> 
>> Thank you for clarifying this in advance. I think if either the behaviour is 
>> the same as in OIDC or different this should be called out in the language 
>> to avoid confusion, especially since this already exists in OIDC and likely 
>> isn't going to be read in isolation, especially because the Request Object 
>> is even called out to be already in place in OIDC in the JAR draft.
>> 
>> Best,
>> Filip
>> ___
>> 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] JWT Secured Authorization Request (JAR) vs OIDC request object

[Filip Skokan]

Hello everyone,

in an earlier thread I've posed the following question that might have
gotten missed, this might have consequences for the existing
implementations of Request Objects in OIDC implementations - its making
pure JAR requests incompatible with OIDC Core implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting thisspecification MUST only
> use the parameters included in the requestobject. *


Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter.  The Authorization


The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting thisspecification MUST only
> use the parameters included in the requestobject. *


Nat, John, everyone - *does this mean a JAR compliant AS ignores everything
outside of the request object while OIDC Request Object one merges the two
with the ones in the request object being used over ones that are sent in
clear?* The OIDC language also includes sections which make sure that some
required arguments are still passed outside of the request object with the
same value to make sure the request is "valid" OAuth 2.0 request
(client_id, response_type), something which an example in the JAR spec does
not do. Not having this language means that existing authorization request
pipelines can't simply be extended with e.g. a middleware, they need to
branch their codepaths.

Is an AS required to choose which of the two it follows?

Thank you for clarifying this in advance. I think if either the behaviour
is the same as in OIDC or different this should be called out in the
language to avoid confusion, especially since this already exists in OIDC
and likely isn't going to be read in isolation, especially because the
Request Object is even called out to be already in place in OIDC in the JAR
draft.

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Filip Skokan]

Any use:enc, without “use” or “key_ops” or keyops:encrypt/deriveKey that works 
with a supported algorithm, or one with the JWA “alg”. 

Odesláno z iPhonu

26. 7. 2019 v 14:01, Brian Campbell 
:

> I'd say this one->* any "enc" key published by the AS on its jwks_uri?
> 
>> On Thu, Jul 25, 2019 at 3:50 PM Танги Ле Пенс 
>>  wrote:
>> Dear all,
>> 
>> draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a 
>> JWS' signature (the client's key) 
>> (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2).
>> 
>> However there no such guidance for JWE encryption:
>> 
>> * any "enc" key published by the AS on its jwks_uri?
>> 
>> * one specific key of the ones listed at the server's jwks_uri? If so, 
>> how to indicate which one in particular?
>> 
>> * out-of-band configuration?
>> 
>> And should it be part of the specification?
>> 
>> Regards,
>> 
>> -- 
>> 
>> Tangui
>> 
>> ___
>> 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

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

[Filip Skokan]

John, Nat,

Tangui raises a good point I have missed,

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *


Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter.  The Authorization


The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *


Nat, John, everyone - *does this mean a JAR compliant AS ignores everything
outside of the request object while OIDC Request Object one merges the two
with the ones in the request object being used over ones that are not?* The
OIDC language also includes sections which make sure that some required
arguments are still passed outside of the request with the same value to
make sure the request is "valid" OAuth 2.0 request, something which an
example in the JAR spec does not do. Not having this language means that
existing authorization request pipelines can't simply be extended with e.g.
a middleware, they need to branch their codepaths.

Thank you for clarifying this in advance. I think if either the behaviour
is the same as in OIDC or different this should be called out in the
language to avoid confusion, especially since this already exists in OIDC
and likely isn't going to be read in isolation since its even called out to
be already in place in OIDC.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 20:48, Танги Ле Пенс  wrote:

> Filip, thank you for your reply. Additional remarks inline.
>
> On 25.07.2019 21:14, Filip Skokan wrote:
> > See my reply inline.
> >
> > S pozdravem,
> > *Filip Skokan*
> >
> >
> > On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс
> >  > <mailto:40mail...@dmarc.ietf..org>> wrote:
> >
> > In
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
> > is stated that an error is to be returned when the object request is
> > invalid. These errors are "invalid_request_uri" and
> > "invalid_request_object".
> >
> > However, to which redirect URI redirect in the following cases:
> > * the request object is invalid (eg. invalid signature), should we
> > still
> > use client_id/redirect_uri of the invalid request object?
> >
> > * the request URI could not be reached
> > * the request object is encrypted and cannot be decrypted (bad key)
> >
> >
> > FS: if the client_id & redirect_uri combination is valid (the uri is
> > valid for that client) - yes, its fine to use those (dtto state). this
> > applies to all three
>
> It doesn't apply to an encrypted object that cannot be decrypted.
>
> >
> > Would it be acceptable to use the "client_id" and "redirect_uri"
> > request
> > query parameters in such a case? Although it contradicts the current
> > specification which states that they shall not be used, and it would
> > defeat confidentiality when using encryption.
> >
> >
> > FS: how would it defeat confidentiality?
> If you use a JWE in the first place, it's so that the parameters cannot
> be read on the wire.
> >
> >
> > Another option is not redirecting and displaying the error message on
> > the AS, like when the client_id is unknown for instance.
> >
> >
> > FS: also an acceptable outcome, one with no caveats
>
> Except degraded UI for the end user, if we assume that an error on the
> client side is easier to manage that a cryptic error on the AS with no
> link back to the client. Also, the client could have a retry strategy
> (it might just be that the request object at the request object URI is
> expired, due to network latency, etc.).
>
> So if my understanding is correct, it's up to the implementer to make a
> decision on this point? Couldn't it lead to incompatibility, divergent
> implementations?
>
> >
> > Also I don't get the example in
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2
> > <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2>
> > :
> >
> > https://server.example.com/authorize?
> > response_type

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

[Filip Skokan]

See my reply inline.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс  wrote:

> In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
> is stated that an error is to be returned when the object request is
> invalid. These errors are "invalid_request_uri" and
> "invalid_request_object".
>
> However, to which redirect URI redirect in the following cases:
> * the request object is invalid (eg. invalid signature), should we still
> use client_id/redirect_uri of the invalid request object?

* the request URI could not be reached
> * the request object is encrypted and cannot be decrypted (bad key)
>

FS: if the client_id & redirect_uri combination is valid (the uri is valid
for that client) - yes, its fine to use those (dtto state). this applies to
all three


>
> Would it be acceptable to use the "client_id" and "redirect_uri" request
> query parameters in such a case? Although it contradicts the current
> specification which states that they shall not be used, and it would
> defeat confidentiality when using encryption.
>

FS: how would it defeat confidentiality?


>
> Another option is not redirecting and displaying the error message on
> the AS, like when the client_id is unknown for instance.
>

FS: also an acceptable outcome, one with no caveats


>
> Also I don't get the example in
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2 :
>
>   https://server.example.com/authorize?
> response_type=code%20id_token
> &client_id=s6BhdRkqt3
> &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
> %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
> &state=af0ifjsldkj
>
> in regards to the following statement in
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :
>
> The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.  However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object.
>
> My understanding is that "response_type", "client_id" and "state" will
> be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add
> them to the example?
>

FS: they will only be ignored IF they are also part of the request object
so i believe its fine to have them part of this example.


>
> Maybe I've missed something?
>
> Regards,
>
> --
> Tangui
>
> ___
> 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] Feedback on OAuth for browser-based Apps

[Filip Skokan]

>
> Obviously it can do it on a per-client basis still, but now an AS is going
> to have to know a bit more about the app itself. Perhaps we finally need a
> few more entries in the “application_type” metadata parameter from OIDC’s
> extension RFC7591 beyond “native” and “web”? But we at least probably want
> to point out to AS implementors that this is something they want to
> consider tracking in their data model for clients.
>

I would very much like to see that. native/web possibly in combination with
token_endpoint_auth_method and the client being DCR or "static" is far from
being enough to make a policy decision.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 13:45, Justin Richer  wrote:

> This raises an interesting question that I don’t think we’ve addressed
> yet: how to appropriately vary token lifetimes and access for different
> clients.
>
> Previously, an AS could see that a client was using the implicit flow and
> decide to limit token lifetimes or scopes based on that alone. Similarly, I
> know of at least some AS implementations that let you limit what scopes you
> allow under the client credentials grant. The key issue is that if all your
> clients are using the auth code flow (which I agree they should), then how
> does an AS tell the difference in capabilities between incoming clients?
>
> Obviously it can do it on a per-client basis still, but now an AS is going
> to have to know a bit more about the app itself. Perhaps we finally need a
> few more entries in the “application_type” metadata parameter from OIDC’s
> extension RFC7591 beyond “native” and “web”? But we at least probably want
> to point out to AS implementors that this is something they want to
> consider tracking in their data model for clients.
>
> — Justin
>
> On Jul 25, 2019, at 4:04 AM, David Waite 
> wrote:
>
>
>
>
> On Jul 24, 2019, at 3:03 PM, Aaron Parecki  wrote:
>
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
>  wrote:
>
> 
>
> I would rather say that ANY JS app should use CSP to lock down the browser
> features to a minimal attack surface. In addition, if refresh or access
> tokens are involved - further settings like disabling inline scripting
> (unsafe inline) and eval should be disabled.
>
>
> I'm not sure what to do with this suggestion. It feels like a blanket
> recommendation of enabling CSP will likely be ignored since it's too
> broad, and recommending disabling inline scripts is overreaching
> unless backed up by a specific threat it's protecting against. Did you
> have a particular threat in mind?
>
>
> I would say that browser applications should take measures to harden their
> applications again code injection and arbitrary code execution. Examples
> include eliminating inline script (and limiting embeddable objects as much
> as possible) via CSP, and versioning third party resources via techniques
> like subresource integrity.  Mechanisms such as augmenting the codebase to
> make sure all appropriate user input, data storage, and output properly
> sanitize data may be used - although they may be more expensive to
> implement and audit.
>
> The AS should likewise take into account an application’s overall security
> posture when deciding appropriate policies around delegated authorization
> scopes and token lifetimes.
>
> Best current practices include turning the screws tightly around CSP. But
> it is (theoretically) possible to accomplish the same with brute-force
> sanitization, which has been made simpler with framework support. It is
> still ultimately the AS job to decide which clients have which capabilities.
>
> -DW
> ___
> 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] Feedback on OAuth for browser-based Apps

[Filip Skokan]

Wouldn’t that contradict the security topics BCP?

Odesláno z iPhonu

23. 7. 2019 v 9:44, Neil Madden :

> Technically it could be optional, but it means that a CSRF attempt will only 
> be detected by the AS not by the client. If we consider the possibility of a 
> malicious AS, then this could allow Login CSRF attacks against the client. 
> The client would also have to be sure that the AS actually implements PKCE. 
> So I think it’s safer to leave the recommendation as-is. 
> 
>> On 23 Jul 2019, at 08:28, Dominick Baier  wrote:
>> 
>> Forgot one more thing
>> 
>> In 7.1
>> 
>> Browser-based apps MUST use the OAuth 2.0 "state" parameter to
>>protect themselves against Cross-Site Request Forgery and
>>authorization code swap attacks and MUST use a unique value for each
>>authorization request, and MUST verify the returned state in the
>>authorization response matches the original state the app created.
>> 
>> Isn’t state optional when PKCE is used?
>> 
>> thanks
>> ———
>> Dominick
>> 
>>> On 22. July 2019 at 08:14:33, Dominick Baier (dba...@leastprivilege.com) 
>>> wrote:
>>> 
>>> Hey, 
>>> 
>>> Just read the spec - good to see the progress. Some feedback:
>>> 
>>> I am yet undecided if I like the categorisation of the “Application 
>>> Architecture Patterns”. I definitely want to distinguish between 
>>> applications only accessing same-site back-end services and “others”. Not 
>>> sure if “dynamic application server" and “static application server” should 
>>> be handled differently - they are deployment details and should not decide 
>>> on the application security architecture. Also not sure how realistic it is 
>>> to deploy a typical applications solely from e.g. a CDN. But I don’t have 
>>> the right answer wrt to categories right now.
>>> 
>>> 6.1.  Apps Served from a Common Domain as the Resource Server
>>> 
>>> > OAuth and OpenID Connect provide very little benefit in this
>>>deployment scenario, so it is recommended to reconsider whether you
>>>need OAuth or OpenID Connect at all in this case.
>>> 
>>> I think you are mixing authentication and API access here. Depending on 
>>> application scenario it makes a lot of sense to use OIDC - but rely on the 
>>> resulting session to control API access. 
>>> Unless you want to dive into the details here, I suggest you remove the 
>>> mention of OIDC because it is misleading.
>>> 
>>> 
>>> 6.2.  Apps Served from a Dynamic Application Server
>>> 
>>> I have a .NET sample for that 
>>> 
>>> https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
>>> And a blog post
>>> https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>>> 
>>> 9.7. Content-Security Policy
>>>A browser-based application that wishes to use either long-lived
>>>refresh tokens or privileged scopes SHOULD restrict its JavaScript
>>>execution to a set of statically hosted scripts via a Content
>>>Security Policy ([CSP2]) or similar mechanism.
>>> 
>>> 
>>> I would rather say that ANY JS app should use CSP to lock down the browser 
>>> features to a minimal attack surface. In addition, if refresh or access 
>>> tokens are involved - further settings like disabling inline scripting 
>>> (unsafe inline) and eval should be disabled.
>>> 
>>> Thanks for doing this work!
>>> 
>>> ———
>>> Dominick
>> ___
>> 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] New OAuth DPoP and Security BCP drafts

[Filip Skokan]

Hello Daniel, everyone,

I don't know if this belongs to the DPoP document itself or each respective
BCP (especially Browser-Based Apps), but one of the documents should give
recommendation to implementers on how to

   1. generate the unique private keys per installation / browser session
   2. platform specific storage for them (e.g. in between browser
   navigation / app launches)

I come asking for this guidance especially for the Browser-Based App use
case. I think the clear recommendation is to use the Web Cryptography API
 (with
extractable: false) for (1) and IndexedDB API
 for (2),
but the more important question is how to deal with lack of those APIs in
browsers that are known to not support them or be buggy (see data in
https://caniuse.com), so

   - is it ok to use other means of generating the key when webcrypto is
   not available?
   - is it ok to generate keys through webcrypto (or other means) that are
   extractable and store them via other means than IndexedDB when indexed DB
   is not available, such as cookie or localstorage.

Best,
*Filip*


On Mon, 8 Jul 2019 at 15:30, Daniel Fett  wrote:

> All,
>
> In preparation for the meeting in Montreal, I just uploaded a new version
> of the DPoP draft:
> https://tools.ietf.org/html/draft-fett-oauth-dpop-02
>
> Please have a look and let me know what you think. We should make this a
> working group item soon.
>
> As you might have noticed, there is also a new version of the Security
> Best Current Practice draft:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>
> -Daniel
> ___
> 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 OAuth DPoP and Security BCP drafts

[Filip Skokan]

I've updated my OP projects draft implementation to 02 as well as the
example browser based client using DPoP for those interested

RP: https://murmuring-journey-60982.herokuapp.com
OP: https://op.panva.cz/.well-known/openid-configuration

As I've mentioned in the github issue tracker i think a server discovery
medatata will be needed so that the RP can know upfront which DSAs are
supported on the OP side to validate DPoP Proof JWTs with

Best,
*Filip Skokan*


On Mon, 8 Jul 2019 at 15:30, Daniel Fett  wrote:

> All,
>
> In preparation for the meeting in Montreal, I just uploaded a new version
> of the DPoP draft:
> https://tools.ietf.org/html/draft-fett-oauth-dpop-02
>
> Please have a look and let me know what you think. We should make this a
> working group item soon.
>
> As you might have noticed, there is also a new version of the Security
> Best Current Practice draft:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>
> -Daniel
> ___
> 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] OAuth 2.0 UI/UX Resources?

[Filip Skokan]

Hello Daniel,

you may gather inspiration and explore Auth0's flows all-in-one page at
https://flows.auth0.com

Best,
*Filip Skokan*


On Wed, 3 Jul 2019 at 16:26, Daniel Roesler  wrote:

> Howdy all,
>
> Apologies if this is slightly off topic.
>
> I'm a part of the Green Button Alliance, the non-profit standards body
> around sharing energy data, and the customer consent process is based
> on OAuth 2.0 (e.g. granting access to your smart meter data in order
> to have an energy audit done).
>
> However, most utilities we work with are unfamiliar with OAuth 2.0, so
> we often have to explain how it works and what the best practices are.
> There are plenty of resources we can point them to for the actual
> protocol handshake, but I haven't been able to find any resources
> around best practices for designing the user interface and experience
> of OAuth. Unfortunately, in the energy industry, UI/UX design isn't
> our strong suit, so it would be very helpful if we had design
> lessons-learned from other industries to use as a reference.
>
> Does anyone here know of any resources, talks, blog posts, examples,
> etc. for making good OAuth 2.0 UI/UX?
>
> Thanks!
> Daniel Roesler
>
> ___
> 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] Client Metadata for Resource Indicators for OAuth 2.0

[Filip Skokan]

Dear John, Brian, everyone,

I'd like to forward a request from several developers using my AS software
to have defined client metadata property similar to scope in section 2 of RFC
7591 <https://tools.ietf.org/html/rfc7591#section-2> but for "resources a
client must stay within the bounds of".

My answer to these developer is that they are able to configure their AS
with custom client metadata with defined validations executed *but since
this is a re-occurring request I wonder if it would be worth to define and
register a property in the resource indicators specification itself that
would promote interoperability and would allow its readers to know what to
look for in available client metadata.*

The format can either be an array of resource values or just like with
scope a space-delimited string of resource values.

Best,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] MTLS discovery - mtls_endpoint_aliases and _endpoint_auth_methods_supported

[Filip Skokan]

Hello everyone,

This is a follow to IETF 104 Thursday, March 28, 2019 OAuth meeting where
we discussed the MTLS update.

In the meeting we discussed the mtls_endpoint_aliases discovery property
that exposes mutual-TLS enabled endpoints in addition to ones that don't
have mutual-TLS enabled. We're doing this so that there are no cert
selection popups for end-users when AS supports a mix of mtls and non-mtls
interactions at e.g. the token endpoint.

Annabelle brought up an issue on this list and in the meeting about the
*_endpoint_auth_methods_supported discovery properties - about "this"
endpoint which is now potentially in two places. I believe we have reached
a compromise in the meeting to also allow these properties in the aliases
but I cannot find a message about this neither on the list nor in the
meeting notes.

An example of such discovery document can be found here
 (aliases at the end
of the document), notice that self_signed_tls_client_auth is not present in
the root *_endpoint_auth_methods_supported properties but is present in the
aliases.

There have been no published updates to the MTLS draft since and i'm
wondering if this is going to make it in the next revision. I also do not
wish this point to get forgotten, hence this message.

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint

[Filip Skokan]

Hello Takahiko,

Such language already exists in second to last paragraph of section 3.1. Like 
with CIBA the client’s regular token endpoint auth method is used at the device 
authorization endpoint. 

> The client authentication requirements of Section 3.2.1 of [RFC6749] apply to 
> requests on this endpoint, which means that confidential clients (those that 
> have established client credentials) authenticate in the same manner as when 
> making requests to the token endpoint, and public clients provide the 
> "client_id" parameter to identify themselves.

Odesláno z iPhonu

4. 6. 2019 v 4:10, Takahiko Kawasaki :

> Hello,
> 
> Do you have any plan to define a rule as to which client authentication 
> method should be used at the device authorization endpoint (which is defined 
> in OAuth 2.0 Device Authorization Grant)?
> 
> Section 4 of CIBA, which has incorporated some ideas/rules/parameters from 
> Device Flow, says as follows.
> 
> The token_endpoint_auth_method indicates the registered authentication method 
> for the client to use when making direct requests to the OP, including 
> requests to both the token endpoint and the backchannel authentication 
> endpoint.
> 
> This means that a backchannel authentication endpoint in CIBA (which 
> corresponds to a device authorization endpoint in Device Flow) performs 
> client authentication using the client authentication method specified by the 
> token_endpoint_auth_method metadata of the client.
> 
> I'd like to know if you have any plan to explicitly add a description like 
> above into the specification of OAuth 2.0 Device Authorization Grant.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> ___
> 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] JWT Response for OAuth Token Introspection implementations

[Filip Skokan]

Hi Rifaat,

node.js OSS oidc-provider implements the document in full behind an optional 
feature toggle - 
https://github.com/panva/node-oidc-provider/blob/master/docs/README.md#featuresjwtintrospection

Best,
Filip

Odesláno z iPhonu

2. 5. 2019 v 22:46, Rifaat Shekh-Yusef :

> All,
> 
> As part of the shepherd write-up for the JWT Response for OAuth Token 
> Introspection draft, we are looking for information about implementations for 
> this document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
> 
> Are you aware of any implementations?
> 
> Regards,
>  Rifaat
> 
> 
> ___
> 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] on PKCE for CSRF prevention instead of state parameter

[Filip Skokan]

In Prague we've seen and talked about this point from Torsten's deck
<https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-security-topics-00>


> Use PKCE for CSRF prevention instead of state parameter
>
>- PKCE is mandatory now and can fulfill this additional task
>- Simplifies recommendations and makes state available again for
>original purpose (carry client transaction data)
>
>
While PKCE is now the suggested countermeasure to some attacks and is to be
used by Clients it's not yet mandatory to be implemented by the AS and the
client has no way of knowing for sure if it's implemented (due to how PKCE
is defined as backwards compatible to clients when AS is missing its
support).

Since at no point in time does the client receive anything from the AS
suggesting that PKCE is in effect, is this a wise recommendation to make in
the current form? Some might interpret this as if they don't need state to
carry any client transaction data they might as well just use PKCE and omit
state altogether altho the server does not support PKCE.

S pozdravem,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Filip Skokan]

I support the draft's adoption.

Best,
*Filip Skokan*


On Mon, 8 Apr 2019 at 19:07, Hannes Tschofenig 
wrote:

> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Rifaat
>
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] CORS and the Device Authorization Grant (device flow)

[Filip Skokan]

Hello *,

I recall implementing an early draft of this flow few years ago for a
client landscape composed primarily of older set-top boxes, old and new TV
models of various brands (LG, Samsung, Sony) and also HbbTV standards 1.5
and 2.0.

I remember having to set up CORS on both the device authorization and token
endpoints (unheard of at the time!) for the sake of these clients.

The reason they required CORS is that these were implemented using, mostly
proprietary, xhtml/html5 based sandboxes running on those devices. The APIs
developers were given were javascript ones, more specifically the http
client was obviously XMLHttpRequest and the whole app when being developed
was debugged in a regular browser.

Since the specification does not mention CORS anywhere I wonder if
a) I was deceived by our business partners to think this was a generic
problem of these client types and not just developers being lazy to turn
off cors when debugging,
b) this was corrected or
c) it's still happening and noone just didn't brought it up

What are your experiences with CORS setup on the device authorization and
token endpoints in relation to device flow for Smart TV, set-top boxes and
HbbTV stream apps (excluding tvOS and AndroidTV).

Best,
*Filip*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and SAN

[Filip Skokan]

Yes.

S pozdravem,
*Filip Skokan*


On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:

> Thank you, I did miss that text. This should be called out more explicitly
> in §2.1, perhaps by specifying that it is only one field. This still
> doesn’t set precedence, but it implies that it’s an error for a client to
> have more than one field set of the available options. Is that your read on
> this as well?
>
> — Justin
>
> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>
> Justin, I had the exact same question off list and believe draft 13
> clarified this.
>
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>
> A client using the "tls_client_auth" authentication method MUST use
> exactly one of the below metadata parameters to indicate the certificate
> subject value that the authorization server is to expect when
> authenticating the respective client.
>
> Then it lists the different dn/san properties.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>
>> We’ve just started implementation of SAN-based certificate
>> authentication, based on the changes in version -13 of the draft. I believe
>> this addition is a bit unclear, due to it being added so late in the
>> document process.
>>
>> My question is how does an AS determine whether to DN or SAN for
>> certificate checking? Corollary, are these mutually exclusive or can they
>> be used together? Currently, the specification text lists DN and SAN as an
>> “or” with no indication whether this is an inclusive or exclusive “or”, and
>> what to do when there’s overlap.
>>
>> This has implications both for the implementation of the server
>> processing the request as well as the client metadata model, since the
>> client fields are all in parallel to each other. I can see a few ways of
>> handling this.
>>
>>
>> 1) One of the fields takes precedence over the other. Say for example you
>> choose the DN field: if it’s set, then you do DN matching and ignore the
>> SAN fields entirely, both in the cert and in the client’s registration.
>> Inverse is true if you choose the SAN fields over the DN but the principle
>> is the same. We should be explicit if there’s an intended precedence
>> between these two, and even more explicit if the DN and SAN are at equal
>> level and the AS gets to choose. We also need to be clear if it’s an error
>> condition if both are set simultaneously, like the way that jwks and
>> jwks_uri are mutually exclusive.
>> 2) You set an explicit switch in your client model that says whether to
>> use the DN or the SAN fields in comparison, and your code branches based on
>> that to either DN or SAN processing. This could also be added as an
>> explicit client metadata field, or it could be an internal detail. If an
>> internal detail, we should be explicit about there not being a predefined
>> precedence between the fields.
>> 3) If it’s allowable to use them together, you match everything that’s
>> set in the client, and at least one field MUST be set.
>>
>>
>> What’s the intended behavior for implementers, and should we be more
>> explicit about this? We are starting our implementation with (1) pending
>> the outcome of this thread, and I’d be curious to know how others are
>> implementing this in their systems.
>>
>> Thanks,
>> — Justin
>>
>> ___
>> 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] MTLS and SAN

[Filip Skokan]

Justin, I had the exact same question off list and believe draft 13
clarified this.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2

A client using the "tls_client_auth" authentication method MUST use exactly
one of the below metadata parameters to indicate the certificate subject
value that the authorization server is to expect when authenticating the
respective client.

Then it lists the different dn/san properties.

S pozdravem,
*Filip Skokan*


On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:

> We’ve just started implementation of SAN-based certificate authentication,
> based on the changes in version -13 of the draft. I believe this addition
> is a bit unclear, due to it being added so late in the document process.
>
> My question is how does an AS determine whether to DN or SAN for
> certificate checking? Corollary, are these mutually exclusive or can they
> be used together? Currently, the specification text lists DN and SAN as an
> “or” with no indication whether this is an inclusive or exclusive “or”, and
> what to do when there’s overlap.
>
> This has implications both for the implementation of the server processing
> the request as well as the client metadata model, since the client fields
> are all in parallel to each other. I can see a few ways of handling this.
>
>
> 1) One of the fields takes precedence over the other. Say for example you
> choose the DN field: if it’s set, then you do DN matching and ignore the
> SAN fields entirely, both in the cert and in the client’s registration.
> Inverse is true if you choose the SAN fields over the DN but the principle
> is the same. We should be explicit if there’s an intended precedence
> between these two, and even more explicit if the DN and SAN are at equal
> level and the AS gets to choose. We also need to be clear if it’s an error
> condition if both are set simultaneously, like the way that jwks and
> jwks_uri are mutually exclusive.
> 2) You set an explicit switch in your client model that says whether to
> use the DN or the SAN fields in comparison, and your code branches based on
> that to either DN or SAN processing. This could also be added as an
> explicit client metadata field, or it could be an internal detail. If an
> internal detail, we should be explicit about there not being a predefined
> precedence between the fields.
> 3) If it’s allowable to use them together, you match everything that’s set
> in the client, and at least one field MUST be set.
>
>
> What’s the intended behavior for implementers, and should we be more
> explicit about this? We are starting our implementation with (1) pending
> the outcome of this thread, and I’d be curious to know how others are
> implementing this in their systems.
>
> Thanks,
> — Justin
>
> ___
> 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