Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

[Brian Campbell]

On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha  wrote:

> Find bellow my review of the draft:
>
>
>1. Redactional changes:
>
> 2.2.  Authorization Data Types
>
>
> Interpretation of the value of the "type" parameter, and the object
>
>elements that the "type" parameter allows => allowed
>
>
>
The "allows" seems correct there.



> 9.  Metadata
>
> which is an
>
>JSON array. => which is a JSON array
>

Fixed this in the document source. Thanks!


>
>1. Application to existing APIs
>
> reason-1: Current open banking initiatives are built on the of existing
> Data Standards like ISO20022 (PAIN, CAMT) which are XML's that do not
> provide direct translation to JSON. Some authorization server's might even
> be able to parse an ISO PAIN file to display the proper authorization
> request to the user.
>

That the APIs are XML doesn't necessarily mean that the details of the
authorization can't be represented in JSON. And, if really need be, XML can
be included as the value of some member in the authorization details and
defined as such by the type.



> reason-2: In some situation, it might be more privacy preserving to have
> the authorization request content negotiated between the AS and the RS. In
> this case the "scope" parameter shall only carry some sort of "grant-id"
> (known in the Berlin Group spec as consent-id). This will allow the AS to
> negotiate the data to be displayed directly with the RS.
>

RAR probably just isn't applicable in that kind of case.



>
> Any idea how to consider these two edge cases?
>




> Best regards.
> /Francis
>
>
> --
> *From:* OAuth  on behalf of Torsten Lodderstedt
> 
> *Sent:* Sunday, February 7, 2021 12:49 PM
> *To:* oauth 
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
>
> Hi all,
>
> here is the list of changes in revision -04:
>
>
>- restructured draft for better readability
>- simplified normative text about use of the resource parameter with
>authorization_details
>- added implementation considerations for deployments and products
>- added type union language from GNAP
>- added recommendation to use PAR to cope with large requests and for
>request protection
>
>
> Your feedback is highly appreciated.
>
> best regards,
> Torsten.
>
> Am 07.02.2021 um 13:42 schrieb internet-dra...@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>Title   : OAuth 2.0 Rich Authorization Requests
>Authors : Torsten Lodderstedt
>  Justin Richer
>  Brian Campbell
> Filename: draft-ietf-oauth-rar-04.txt
> Pages   : 36
> Date: 2021-02-07
>
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
>
>
> The IETF datatracker status page for this draft is:
>
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/=gmail-imap=161330655700=AOvVaw3-4SmuMFgxbz-cDK2Ir_a7
>
> There is also an HTML version available at:
>
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html=gmail-imap=161330655700=AOvVaw1J52xGTvk1ZAuBC_fUAIjJ
>
> A diff from the previous version is available at:
>
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-04=gmail-imap=161330655700=AOvVaw0TYqmFwryvAYznR2Ho5Oj6
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=161330655700=AOvVaw06g1z6o36BkkaqkiWc1Lw9
>
>
> ___
> 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-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Vittorio Bertocci]

Dear all,
Brian and yours truly are proposing a new specification that shows how the user 
agent frontend of a web app can delegate token acquisition and persistence to 
its backend, and request such tokens when needed for direct access of protected 
resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern 
development stacks, such as Next.JS. Variants of the pattern, often discussed 
under the catch-all term BFF (backend for frontend), have been often mentioned 
in this workgroup’s activity, but always left all implementation details to the 
reader.
We believe the pattern has merit, as corroborated by its growing adoption. By 
delegating access token acquisition to the backend, we avoid many of the often 
brittle moving parts (and implied attack surface) required to acquire access 
tokens from a user agent. The topology also relieves the frontend from the need 
of persisting tokens in local storage, a well known sore point of using OAuth 
directly in JavaScript, by relying on its backend storage and session to 
preserve tokens.

Although the specification is very simple, providing explicit guidance on the 
scenario offers many advantages.  
- It makes it possible to create interoperable SDKs, where frontend dev stacks 
(any JS flavor) can be mixed and matched with compliant backend stacks 
(middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario and 
warn implementers against security risks (scope escalations, using IDtokens 
instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as part 
of the browser apps security guidance, and position the scenario where frontend 
only calls API on its own backed (hence doesn’t need access tokens) simply as a 
special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventing 
developers from weakening the security of their system (eg turning on ROPG 
options)  or turning to risky practices like scraping

Needless to say, this specification doesn’t entirely eliminate the risks 
inherent to direct use of access tokens from a browser. But reality is that the 
pattern is in widespread use, and the circumstances leading to that (eg 
developers on a particular project only work with frontend stacks; components 
like reverse proxies might not always be viable; etc) aren’t going away any 
time soon. By providing simple guidance on this pattern, we can simplify the 
life of many developers while enshrining basic security hygiene in scenarios 
that would have otherwise be left to their own device.
 
Looking forward for your feedback!

B  

On 2/12/21, 12:41, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to the
IETF repository.

Name:   draft-bertocci-oauth2-tmi-bff
Revision:   00
Title:  Token Mediating and session Information Backend For 
Frontend
Document date:  2021-02-12
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Html:   
https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
Htmlized:   https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


Abstract:
   This document describes how a JavaScript frontend can delegate access
   token acquisition to a backend component.  In so doing, the frontend
   can access resource servers directly without taking on the burden of
   communicating with the authorization server, persisting tokens, and
   performing operations that are fraught with security challenges when
   executed in a user agent, but are safe and well proven when executed
   by a confidential client running on a backend.


  


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



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

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Neil Madden]

> On 11 Feb 2021, at 21:43, Andrii Deinega  wrote:
> 
> 
> Thank you for the response! Unfortunately, I'm still not convinced that there 
> is no need for nonce.
>  
> Based on the draft, I don't know how it's possible to achieve a “stronger 
> assurance that the authorizationserver issued the token introspection 
> response for an access token, includingcases where the authorization server 
> assumes liability for the content of thetoken introspection response” if we 
> can't guarantee that a client will always get the response to its initial 
> introspect request, or in other words, old communications can be never reused 
> (the iat claim isn't going to be sufficient for that).

The whole point about liability is being able to establish it after the fact. A 
nonce is only meaningful within the initial interaction and so is no help at 
all for establishing liability. 

>  
> Let's put aside those attackers for a moment and say we experience some 
> awfully wrong caching issues that can happen anywhere between an AS and a 
> client... where the client gets a cached response for its previous requests 
> which isn't expected. How can it be prevented?

1. TLS. 2. Cache-Control. 

— Neil

-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth