[OAUTH-WG] OAuth 2.0 for First-Party Native Applications + Step-Up

[Dmitry Telegin]

First of all, thanks to everyone who worked on this draft. (Aaron - special
thanks for your time at OSW!). This is also to register our (Backbase)
interest in contributing to the draft.

Question on using FiPNA for step-up and similar cases; as long as cookies
are not used in the native scenario, how do we communicate the existing
session to the authorization challenge endpoint? We already have
id_token_hint, but the problem is that ID tokens would generally contain no
session identifiers (in some cases they would, e.g. OIDC Front Channel
Logout requires the presence of the "sid" claim in the ID token, but again,
that's not the general case).

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

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

[Atul Tulshibagwale]

Hi George,
Indeed, it might be time to re-think how scopes work in general.Food for
thought for all of us here.

Re: step up auth spec: I suppose you are referring to the
"insufficient_user_authentication" error response (in Section 3
)
that might contain suggested scopes? Should such a mechanism be included in
the WWW-Authenticate Response (Section 5.1
)
in the OPRM draft?

This addresses (to some extent) Issue #1 I mentioned in my email (If I have
a resource server that has multiple endpoints, each of which require
different scopes, how should those be handled?). But it still does not
address issue #2 from my previous email:

   - Does the spec encourage insecure behavior in the caller by requesting
   tokens with scopes that they do not understand? I.e. If an authorization
   server is known to provide valuable tokens with certain scopes, can a
   malicious resource server trick the client into requesting a more powerful
   token, which it then uses to access some other service? Since the consent
   dialog is likely to show two trusted names (i.e. the requesting client and
   the authorization server), the user would be prone to providing consent,
   even if the scope looks unnecessarily permissive.


Thanks,
Atul

On Tue, Sep 5, 2023 at 6:31 AM George Fletcher <
george.fletc...@capitalone.com> wrote:

> Hi Atul,
>
> I think this is the beginning of a really interesting discussion. I'm
> wondering if we should start a different thread. The recent OAuth Step-up
> spec could help in this regard and static RS documentation could be used to
> describe which scopes are needed for which endpoints. However, as we move
> authorization to be more fine-grained I'm wondering if "scopes" is really
> the right mechanism :)
>
> Thanks,
> George
>
> On Thu, Aug 31, 2023 at 7:51 PM Atul Tulshibagwale  wrote:
>
>> Hi all,
>> I have a couple of questions about the OPRM draft.
>>
>>
>>1. If I have a resource server that has multiple endpoints, each of
>>which require different scopes, how should those be handled? For example,
>>in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a
>>Polling endpoint. The scopes required for these are different. How would
>>the client know which scope is to be used with which endpoint?
>>2. Does the spec encourage insecure behavior in the caller by
>>requesting tokens with scopes that they do not understand? I.e. If an
>>authorization server is known to provide valuable tokens with certain
>>scopes, can a malicious resource server trick the client into requesting a
>>more powerful token, which it then uses to access some other service? 
>> Since
>>the consent dialog is likely to show two trusted names (i.e. the 
>> requesting
>>client and the authorization server), the user would be prone to providing
>>consent, even if the scope looks unnecessarily permissive.
>>
>> Thanks,
>> Atul
>>
>>
>> On Mon, Aug 28, 2023 at 2:28 AM Takahiko Kawasaki 
>> wrote:
>>
>>> I support adoption.
>>>
>>> In the past, when considering the encryption of JWT access tokens, I
>>> learned that the draft regarding the metadata of the resource server had
>>> expired, which was disappointing. For an authorization server to encrypt an
>>> access token with an asymmetric algorithm, it must obtain a public key of
>>> the target resource server, but there was no standardized way. I'm glad to
>>> see the specification has been revived. If it had been revived a bit
>>> earlier, the addition that was made as "client" metadata in the "JWT
>>> Response for OAuth Token Introspection" specification would likely have
>>> been treated as metadata for the "resource server."
>>>
>>> Best Regards,
>>> Takahiko Kawasaki
>>>
>>>
>>> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
 All,

 This is an official call for adoption for the *Protected Resource
 Metadata* draft:
 https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
 

 Please, reply on the mailing list and let us know if you are in favor
 of adopting this draft as WG document, by *Sep 6th.*

 Regards,
  Rifaat & Hannes

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

>>> 

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7631)

[Aaron Parecki]

I agree with this errata, it should have been "authorization code". This
sentence was also removed from OAuth 2.1, since the PKCE code
challenge/code verifier mechanism is a more complete protection against
authorization code substitution.

Aaron

On Tue, Sep 5, 2023 at 6:00 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7631
>
> --
> Type: Editorial
> Reported by: Daiki Usami 
>
> Section: 3.2.1
>
> Original Text
> -
> This protects the client from substitution of the authentication code.
>
> Corrected Text
> --
> This protects the client from substitution of the authorization code.
>
> Notes
> -
> It will be a bit confusing to figure out if it is a MAC or an
> authorization code.
>
> 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.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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 Sender] Re: Call for adoption - Protected Resource Metadata

[George Fletcher]

Hi Atul,

I think this is the beginning of a really interesting discussion. I'm
wondering if we should start a different thread. The recent OAuth Step-up
spec could help in this regard and static RS documentation could be used to
describe which scopes are needed for which endpoints. However, as we move
authorization to be more fine-grained I'm wondering if "scopes" is really
the right mechanism :)

Thanks,
George

On Thu, Aug 31, 2023 at 7:51 PM Atul Tulshibagwale  wrote:

> Hi all,
> I have a couple of questions about the OPRM draft.
>
>
>1. If I have a resource server that has multiple endpoints, each of
>which require different scopes, how should those be handled? For example,
>in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a
>Polling endpoint. The scopes required for these are different. How would
>the client know which scope is to be used with which endpoint?
>2. Does the spec encourage insecure behavior in the caller by
>requesting tokens with scopes that they do not understand? I.e. If an
>authorization server is known to provide valuable tokens with certain
>scopes, can a malicious resource server trick the client into requesting a
>more powerful token, which it then uses to access some other service? Since
>the consent dialog is likely to show two trusted names (i.e. the requesting
>client and the authorization server), the user would be prone to providing
>consent, even if the scope looks unnecessarily permissive.
>
> Thanks,
> Atul
>
>
> On Mon, Aug 28, 2023 at 2:28 AM Takahiko Kawasaki 
> wrote:
>
>> I support adoption.
>>
>> In the past, when considering the encryption of JWT access tokens, I
>> learned that the draft regarding the metadata of the resource server had
>> expired, which was disappointing. For an authorization server to encrypt an
>> access token with an asymmetric algorithm, it must obtain a public key of
>> the target resource server, but there was no standardized way. I'm glad to
>> see the specification has been revived. If it had been revived a bit
>> earlier, the addition that was made as "client" metadata in the "JWT
>> Response for OAuth Token Introspection" specification would likely have
>> been treated as metadata for the "resource server."
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>>
>> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *Protected Resource
>>> Metadata* draft:
>>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>> 
>>>
>>> Please, reply on the mailing list and let us know if you are in favor of
>>> adopting this draft as WG document, by *Sep 6th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0vbvkqcw$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] [Editorial Errata Reported] RFC6749 (7631)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7631

--
Type: Editorial
Reported by: Daiki Usami 

Section: 3.2.1

Original Text
-
This protects the client from substitution of the authentication code.

Corrected Text
--
This protects the client from substitution of the authorization code.

Notes
-
It will be a bit confusing to figure out if it is a MAC or an authorization 
code.

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. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

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