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

[Richard Backman, Annabelle]

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 Identity
https://aws.amazon.com/identity/


From: Vittorio Bertocci 
Date: Wednesday, March 25, 2020 at 5:10 PM
To: "Richard Backman, Annabelle" , 
"vittorio.bertocci=40auth0@dmarc.ietf.org" , 
'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token 
(JWT) Profile for OAuth 2.0 Access Tokens"

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 so as a way of enforcing security boundaries.
Is that the correct conclusion? If yes, I would suggest we use the language I 
suggested in Brian’s thread (“The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs”) to warn the RS developer that 
the AS could do that, and in the security section we warn the AS developer that 
using multiple keys won’t help much given that the RS won’t differentiate 
between tokens signed with keys from the same metadata collection anyway, hence 
it’s enough to compromise one key to generate tokens that will be accepted 
regardless of type or any other classification.
WDYT?

From: Vittorio Bertocci 
Date: Wednesday, March 25, 2020 at 16:53
To: "Richard Backman, Annabelle" , 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 
, 'George Fletcher' 
, 'Brian Campbell' 

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

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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

This is another manifestation of the limits of jwks_uri that I’ve brought up on 
the list 
previously.

Using different signing keys does not actually limit the blast radius of each 
key, since the validator doesn’t know that each key should only be considered 
valid for one type of token. This takes away one of the major drivers for using 
different keys. If the text says deployments can use different keys, it needs 
to clarify the limited value of that.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth  on behalf of 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 

Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


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 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 at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future.



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is 

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

[Vittorio Bertocci]

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 so as a way of enforcing security boundaries.
Is that the correct conclusion? If yes, I would suggest we use the language I 
suggested in Brian’s thread (“The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs”) to warn the RS developer that 
the AS could do that, and in the security section we warn the AS developer that 
using multiple keys won’t help much given that the RS won’t differentiate 
between tokens signed with keys from the same metadata collection anyway, hence 
it’s enough to compromise one key to generate tokens that will be accepted 
regardless of type or any other classification..
WDYT?

From: Vittorio Bertocci 
Date: Wednesday, March 25, 2020 at 16:53
To: "Richard Backman, Annabelle" , 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 
, 'George Fletcher' 
, 'Brian Campbell' 

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

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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

This is another manifestation of the limits of jwks_uri that I’ve brought up on 
the list 
previously.

Using different signing keys does not actually limit the blast radius of each 
key, since the validator doesn’t know that each key should only be considered 
valid for one type of token. This takes away one of the major drivers for using 
different keys. If the text says deployments can use different keys, it needs 
to clarify the limited value of that.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth  on behalf of 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 

Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

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 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 at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.







From: Brian Campbell 


Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher 

Cc: Brian Campbell 
; Vittorio 
Bertocci ; 
oauth 

Subject: Re: [OAUTH-WG] WGLC on 

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

[Vittorio Bertocci]

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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

This is another manifestation of the limits of jwks_uri that I’ve brought up on 
the list 
previously.

Using different signing keys does not actually limit the blast radius of each 
key, since the validator doesn’t know that each key should only be considered 
valid for one type of token. This takes away one of the major drivers for using 
different keys. If the text says deployments can use different keys, it needs 
to clarify the limited value of that.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth  on behalf of 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 

Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

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 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 at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.







From: Brian Campbell 


Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher 

Cc: Brian Campbell 
; Vittorio 
Bertocci ; 
oauth 

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







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 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri.























On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org> 
 > wrote:



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

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,

"An authorization server MAY elect to use different keys to sign id_tokens

and JWT access tokens."? Just a thought anyway.



On Wed, 

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

[Vittorio Bertocci]

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 
so far, what I have read was “if the intent was to prevent token 
confusion/substitution, this is insufficient”, to which the answer was “that 
was not the intent”.
And if preventing token substitution/confusion is not the aim, then the only 
guidance required here to the RS is “expect that any key published in the doc 
pointed by jwks_uri could be used to sign the AT” which seems actionable enough.
I do agree that the language could be more explicitly aimed at that outcome.. 
Would something to the effect of “The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs” work better?

From: Brian Campbell 
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci 
Cc: George Fletcher , Brian Campbell 
, oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

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, looking 
at this from the useful guidance standpoint rather than the “lawyering up” 
perspective, some guidance on determining the correct key to use from the keys 
at the jwks_uri to verify the signature on the AT would be very useful in 
general and also prevent the kind of potential missteps you described. I mean, 
if nothing is said about it or even if it'd said to be out of scope, a working 
interoperable approach could probably be inferred by knowing and applying bits 
of JWS, JWA, JWK, etc.. But, to me anyway, it seems incongruent to expect folks 
to figure all that out but at the same time believe them capable of mistakes 
that would be prevented by only pointing out that ATs and ID tokens might be 
signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that 
kind of guidance in the Asymmetric bit of 
https://openid.net/specs/openid-connect-core-1_0.html#Signing and 
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's not 
perfect (this 
issue
 was raised just recently) but attempts to convey how verification key 
selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this one. 
And I've spent more time here than I'd like to admit so I won't argue it 
further.



On Wed, Mar 25, 2020 at 12:57 PM 
mailto:vittorio.berto...@auth0.com>> wrote:
That works for me!

From: George Fletcher mailto:gffle...@aol.com>>
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian 
Campbell' 
mailto:40pingidentity@dmarc.ietf.org>>
Cc: 'Brian Campbell' 
mailto:bcampb...@pingidentity.com>>; 'oauth' 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

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 at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more 

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

[Brian Campbell]

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,
looking at this from the useful guidance standpoint rather than the
“lawyering up” perspective, some guidance on determining the correct key to
use from the keys at the jwks_uri to verify the signature on the AT would
be very useful in general and also prevent the kind of potential missteps
you described. I mean, if nothing is said about it or even if it'd said to
be out of scope, a working interoperable approach could probably be
inferred by knowing and applying bits of JWS, JWA, JWK, etc.. But, to me
anyway, it seems incongruent to expect folks to figure all that out but at
the same time believe them capable of mistakes that would be prevented by
only pointing out that ATs and ID tokens might be signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that
kind of guidance in the Asymmetric bit of
https://openid.net/specs/openid-connect-core-1_0.html#Signing and
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's
not perfect (this issue

was raised just recently) but attempts to convey how verification key
selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this
one. And I've spent more time here than I'd like to admit so I won't argue
it further.



On Wed, Mar 25, 2020 at 12:57 PM  wrote:

> That works for me!
>
>
>
> *From:* George Fletcher 
> *Sent:* Wednesday, March 25, 2020 11:56 AM
> *To:* vittorio.berto...@auth0.com; 'Brian Campbell'  40pingidentity@dmarc.ietf.org>
> *Cc:* 'Brian Campbell' ; 'oauth' <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> 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 at least we are being very clear that the spec is not trying to
> specify how that happens.
>
> Thoughts?
>
> On 3/25/20 2:44 PM, vittorio.berto...@auth0.com wrote:
>
> 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 end 
> up failing at runtime when/if the assumption ceases to apply in the future.
>
>
>
> Would that be legitimate of them to take such a dependency, even without 
> warning text? No. However I am not looking at this from the “lawyering up” 
> perspective, but from the useful guidance standpoint as well. I am well aware 
> that being concise is a feature, but I am also not crazy about making every 
> specification into an intelligence test for the reader. If a 16 words 
> sentence can help prevent a likely misstep, I’d be inclined to keep it. But 
> if the consensus is that the sentence is confusing, I can also take it out.
>
>
>
>
>
> Brian & George, in the spirit of keeping things simple, and given that this 
> was more of a “just in case” warning rather than a security feature clamored 
> for- if the language is problematic I’d be more inclined to take the sentence 
> out rather than complicating the guidance further.
>
>
>
>
>
> From: Brian Campbell  
> 
>
> Sent: Wednesday, March 25, 2020 11:21 AM
>
> To: George Fletcher  
>
> Cc: Brian Campbell  ; 
> Vittorio Bertocci  
> ; oauth  
>
> Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2..0 
> Access Tokens"
>
>
>
>
>
> 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 'kid' header in a JWT AT and how it references the 
> verification key in the content at the jwks_uri.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
> mailto:40aol@dmarc.ietf.org> 
> <40aol@dmarc.ietf.org> > wrote:
>
>
>
> 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
>
> enough but I can't 

Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens

[vittorio . bertocci=40auth0 . com]

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 the validation
checks enumerated in Section 4. I can definitely add a paragraph to that
effect (does it have to be a section?).

The re-authentication part is tricky. Technically we are still rejecting the
incoming token, hence the above should still apply.
I am not aware of tools we can use from the primitives defined in the OAuth2
family of standards for telling people how to make reauthentication happen-
and making reauth happen can be quite involved. In Azure AD there are semi
proprietary mechanisms that can be used to signal the need to repeat
authentication, say for triggering a step-up auth, by sending back together
with the error response a challenge that can in turn be used by the client
to communicate policy requirements to the AS (which is assumed to support
OIDC and accept/understand those policies in form of claim). Giving
equivalent guidance but relying only on standards seems tricky, especially
without making strong assumptions about how auth happens (e.g can we assume
OIDC?).
To solve this for the profile, I see two main ways forward:
A) We warn the reader that it's on them to decide how to signal the reauth
requirement from the API to the client, and how to use that in the client to
AS subsequent authorization request
B) We venture in devising a standard mechanism for propagating errors that
require reauth, basically extending RFC6750 with a new use case (perhaps by
detailing extra info to be put in WWW-Authenticate?).

I can see how B) might be useful in general, but it doesn't seem
particularly tied to the fact that the ATs being discussed here are JWTs...
hence I'd be inclined to declare it out of scope here, tho I would really
love for us to devise a standard solution for it _somewhere_.
WDYT?



-Original Message-
From: OAuth  On Behalf Of Aaron Parecki
Sent: Wednesday, March 25, 2020 12:07 PM
To: OAuth WG 
Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access
Tokens

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 rejected if...", without clear instructions on *how*
to reject this request. For these, I could infer that the RFC6750 error code
"invalid_token" is the correct response, but these could benefit from being
more explicit about that here.

Step 7 says:  "the resource server SHOULD check the auth_time value and
request re-authentication..." But there are no instructions on how the RS
should respond to indicate that the client should request re-authentication.
This sounds like a different response than "invalid_token" to me, but in any
case, regardless of what the correct response is, Section 4 really needs a
description of how to respond in these error cases.


Aaron Parecki
aaronparecki.com
@aaronpk

___
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] Error Responses in JWT Profile for OAuth 2.0 Access Tokens

[Aaron Parecki]

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 rejected if...", without clear
instructions on *how* to reject this request. For these, I could infer
that the RFC6750 error code "invalid_token" is the correct response,
but these could benefit from being more explicit about that here.

Step 7 says:  "the resource server SHOULD check the auth_time value
and request re-authentication..." But there are no instructions on how
the RS should respond to indicate that the client should request
re-authentication. This sounds like a different response than
"invalid_token" to me, but in any case, regardless of what the correct
response is, Section 4 really needs a description of how to respond in
these error cases.


Aaron Parecki
aaronparecki.com
@aaronpk

___
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"

[vittorio . bertocci=40auth0 . com]

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 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 at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?

On 3/25/20 2:44 PM, vittorio.berto...@auth0.com 
  wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future.
 
Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.
 
 
 
Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.
 
 
 
From: Brian Campbell   
 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher   
Cc: Brian Campbell   
; Vittorio Bertocci  
 ; oauth  
 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"
 
 
 
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 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri. 
 
 
 
 
 
 
 
 
 
 
 
On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org>   
  > wrote:
 
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
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,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
 
On Wed, Mar 25, 2020 at 10:11 AM mailto:40auth0@dmarc.ietf.org>   
  > wrote:
 
 
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 listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
 
 
 
*From:* Brian Campbell    
  
 

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci    
   

*Cc:* Richard Backman, Annabelle    
   
; oauth <
oauth@ietf.org     
 >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
 
 
 
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 

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

[George Fletcher]

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 at least we are being very clear that the spec is not trying to 
specify how that happens.


Thoughts?

On 3/25/20 2:44 PM, vittorio.berto...@auth0.com wrote:

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 end up 
failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.

  


Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- if 
the language is problematic I’d be more inclined to take the sentence out rather 
than complicating the guidance further.

  


From: Brian Campbell 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher 
Cc: Brian Campbell ; Vittorio Bertocci 
; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens"

  


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 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri.

  

  

  

  

  


On Wed, Mar 25, 2020 at 11:54 AM George Fletcher mailto:40aol@dmarc.ietf.org> > wrote:

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
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,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
  
On Wed, Mar 25, 2020 at 10:11 AM 
40auth0@dmarc.ietf.org  > wrote:
  


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 listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
  
  
  
*From:* Brian Campbell   

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci   

*Cc:* Richard Backman, Annabelle   
; oauth <
oauth@ietf.org  >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
  
  
  
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..
  
  
  
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
40auth0@dmarc.ietf.org  > wrote:
  
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with

different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
  
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they

all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for 

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

[vittorio . bertocci=40auth0 . com]

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 end up 
failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.

 

Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher 
Cc: Brian Campbell ; Vittorio Bertocci 
; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

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 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri. 

 

 

 

 

 

On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:40aol@dmarc.ietf.org> > wrote:

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
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,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
 
On Wed, Mar 25, 2020 at 10:11 AM mailto:40auth0@dmarc.ietf.org> > wrote:
 

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 listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
 
 
 
*From:* Brian Campbell   

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci   

*Cc:* Richard Backman, Annabelle   
; oauth <
oauth@ietf.org  >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
 
 
 
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..
 
 
 
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci mailto:40auth0@dmarc.ietf.org> > wrote:
 
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
 
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the validation
section. That doesn’t mean this is useless, an AS might elect to use
different 

Re: [OAUTH-WG] Full Third-Party Cookie Blocking

[David Waite]

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 session management mechanism which would work 
for SPA apps under Connect, 
https://bitbucket.org/openid/connect/src/default/distributed-token-validity-api.txt)

In my experience, the vast majority of apps only care about SSO from a user 
experience perspective, and don’t want synchronized session management. Many 
which do want session management are hosted _mostly_ under one origin since the 
organization is trying to hide that they are disparate applications - but many 
have exceptions, such as *.google.com and YouTube.com

-DW


> On Mar 25, 2020, at 7:55 AM, 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 management
> * OIDC JS session notifications
> 
> Will not work anymore. Or don’t work anymore already today - e.g. in Brave.
> 
> This means SPAs would need to be forced to do refresh tokens - and there is 
> no solution right now for session notifications.
> 
> Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the 
> “browser apps without a back-end” scenario and promote the BFF style 
> architecture instead.
> 
> Cheers 
> ———
> Dominick Baier
> ___
> 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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Brian Campbell]

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 'kid' header in a JWT AT and how it
references the verification key in the content at the jwks_uri.





On Wed, Mar 25, 2020 at 11:54 AM George Fletcher  wrote:

> 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
> 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,
> "An authorization server MAY elect to use different keys to sign id_tokens
> and JWT access tokens."? Just a thought anyway.
>
> On Wed, Mar 25, 2020 at 10:11 AM 
>  wrote:
>
>
> 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 listed below, or any other reason they might have) and a
> headsup to RSes so that they don’t make assumptions.
>
>
>
> *From:* Brian Campbell  
> 
> *Sent:* Wednesday, March 25, 2020 8:48 AM
> *To:* Vittorio Bertocci  
> 
> *Cc:* Richard Backman, Annabelle  ; 
> oauth 
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> 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...
>
>
>
> On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
>  wrote:
>
> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>
>
>
>
>
>
> *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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[image: Ping Identity]

Brian Campbell
Distinguished Engineer
bcampb...@pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Blog logo]

Re: [OAUTH-WG] Full Third-Party Cookie Blocking

[Torsten Lodderstedt]

> 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 management
> * OIDC JS session notifications
> 
> Will not work anymore. Or don’t work anymore already today - e.g. in Brave.
> 
> This means SPAs would need to be forced to do refresh tokens - and there is 
> no solution right now for session notifications.
> 
> Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the 
> “browser apps without a back-end” scenario and promote the BFF style 
> architecture instead.

Sound reasonable to me. 

> 
> Cheers 
> ———
> Dominick Baier
> ___
> 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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

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
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,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM  wrote:


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 listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.



*From:* Brian Campbell 
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci 
*Cc:* Richard Backman, Annabelle ; oauth <
oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"



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..



On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*

Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the validation
section. That doesn’t mean this is useless, an AS might elect to use
different keys for its own purposes (eg separation of concerns for
forensics, different strengths, different lifecycles, and so on).






*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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Brian Campbell]

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,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM  wrote:

> 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 listed below, or any other reason they might have) and a
> headsup to RSes so that they don’t make assumptions.
>
>
>
> *From:* Brian Campbell 
> *Sent:* Wednesday, March 25, 2020 8:48 AM
> *To:* Vittorio Bertocci 
> *Cc:* Richard Backman, Annabelle ; oauth <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> 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..
>
>
>
> On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>
>
>
>
>
>
> *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.*
>


-- 
[image: Ping Identity]

Brian Campbell
Distinguished Engineer
bcampb...@pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Blog logo]







*If you’re not a current customer, click here

for
a more relevant offer.*

-- 
_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 

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

[vittorio . bertocci=40auth0 . com]

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 listed below, or any other reason they might have) and a headsup to 
RSes so that they don’t make assumptions.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 8:48 AM
To: Vittorio Bertocci 
Cc: Richard Backman, Annabelle ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

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. 

 

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org> > wrote:

>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with 
>different keys is to publish the keys in two different JWK sets. This only way 
>to do this today is by publishing separate OAuth 2.0 authorization server 
>metadata and OIDC Discovery metadata files, where the JWK set in the former 
>applies to access tokens and the JWK set in the latter applies to ID Tokens.

Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they all 
can be used for signing. What prevents the AS to use one key from that list for 
IDtokens and another for ATs? Separate discovery docs shouldn’t be necessary. 
Sure, there would be no way for the RS to know what key is used for what- but 
similar mechanisms are already in place today for handling signing key 
rotation: e.g. the discovery doc lists the current key and the future key, but 
uses only the current- and the RS has no way of distinguishing between the two. 
The situation here can be analogous, any key in the discovery doc should be 
considered valid by the RS, and in fact there’s no requirement about selecting 
specific keys in the validation section. That doesn’t mean this is useless, an 
AS might elect to use different keys for its own purposes (eg separation of 
concerns for forensics, different strengths, different lifecycles, and so on).

 

 


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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[vittorio . bertocci=40auth0 . com]

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 
increase the likelihood prompt interoperability out of the box, hence it seems 
meaningful to recommend it in an interop profile.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 8:10 AM
To: Vittorio Bertocci 
Cc: Richard Backman, Annabelle ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

 

 

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org> > 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 
>including some Security Considerations text calling out the key distribution 
>challenges when dealing with loosely coupled ASes and RSes).

In the spirit of achieving the simplest, most actionable core interop profile, 
with as little left as exercise to the reader as possible, I would prefer to 
keep symmetric keys out of scope. 

Although you are right that MAC-based implementations have a role to play in 
the OAuth2 ecosystem, key distribution is a problem left to the developer to 
solve; and all the sample JWTs ATs I got from the providers I worked with were 
signed with discoverable keys.

Again, that doesn’t mean that MAC-based implementations shoulnd’t be used: only 
that this profile focuses on a solution that is as close to turnkey as possible 
for developers, and that requests as little delta as possible to providers 
already using JWT for their ATs.

 

I'm not trying to re-litigate the decision or question consensus but I will ask 
that you don't use the justification that "all the sample JWTs ATs I got from 
the providers I worked with were signed with discoverable keys" because I 
explicitly included several example JWT ATs in the samples that I provided that 
were using AEAD symmetric encryption, which is similar to MAC-based but with 
the added benefit of confidentiality of the claims payload. 

 

See also 
https://mailarchive.ietf.org/arch/msg/oauth/DAFccKDPJRhA5Z-vLIrx7u5XU4Q/

 

 


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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Brian Campbell]

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.

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>

-- 
_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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Brian Campbell]

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 including some Security Considerations text calling out the
> key distribution challenges when dealing with loosely coupled ASes and
> RSes).*
>
> In the spirit of achieving the simplest, most actionable core interop
> profile, with as little left as exercise to the reader as possible, I would
> prefer to keep symmetric keys out of scope.
>
> Although you are right that MAC-based implementations have a role to play
> in the OAuth2 ecosystem, key distribution is a problem left to the
> developer to solve; and all* the sample JWTs ATs I got from the providers
> I worked with were signed with discoverable keys.*
>
> Again, that doesn’t mean that MAC-based implementations shoulnd’t be used:
> only that this profile focuses on a solution that is as close to turnkey as
> possible for developers, and that requests as little delta as possible to
> providers already using JWT for their ATs.
>

I'm not trying to re-litigate the decision or question consensus but I will
ask that you don't use the justification that "all the sample JWTs ATs I
got from the providers I worked with were signed with discoverable keys"
because I explicitly included several example JWT ATs in the samples that I
provided that were using AEAD symmetric encryption, which is similar to
MAC-based but with the added benefit of confidentiality of the claims
payload.

See also
https://mailarchive.ietf.org/arch/msg/oauth/DAFccKDPJRhA5Z-vLIrx7u5XU4Q/

-- 
_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] Full Third-Party Cookie Blocking

[Dominick Baier]

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 anymore already today - e.g. in Brave.

This means SPAs would need to be forced to do refresh tokens - and there is
no solution right now for session notifications.

Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the
“browser apps without a back-end” scenario and promote the BFF style
architecture instead.

Cheers
———
Dominick Baier
___
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"

[Vittorio Bertocci]

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 be seen as some weird edge case scenario (though it’d be worth 
>including some Security Considerations text calling out the key distribution 
>challenges when dealing with loosely coupled ASes and RSes).
In the spirit of achieving the simplest, most actionable core interop profile, 
with as little left as exercise to the reader as possible, I would prefer to 
keep symmetric keys out of scope.
Although you are right that MAC-based implementations have a role to play in 
the OAuth2 ecosystem, key distribution is a problem left to the developer to 
solve; and all the sample JWTs ATs I got from the providers I worked with were 
signed with discoverable keys.
Again, that doesn’t mean that MAC-based implementations shoulnd’t be used: only 
that this profile focuses on a solution that is as close to turnkey as possible 
for developers, and that requests as little delta as possible to providers 
already using JWT for their ATs.

>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with 
>different keys is to publish the keys in two different JWK sets. This only way 
>to do this today is by publishing separate OAuth 2.0 authorization server 
>metadata and OIDC Discovery metadata files, where the JWK set in the former 
>applies to access tokens and the JWK set in the latter applies to ID Tokens.
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they all 
can be used for signing. What prevents the AS to use one key from that list for 
IDtokens and another for ATs? Separate discovery docs shouldn’t be necessary. 
Sure, there would be no way for the RS to know what key is used for what- but 
similar mechanisms are already in place today for handling signing key 
rotation: e.g. the discovery doc lists the current key and the future key, but 
uses only the current- and the RS has no way of distinguishing between the two. 
The situation here can be analogous, any key in the discovery doc should be 
considered valid by the RS, and in fact there’s no requirement about selecting 
specific keys in the validation section. That doesn’t mean this is useless, an 
AS might elect to use different keys for its own purposes (eg separation of 
concerns for forensics, different strengths, different lifecycles, and so on).

>2.1 p3: This should be reworded to describe the usage of the 
>“application/at+jwt” media type for the “typ” header parameter. See Section 
>2.3 of RFC 8417 for how this 
>was worded for SETs.
Great catch! I reworded accordingly.
>§2.2: All the JWT claims defined in RFC 7519 are fair game, so there is no 
>need to explicitly call out “iat” and “jti” unless you want to change their 
>OPTIONAL status to something else. I’d be in favor of making them REQUIRED, as 
>they are highly valuable and including them represents a negligible burden on 
>the AS.
You are right that explicitly calling out those claims isn’t necessary given 
their current OPTIONAL status- thought in the spirit of making life easier for 
developers, given their importance I thought it was useful to explicitly 
reference them in the specification.
I’d personally be in favor of making those claims REQUIRED as well- especially 
JTI- I believe that they were marked OPTIONAL as the result of the discussions 
in Stuttgart, but if more people want to chime in favor of promoting them to 
REQUIRED, I’d be happy to change.

>Also, given the confusion around the meaning of “auth_time”, it might be worth 
>calling out that as per definition in 7519, “iat” is the issue time for the 
>access token itself, not for the session or anything else.
This is such a great point. Added language to preempt confusion there.
>§2.2.1: With the addition of the clarifying paragraph in this section, you can 
>do away with the additional descriptions on “auth_time”, “acr”, and “amr”. 
>Just reference OIDC, i.e., drop everything after “as defined in section 2 of 
>[OpenID.Core].”
You are right the individual descriptions aren’t strictly necessary and I did 
consider dropping the list, however I thought that for readability maintaining 
the list would make it easier for the skimmer to unpacks the content. Do you 
see harm in keeping the list, or is it more of a matter of conciseness?
>§2.2.2 p3: Instead of specifically referencing OIDC and Token Introspection, 
>maybe just say implementers SHOULD use claims defined in the JWT Claims 
>Registry when appropriate? We could retain the references as examples, e.g., 
>“such as the claims defined in…”.
Likewise for §2.2.3.1 p2 and SCIM Core.
Similar to the above. Technically you are