Yes, there isn’t a clear solution to this problem. My main concern at this
point is that we don’t give the impression that an AS can establish security
boundaries or prevent token mix up by using different keys. The text changes
you suggest would address that.
–
Annabelle Backman (she/her)
AWS
OK, I caught up with the discussion. Very interesting.
It seems that the conclusion is that there’s no simple mechanism we can add at
this point that would easily gel with existing deployment, hence either we tell
people to STOP using multiple keys, or we make them aware of the futility of
doing
Oh wow, I completely missed that thread. Thanks for the link. Reading…
From: OAuth on behalf of "Richard Backman, Annabelle"
Date: Wednesday, March 25, 2020 at 14:26
To: "vittorio.bertocci=40auth0@dmarc.ietf.org"
, 'George Fletcher'
, 'Brian Campbell'
Cc: 'oauth'
Subject: Re: [OAUTH-WG
I think I am missing something here. It’s not that I don’t want to give
guidance, is that it seems that the guidance you are thinking of isn’t
necessary unless we think that enforcing explicitkey-token type assignment
declaration is necessary. I didn’t get the impression that it was the proposal
It seems to me that leaving that out of scope is rather antithetical to the
previously stated reason for the profile using only asymmetric signatures,
namely that "this profile focuses on a solution that is as close to turnkey
as possible for developers." And I'd suggest that, to borrow your words,
Thanks Aaron!
You are right, we could be clearer re:errors. AFAIK the only errors we can
rely on from an RS are in RFC6750, and the entire section is about what to
look for in an incoming AT to validate, hence it doesn't look like we have
much choice but to return invalid_token for every error in t
Section 4 talks about validating JWT Access Tokens
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-4
It has a list of things the RS MUST do when validating a request made
with a JWT access token. This section contains phrases like "...and
reject tokens..." and "MUST be re
That works for me!
From: George Fletcher
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian Campbell'
Cc: 'Brian Campbell' ; 'oauth'
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"
If we don't want to give guidan
If we don't want to give guidance on how the RS determines the correct
key to use to validate the token, then maybe we should state that
explicitly. "The mechanism used by the RS to determine the correct key
to use to validate the access token is out of scope for this specification".
That way
Brian, there are plenty of ways in which an RS can surprise you with odd
behavior- for example, developers might see that you used a key for signing an
IDtoken and use that for init all their validation middleware for ATs as well,
say because the library only supports one key at a time, and then
More specifically, SSO will not work anymore without either:
- prompting the user (via Storage Access API)
- using explicit front-channel mechanisms (popups and redirects)
- using back-channel mechanisms (refresh tokens and some backchannel logout
infrastructure)
(FWIW, I proposed a back-channel
I don't think you are missing anything, George (except that, to be
pedantic, `kid` is a header rather than a claim).
The question gave me pause, however, and makes me think that maybe the
draft, with the aim of improved interoperability, should have some more
explicit text about the use of the 'ki
> On 25. Mar 2020, at 14:55, Dominick Baier wrote:
>
> This
>
> https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
>
> Really means that “modern” SPAs based on a combination of OIDC and OAuth will
> not work anymore
>
> both
>
> * silent-renew for access token managem
Can we not use the 'kid' claim to inform the RS as to which key is being
used? What am I missing?
On 3/25/20 1:51 PM, Brian Campbell wrote:
I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enoug
I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"A
Thank you for the perspective- I guessed something similar (“there would be no
way for the RS to know what key is used for what").
As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for the
reasons liste
Fair. I went back to the aggregated research rather than the individual emails
and I did find those samples from you- thanks for pointing this out.
Nonetheless, I don’t think this changes the main argument. Symmetric isn’t
disallowed, it just cannot give a complete end to end solution that would
I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri.
O
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci wrote:
> *>4 p1: Saying asymmetric signatures are RECOMMENDED presupposes that key
> distribution is the implementer’s primary concern. MAC-based
> implementations shouldn’t be seen as some weird edge case scenario (though
> it’d be worth includin
This
https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
Really means that “modern” SPAs based on a combination of OIDC and OAuth
will not work anymore
both
* silent-renew for access token management
* OIDC JS session notifications
Will not work anymore. Or don’t work anym
Thank you for the kind words and the super thorough review, Annabelle!
Comments inline. I’ll reply to the aud/scope thread tomorrow.
>4 p1: Saying asymmetric signatures are RECOMMENDED presupposes that key
>distribution is the implementer’s primary concern. MAC-based implementations
>shouldn’t b
21 matches
Mail list logo
