Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

> On 20 Feb 2024, at 06:44, Sachin Mamoru  wrote:
> 
> 
> Hi All,
> 
> When we request an access token using 3 scopes (scope1, scope2, scope3).
> Then will receive a refresh token (refresh_token1) with the access token.
> 
> After that will request another access token with refresh_token1 and provide 
> the scope list as scope1 and scope2 (Narrow down scopes).
> Similarly, get another refresh token (refresh_token2) with the access token.
> 
> Now if we request another access token with refresh_token2, we cannot request 
> scope3, instead, we can either request both scope1 and scope2 or one of them.
> 
> But in the specification, didn't able to find anything related to narrow-down 
> scopes with refresh token.
> 
> From Spec
> 
> 1.5.  Refresh Token - Refresh tokens are issued to the client by the 
> authorization server and are used to obtain a new access token when the 
> current access token becomes invalid or expires or to obtain additional 
> access tokens with identical or narrower scope (access tokens may have a 
> shorter lifetime and fewer permissions than authorized by the resource owner).
> 
> 6.  Refreshing an Access Token
> The scope of the access request as described by Section 3.3.  The requested 
> scope MUST NOT include any scope not originally granted by the resource 
> owner, and if omitted is treated as equal to the scope originally granted by 
> the resource owner.
> 
> https://datatracker.ietf.org/doc/html/rfc6749
> 
> IMO, from a security aspect, the current behaviour is much more secure 
> because it is designed to maintain the principle of least privilege, where it 
> updates the refresh token authorised scopes based on the requested ones.
> 
> What should be the correct behaviour?
> narrow-down scope refresh token should also be able to request access token 
> with original scope list?

Also from section 6:

If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.




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

[OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Sachin Mamoru]

Hi All,

When we request an access token using 3 scopes (scope1, scope2, scope3).

Then will receive a refresh token (refresh_token1) with the access token.

After that will request another access token with refresh_token1 and
provide the scope list as scope1 and scope2 (Narrow down scopes).

Similarly, get another refresh token (refresh_token2) with the access token.

Now if we request another access token with refresh_token2, we cannot
request scope3, instead, we can either request both scope1 and scope2 or
one of them.

But in the specification, didn't able to find anything related to
narrow-down scopes with refresh token.

>From Spec

1.5.  Refresh Token - Refresh tokens are issued to the client by the
authorization server and are used to obtain a new access token when the
current access token becomes invalid or expires or to obtain additional
access tokens with identical or narrower scope (access tokens may have a
shorter lifetime and fewer permissions than authorized by the resource
owner).

6.  Refreshing an Access Token

The scope of the access request as described by Section 3.3.  The requested
scope MUST NOT include any scope not originally granted by the resource
owner, and if omitted is treated as equal to the scope originally granted
by the resource owner.

https://datatracker.ietf.org/doc/html/rfc6749


IMO, from a security aspect, the current behaviour is much more secure
because it is designed to maintain the principle of least privilege, where
it updates the refresh token authorised scopes based on the requested ones.


What should be the correct behaviour?
narrow-down scope refresh token should also be able to request access token
with original scope list?


Your input is highly valuable on this.


Thanks & Regards,
Sachin
-- 

Sachin Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me  
sachinmam...@gmail.com  


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

[OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Sachin Mamoru]

Hi All,

When we request an access token using 3 scopes (scope1, scope2, scope3).

Then will receive a refresh token (refresh_token1) with the access token.

After that will request another access token with refresh_token1 and
provide the scope list as scope1 and scope2 (Narrow down scopes).

Similarly, get another refresh token (refresh_token2) with the access token.

Now if we request another access token with refresh_token2, we cannot
request scope3, instead, we can either request both scope1 and scope2 or
one of them.

But in the specification, didn't able to find anything related to
narrow-down scopes with refresh token.

>From Spec

1.5.  Refresh Token - Refresh tokens are issued to the client by the
authorization server and are used to obtain a new access token when the
current access token becomes invalid or expires or to obtain additional
access tokens with identical or narrower scope (access tokens may have a
shorter lifetime and fewer permissions than authorized by the resource
owner).

6.  Refreshing an Access Token

The scope of the access request as described by Section 3.3.  The requested
scope MUST NOT include any scope not originally granted by the resource
owner, and if omitted is treated as equal to the scope originally granted
by the resource owner.

https://datatracker.ietf.org/doc/html/rfc6749


IMO, from a security aspect, the current behaviour is much more secure
because it is designed to maintain the principle of least privilege, where
it updates the refresh token authorised scopes based on the requested ones.


What should be the correct behaviour?
narrow-down scope refresh token should also be able to request access token
with original scope list?


Your input is highly valuable on this.


Thanks & Regards,
Sachin
-- 

Sachin Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me  
sachinmam...@gmail.com  


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

Re: [OAUTH-WG] OAuth Digest, Vol 184, Issue 24

[Mz Ariez LLC]

Not sure what I'm supposed to send please be detailed in the instructions
please unblock my stake.us account though I can no longer log in using sign
in through my Google

On Thu, Feb 15, 2024, 3:01 PM  wrote:

> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Re: FW: Call for consensus on SPICE charter (nada...@prodigy.net)
>
>
> --
>
> Message: 1
> Date: Thu, 15 Feb 2024 11:36:20 -0800
> From: 
> To: "'Tom Jones'" , "'Roman Danyliw'"
> 
> Cc: "'oauth'" 
> Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
> Message-ID: <07e701da6046$40e704b0$c2b50e10$@prodigy.net>
> Content-Type: text/plain;   charset="UTF-8"
>
> 1) Do you support the charter text? Or do you have objections or blocking
> concerns (please describe what they might be and how you would propose
> addressing the concern)?
>
> Not sure I support at this point, I understand the need for an
> architecture document with patterns and definitions, etc.
>
> There is a lot of work going on outside the IETF in this area such as the
> mDL work in ISO that already has patterns and definitions along with
> credential formats (mdoc)  and transports (ble/http/nfc). I don?t believe
> the IETF should ignore these efforts since most of the driving licence and
> passport communities/companies are adopting this as one of the standards
> that issuers and verifiers will use. The same is true for W3C WebAuthn.
>
> The architecture, patterns and definitions should be free from technology,
> I don't know why W3C is mentioned in the introduction as the only
> technology, this should not be in the introduction but along with other
> technologies such as mDL/mdoc, webauthn, etc when describing profiles. As
> the goal would be for interested parties to produce profiles of other
> technologies to fit the architecture document with patterns and definitions.
>
> I believe that the WG if formed should also think about holder
> verification and patterns and attestations that can be used. Also there
> needs to be a notion of a "reader/wallet/etc" that can potentially store
> credentials (not necessarily the user or verifier) and release/store
> credentials upon "user" consent.
>
> There are other models than the 3 party that VCs use, so these also need
> to be considered in the architecture,  patterns and definitions documents
> to enable profiles for other technologies.
>
> I believe in the 1st 3 items in Goals but  I don't believe it would be in
> the best interest to define a metatdata protocol, as this sounds like this
> would be a protocol for obtaining DID documents, there are already many
> protocols out there for metadata retrieval, not sure there is a need for
> another one, if one is needed for DIDs then that may be better done in W3C
> as this does not seem to fit well with the charter
>
> This charter seems to be very scoped to W3C technology, I understand that
> interested parties will have to contribute if they want to have other
> technologies included but the charter in general does not seem to allow
> this, so removing specific technology will allow this to happen.
>
> I would be happy to give provide specific text changes to the charter.
>
>
> 2) If you do support the charter text:
>
>
> 3) Are you willing to author or participate in the developed of the WG
> drafts?
>
> yes
>
> ? Are you willing to review the WG drafts?
>
> yes
>
> ? Are you interested in implementing the WG drafts?
>
> I'm willing to see how we can use these outputs with the other industry
> technologies.
>
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
>
> End of OAuth Digest, Vol 184, Issue 24
> **
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[Orie Steele]

Inline:

On Mon, Feb 19, 2024, 7:34 PM  wrote:

> Orie, thanks for the response
>
>
>
> I’m still confused on this charter proposal as I read this charter it is
> to create architecture, patterns and definitions for electronic
> credentials. The charter should be free of any technology including W3C, if
> people want clarity about what an electronic credential is then they can
> help out with the definitions since that is an output, so I don’t agree
> with how W3C is mentioned in the charter.
>

As you pointed out below, W3C has defined credentials that are simply
public keys bound to an origin (used as authenticators), and issuer signed
claims about a subject (like JWTs)

So far the people who have been most active seem interested in generalizing
the "signed public key and attributes" version of a digital credential.
That definition lines up well with JWT and CWT with the cnf claim, and mDoc
(as I understand it).

Most of the value W3C VC Data Model provides is focused on creating a
structure for the claims that go in the credential. The security of W3C VCs
based on JWT, SD-JWT, and COSE comes from the IETF drafts not from W3C.

Some of the protocol connection points also come from IETF documents, for
example aud, nonce and cnf.

Most of the value JWT and CWT provide, is through the public claims and
private claims in the associated IANA registries. For example, this is
where the cnf claim that ties proof of possession to credentials is
registered.

It's my understanding that mdocs have a namespace approach to claims as
well.

Creating conventions for claims in a credential format is profiling. iso
mdoc is a profile of COSE Sign1 in that sense.

You can consider the W3C documents that rely on JWT, CWT and COSE as
profiles of those IETF standards. Instead of using JWT or CWT claimsets,
the W3C uses JSON-LD.

A major reason for spice forming was to explore alternative claims
structures, and to align CWT and JWT conventions for credentials that DO
NOT require JSON-LD.

The way I read the charter is that interested parties will work on various
> profiles to map/profile various technologies to the create architecture, 
> patterns
> and definitions documents, this will be done with various members that
> submit drafts.
>
>
>
> Relative to WebAuthn what is produced is a credential, its not a JWT or
> SD-JWT but as the charter reads that is not the only credentials under
> consideration, if this is the case then the charter severely lacks clarity
> on what is the goal.
>

I don't think there is utility in IETF creating a profile for webauthn
based credentials, because they are not meant to be presented beyond the
origin they are bound to.


>
> ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO
> with no issues, I assume profile will be created by various members that
> submit drafts, if no one is interested in mDL/ISO then that’s fine.
>
>
>
> I still think this charter needs more clarity as I point out
>

Can you suggest text?

>
>
>
>
> *From:* Orie Steele 
> *Sent:* Friday, February 16, 2024 10:11 AM
> *To:* nada...@prodigy.net
> *Cc:* Roman Danyliw ; oauth 
> *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
>
>
>
> Hey Tony,
>
>
>
> On Thu, Feb 15, 2024 at 1:36 PM  wrote:
>
> 1) Do you support the charter text? Or do you have objections or blocking
> concerns (please describe what they might be and how you would propose
> addressing the concern)?
>
> Not sure I support at this point, I understand the need for an
> architecture document with patterns and definitions, etc.
>
> There is a lot of work going on outside the IETF in this area such as the
> mDL work in ISO that already has patterns and definitions along with
> credential formats (mdoc)  and transports (ble/http/nfc). I don’t believe
> the IETF should ignore these efforts since most of the driving licence and
> passport communities/companies are adopting this as one of the standards
> that issuers and verifiers will use. The same is true for W3C WebAuthn.
>
>
> WebAuthN cannot produce standard digital signatures, and so it cannot be
> used to produce standard digital credentials (for example it cannot be used
> to produce JWT or SD-JWT).
> It could produce authentications for public keys that could be bound to
> credentials, but because of the origin binding in WebAuthN, this would not
> fit well with the "audience" typically used for digital credentials
> (usually there is no audience)
>
> You might find this thread on possible relation between mDoc and CWT
> interesting:
>
> https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/
>
>
> The architecture, patterns and definitions should be free from technology,
> I don't know why W3C is mentioned in the introduction as the only
> technology, this should not be in the introduction but along with other
> technologies such as mDL/mdoc, webauthn, etc when describing profiles. As
> the goal would be for interested parties to produce profiles of other

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[nadalin]

Orie, thanks for the response

 

I’m still confused on this charter proposal as I read this charter it is to 
create architecture, patterns and definitions for electronic credentials. The 
charter should be free of any technology including W3C, if people want clarity 
about what an electronic credential is then they can help out with the 
definitions since that is an output, so I don’t agree with how W3C is mentioned 
in the charter. The way I read the charter is that interested parties will work 
on various profiles to map/profile various technologies to the create 
architecture, patterns and definitions documents, this will be done with 
various members that submit drafts.

 

Relative to WebAuthn what is produced is a credential, its not a JWT or SD-JWT 
but as the charter reads that is not the only credentials under consideration, 
if this is the case then the charter severely lacks clarity on what is the goal.

 

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO with no 
issues, I assume profile will be created by various members that submit drafts, 
if no one is interested in mDL/ISO then that’s fine.

 

I still think this charter needs more clarity as I point out

 

 

From: Orie Steele  
Sent: Friday, February 16, 2024 10:11 AM
To: nada...@prodigy.net
Cc: Roman Danyliw ; oauth 
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Hey Tony,

 

On Thu, Feb 15, 2024 at 1:36 PM mailto:nada...@prodigy.net> > wrote:

1) Do you support the charter text? Or do you have objections or blocking 
concerns (please describe what they might be and how you would propose 
addressing the concern)?

Not sure I support at this point, I understand the need for an architecture 
document with patterns and definitions, etc. 

There is a lot of work going on outside the IETF in this area such as the mDL 
work in ISO that already has patterns and definitions along with credential 
formats (mdoc)  and transports (ble/http/nfc). I don’t believe the IETF should 
ignore these efforts since most of the driving licence and passport 
communities/companies are adopting this as one of the standards that issuers 
and verifiers will use. The same is true for W3C WebAuthn.


WebAuthN cannot produce standard digital signatures, and so it cannot be used 
to produce standard digital credentials (for example it cannot be used to 
produce JWT or SD-JWT).
It could produce authentications for public keys that could be bound to 
credentials, but because of the origin binding in WebAuthN, this would not fit 
well with the "audience" typically used for digital credentials (usually there 
is no audience)

You might find this thread on possible relation between mDoc and CWT 
interesting:

https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/


The architecture, patterns and definitions should be free from technology, I 
don't know why W3C is mentioned in the introduction as the only technology, 
this should not be in the introduction but along with other technologies such 
as mDL/mdoc, webauthn, etc when describing profiles. As the goal would be for 
interested parties to produce profiles of other technologies to fit the 
architecture document with patterns and definitions.


W3C is mentioned because some W3C members asked for a term other than 
"Verifiable Credentials" to be used... and they asserted the "Verifiable 
Credentials" implies the JSON-LD data model developed in W3C.

ISO was not emphasized because formal coordination would require contribution 
from ISO experts, and we have had relatively low engagement from them.
 


I believe that the WG if formed should also think about holder verification and 
patterns and attestations that can be used.

 

Interesting. I think this is covered under the metadata discovery deliverable, 
but if you feel it could be made more clear, please send text.

 

Also there needs to be a notion of a "reader/wallet/etc" that can potentially 
store credentials (not necessarily the user or verifier) and release/store 
credentials upon "user" consent.


This sounds like an application to me.
How do you see this related to "credential formats" or "issuer/holder/verifier 
metadata"?
 



There are other models than the 3 party that VCs use, so these also need to be 
considered in the architecture,  patterns and definitions documents to enable 
profiles for other technologies.


Agreed, OAuth JWTs/SD-JWTs, and ISO mDocs are examples we have discussed.
Are there others you would like to see considered?  



I believe in the 1st 3 items in Goals but  I don't believe it would be in the 
best interest to define a metatdata protocol, as this sounds like this would be 
a protocol for obtaining DID documents, there are already many protocols out 
there for metadata retrieval, not sure there is a need for another one, if one 
is needed for DIDs then that may be better done in W3C as this does not seem to 
fit well with the charter


Discovering attestations for 

[OAUTH-WG] Fwd: [media-types] Last tracker issue for mediaman-suffixes

[Orie Steele]

See the following PR related to registrations of media types that rely on
multiple structured suffixes, for example:

application/foo+bar+cose would require `+bar+cose` , `+cose`
application/foo+bar+jwt would require `+bar+jwt`, `+bar+jwt`
application/foo+bar+sd-jwt would require `+bar+sd-jwt`, `+sd-jwt`

Manu, please make sure I translated the text from the PR to examples
meaningful to the JOSE, COSE and OAuth working groups.

If you feel this message should be reviewed by other lists, for example:

- https://openid.net/wg/digital-credentials-protocols/
- https://www.w3.org/community/wicg/

Please forward a link along to them.

For context, the intention of the W3C VCWG appears to be to register a lot
of media types relying on structured suffixes:

For example:

application/vc+ld+json -
https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240218/#iana-considerations
application/vp+ld+json -
https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240218/#iana-considerations

application/vc+ld+json+jwt - https://w3c.github.io/vc-jose-cose/#media-types
application/vp+ld+json+jwt - https://w3c.github.io/vc-jose-cose/#media-types

application/vc+ld+json+sd-jwt -
https://w3c.github.io/vc-jose-cose/#media-types
application/vp+ld+json+sd-jwt -
https://w3c.github.io/vc-jose-cose/#media-types

application/vc+ld+json+cose -
https://w3c.github.io/vc-jose-cose/#media-types
application/vp+ld+json+cose -
https://w3c.github.io/vc-jose-cose/#media-types

+jwt is already registered
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
 ( https://www.rfc-editor.org/rfc/rfc8417.html#section-7.2 )

+ld+json is requested to be registered in
https://w3c.github.io/json-ld-syntax/#structured-extension-ld-json (an W3C
Editors draft)
+sd-jwt is requested to be registered in
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-07#name-structured-syntax-suffix-re
(not
yet an RFC)
+cose is requested to be registered in
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-16.5
(not
yet an RFC)

My understanding of the proposed PR text would be that there is no need to
register additional structured suffixes to support the intention of the W3C
VCWG, because:

All the suffixes mentioned above are either already registered (+jwt), or
in the process of being registered (+ld+json, +sd-jwt, +cose).

After all the suffixes have been registered, it will then be possible to
request registrations of subtypes that rely on them, namely:

application/vc+...
application/vp+...

We may also see additional structured syntax suffixes registered for other
security formats in the future, for example:

application/cesr might register +cesr
-
https://mailarchive.ietf.org/arch/msg/i-d-announce/FvL1rLC1SCyTBRnu92At9Wncd2Y/

-
https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml#Samuel_M._Smith

I can imagine perhaps `+mdoc` in the future, or perhaps mdoc might use
`+cose` since AFAIK, mdocs are cose-sign1 based credentials.

I'd like to see the suffixes draft make it to WGLC (with more reviews), and
appreciate Manu sending this email out in order to gather feedback with
sufficient time to address it before 119.

Regards,

OS

-- Forwarded message -
From: Manu Sporny 
Date: Mon, Feb 19, 2024 at 12:44 PM
Subject: [media-types] Last tracker issue for mediaman-suffixes
To: IETF Media Types 


The only item of concern that was raised during the last IETF was the
notion that one wouldn't have to register "intermediate" suffixes[1].
The PR above corrects that by implementing what I believe many of the
people in the room (and on the tracker) were arguing for, including
Alexi and Darrel:

https://github.com/ietf-wg-mediaman/suffixes/pull/21

That is the last PR for the last tracker issue for the
mediaman-suffixes draft. Speaking as an Editor, I think we're done
here with all of the items that we can get consensus on (we'll see if
others disagree).

Once I have enough reviews on the PR above (end of week, probably),
I'll cut a new version of the draft and send it out for review (next
weekend, probably) before the next IETF.

-- manu

[1]https://github.com/ietf-wg-mediaman/suffixes/issues/20

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

___
media-types mailing list
media-ty...@ietf.org
https://www.ietf.org/mailman/listinfo/media-types


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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

[OAUTH-WG] I-D Action: draft-ietf-oauth-identity-chaining-01.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-identity-chaining-01.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth Identity and Authorization Chaining Across Domains
   Authors: Arndt Schwenkschuster
Pieter Kasselmann
Kelley Burgin
Mike Jenkins
Brian Campbell
   Name:draft-ietf-oauth-identity-chaining-01.txt
   Pages:   18
   Dates:   2024-02-19

Abstract:

   This specification defines a mechanism to preserve identity
   information and federate authorization across trust domains that use
   the OAuth 2.0 Framework.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-identity-chaining.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-identity-chaining-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [OAUTH-WG] OAuth browser based apps with first-party same-domain apps

[Kai Lehmann]

Hi Aaron,

(To be honest, I haven’t expected to receive feedback for my inquiry after that 
long timespan. I thought my question was lost due to IETF going on at the time.)

Thanks for taking the time to answer. The draft you mentioned looks 
interesting, although I don’t think it fits our purposes. I have a few concerns 
regarding the draft and I hope Jared is subscribed to the mailing list as well. 
My main concern with the approach in the draft is that the access token would 
not be issued to a specific client, but to the user agent itself. If the the 
user navigates to another client after the access token was returned with 
Set-Cookie, this other client could just initiate requests to the Resource 
Server and the browser would send the cookie with the AT along. This AT in the 
cookie may have a scope which the other client was not supposed to receive in 
the first place. All clients are essentially sharing the AT in the cookie 
instead of each client having their own AT issued.

Furthermore, the cookie with the AT would need to be set on a domain which is 
shared by the AS and all RS which would accept this AT via cookie. That usually 
means that this cookie would need to be set on the eTLD+1. It also means that 
web servers running on any subdomain of that TLD+1 will receive that cookie/AT 
with each and every request done by the user agent, even if this request is not 
related to accessing protected resources.


The approach I mentioned has similarities with FedCM: The user agent already 
has a login session which is bound with a session cookie to the (sub-)domain of 
the AS only and the AS can issue access tokens to SPA clients running in the 
user agent using Fetch API calls. The ATs are issued to specific clients and 
can have individual scopes. The RS accept the AT as usual as Bearer Token in 
the Authorization header. The difference is, that we do not need FedCM as the 
login session cookie is set and used in first-party context.

One of our main concerns was the redirects which we wanted to avoid. You 
mentioned that the authorize endpoint may already have some logic which would 
be required to be implemented on the token endpoint for this approach (e.g. 
what clients are allowed and so on) which is a valid point. An in-between 
approach might be to allow POST requests with the necessary parameters on the 
authorize endpoint (similar to the approach in 
https://www.ietf.org/archive/id/draft-meyerzuselha-oauth-web-message-response-mode-00.html)
 and return the authcode within a JSON body. Then the SPA client could take the 
authcode to the token endpoint to fetch the AT. That would be two requests 
instead of one, but they can both be performed from within the SPA without the 
need to redirect and giving up control.

If you like, we can talk about it at the upcoming OSW and see if there is some 
interest for this scenario within the Oauth community.

Best regards,
Kai



From: OAuth  on behalf of Aaron Parecki 

Date: Saturday, 17. February 2024 at 01:13
To: OAuth WG , Kai Lehmann 

Subject: Re: [OAUTH-WG] OAuth browser based apps with first-party same-domain 
apps

Hi Kai,

This sounds similar to an approach described in this draft, although never 
actually implemented as far as I know: 
https://www.ietf.org/archive/id/draft-hanson-oauth-cookie-response-mode-00.html

The main difference is the hanson draft does a redirect to the authorization 
endpoint, but the access token is still returned by setting a cookie. There are 
a few advantages of this approach over submitting a POST to the token endpoint 
directly:

• Leverages existing infrastructure at the authorization endpoint, including 
rate limits, CSRF protection, bot protection, etc
• Leverages existing logic at the authorization endpoint for applying policies 
of the request, things like which clients can request which scopes, etc, rather 
than having to redefine all the authorization parameters at the token endpoint

Since you have to do a redirect the first time the user logs in anyway, the 
hanson draft is faster for the first login. I could imagine trying to find an 
optimization for the case where the browser wants to refresh the token while 
the session at the AS is still active, so maybe we could extend that to support 
that use case instead of having to do a full redirect as often.

In any case, both of these approaches are far too experimental to consider 
adding to the Browser Apps BCP right now. But I do think there is something 
here worth exploring in the future.

Aaron



On Mon, Nov 6, 2023 at 5:22 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:


From: Kai Lehmann mailto:kai.lehm...@1und1.de>>
Date: Monday, 6. November 2023 at 07:48
To: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Subject: OAuth browser based apps with first-party same-domain apps

Hi,

I’ve been reading through the recent update of the draft for using OAuth in 
browser based apps and highly appreciate the excellent work.