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

[Benjamin Kaduk]

On Tue, Mar 31, 2020 at 09:33:35PM +, Vittorio Bertocci wrote:
> 
> > I’ve already replied to the other thread, but I’ll note that “different 
> > strengths, different lifecycles” don’t matter much if the RS will accept 
> > both types of tokens, signed with either key.
> point taken. I applied the changes discussed on the  other thread.
> 
> >As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
> Promoted to RECOMMENDED

I'd also prefer REQUIRED, and thanks for already moving to RECOMMENDED
(which I was going to suggest as an alternative).

-Ben

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-05.txt

[Vittorio Bertocci]

This version includes a quite large set of changes and additions- thanks 
Annabelle, George, Aaron, Brian, Filip.
Will pick up the conversation on the main remaining item, audience & scopes, in 
the next few hours.

On 3/31/20, 14:35, "OAuth on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens
Author  : Vittorio Bertocci
Filename: draft-ietf-oauth-access-token-jwt-05.txt
Pages   : 18
Date: 2020-03-31

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens
Author  : Vittorio Bertocci
Filename: draft-ietf-oauth-access-token-jwt-05.txt
Pages   : 18
Date: 2020-03-31

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.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! I updated the language accordingly, and added a warning in the 
security section aligned with Annabelle’s concerns.
Updating the draft shortly.

From: Brian Campbell 
Date: Thursday, March 26, 2020 at 09:47
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"

Preventing token substitution/confusion was not at all the aim of my comment. I 
only brought that up in an attempt to bridge what looked like a communication 
gap in Annabelle's and your discussion. Sorry for any confusion that might have 
caused.

That discussion did lead me to think again about the more general issue of 
signalling/figuring out what key from jwks_uri (which has content that isn't 
static and likely changes over time for key rotation) used to sign. Then 
looking again at draft-ietf-oauth-access-token-jwt-04 to realize that it's 
pretty much silent about this bit that I think is an important aspect to 
interop.

The text you suggested definitely works better, yes. Thank you. I could say 
that there'd be value in saying more but, as previously promised, I won't argue 
it further.

On Wed, Mar 25, 2020 at 5:46 PM Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>> wrote:
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 
mailto:bcampb...@pingidentity.com>>
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>>
Cc: George Fletcher mailto:gffle...@aol.com>>, Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>,
 oauth mailto:oauth@ietf.org>>
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 

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

[Vittorio Bertocci]

Alrighty. I added language to explicitly call out 6570 and invalid_token... and 
eliminated step 7 in the validation for other reasons, indirectly obviating for 
the need to clarify the reauthentication signaling mechanism.
Updating the draft shortly.

On 3/25/20, 12:59, "vittorio.berto...@auth0.com"  
wrote:

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

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

[Vittorio Bertocci]

Thank you! I updated the language accordingly, and added a warning in the 
security section aligned with your concerns.
Updating the draft shortly. Will pick up the audience/scope discussion right 
after that


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

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

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 

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

[Vittorio Bertocci]

I addressed all of the below, in line with your suggestion in nearly every case.
I am updating the draft as there are many changes accumulated at this point- 
will pick up the audiences and scope discussion afterwards.



> As evidenced by George’s questions, the individual descriptions are 
> confusing. They aren’t worded as precisely as the paragraph above, and use 
> different terms (e.g., “session”) that aren’t well defined. I’d keep the list 
> but get rid of the extended description, or at the very least pare them down 
> and reword them to match/reference the preceding paragraph.
Alrighty, keeping the list with simplified descriptions seem to satisfy both 
PoVs. Done, I kept only the reference to OIDC.

> My concern is that I don’t want library/framework implementers to come away 
> thinking they only need to support asymmetric signatures. They need to 
> support the full set of JWS signing algorithms (other than “none”).
I see the concern, but I still think that we should be able to recommend one 
method in particular…  the asymmetric method does have concrete advantages in 
term of completeness of guidance, even if that doesn’t mean that the symmetric 
crypto should be ignored. Is there any other language you’d suggest that can 
achieve the goal of expressing that preference while minimizing the risk you 
are concerned about?

> I’ve already replied to the other thread, but I’ll note that “different 
> strengths, different lifecycles” don’t matter much if the RS will accept both 
> types of tokens, signed with either key.
point taken. I applied the changes discussed on the  other thread.

>As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
Promoted to RECOMMENDED

>Specs shouldn’t mandate things that don’t impact functionality or 
>interoperability. If doing Y before X creates a security vulnerability, then 
>by all means the spec should require X be done before Y. By all means, we can 
>advise that implementers consider things like resource consumption in their 
>design, but we should not assume that one fixed approach will work for 
>everyone. [..]
Those are good examples. Also, I validated that the numbers in the idtoken 
validation steps in OIDC are in place only for layout purposes and there’s no 
normative intent behind it. To avoid any confusion, I switched the list from 
numbered to simple bullets.

>I could see people reading step 7 as meaning that the use of “auth_time” 
>inherently implies a fixed session lifetime, which may not be the case. Its 
>value could simply be one signal amongst many that go into an authorization 
>decision, as alluded to in the last paragraph of that section.
I am not convinced a lot of people would go for that interpretation, mostly as 
inferred from how that step is implemented in OIDC based solutions; however I 
don’t feel too strongly about that, I agree that 7 could be derived from the 
closing paragraph, and… by eliminating 7, we sidestep the challenges Aaron 
raised about how exactly would the RS signal to the client that authentication 
needs to reoccur. For all this considered, I am removing that step from the 
validation list.

> A general statement that implementers SHOULD use claims from the registry 
> where applicable would hold up better as future specs define identity-related 
> claims, and I think better captures the intent of the claims registry. I 
> think it’s appropriate to also refer developers to OIDC, Introspection, and 
> SCIM as specs whose claims are likely to be applicable.
Added a reference to the JWT claims registry in 2.2.2. It was harder to do for 
SCIM given that we are explicitly feeding those attributes as JWT claims in 
this very profile.




From: "Richard Backman, Annabelle" 
Date: Wednesday, March 25, 2020 at 17:25
To: Vittorio Bertocci , 'oauth' 
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) 
Profile for OAuth 2.0 Access Tokens"

[richanna]
Comments inline.
[/richanna]

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


From: Vittorio Bertocci 
Date: Wednesday, March 25, 2020 at 2:53 AM
To: "Richard Backman, Annabelle" , 'oauth' 

Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [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.

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 

Re: [OAUTH-WG] RAR - Example JWT for Payment

[Justin Richer]

The “type” is effectively a schema marker for the content of the authorization 
request object, and so it doesn’t need to be the same domain as the API that’s 
being hosted. Think of it this way: the type defines the API, this could be a 
standard body or some other org, and the location defines the specific hosted 
instance. It’s like defining OpenID Connect at the OIDF and hosting it on your 
company’s domain.

 — Justin

> On Mar 30, 2020, at 9:18 AM, Jared Jennings  wrote:
> 
> I have a question about the example and maybe it's more for clarification 
> than anything.
> 
> The example contains type and also location.
> A couple of things
> 1. Would it add clarity if the domain was the same for both? vs. someorg.com 
>  / example.com 
> 2. While only an example, would it bring clerity to past examples if the type 
> was https://schema.example.com/payment_initiation 
>  and the location was 
> https://api.example.com/payments 
> 
> or am I missing something what the values represent?
> 
> Here's the example I am referring to on page 17.
> {
>   "iss": "https://as.example.com ",
>   "sub": "24400320",
>   "aud": "a7AfcPcsl2",
>   "exp": 1311281970,
>   "acr": "psd2_sca",
>   "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
>   "authorization_details": [
>  {
> "type": "https://www.someorg.com/payment_initiation 
> ",
> "actions": [
>"initiate",
>"status",
>"cancel"
> ],
> "locations": [
>"https://example.com/payments "
> ],
> "instructedAmount": {
>"currency": "EUR",
>"amount": "123.50"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
>"iban": "DE02100100109307118603"
> },
> "remittanceInformationUnstructured": "Ref Number Merchant"
>  }
>   ],
>   "debtorAccount": {
>  "iban": "DE40100100103307118608",
>  "user_role": "owner"
>   }
>]
> 
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
> ___
> 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] IETF 107 Virtual OAuth Sessions

[Aaron Parecki]

Sounds good to me!


Aaron Parecki
aaronparecki.com
@aaronpk


On Thu, Mar 26, 2020 at 1:05 PM Hannes Tschofenig
 wrote:
>
> Hi all,
>
>
>
> Rifaat and I had a chat about the virtual interim meetings.
>
> We decided to schedule 6 one-hour-long sessions with 2 topics per session.
>
>
>
> Here is the list of topics we want to discuss:
>
>
>
> 1) OAuth Security Topics + Browser-Based Apps
>
>
>
> 2) JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens + Nested JWT
>
>
>
> 3) PAR + RAR
>
>
>
> 4) OAuth 2.1 + JWT Response for OAuth Token Introspection
>
>
>
> 5) DPoP + OAuth 2.0 Incremental Authorization
>
>
>
> 6) Client Intermediary Metadata + Reciprocal OAuth
>
>
>
> We were thinking about using our Monday, 12:00 EDT, office hour timeslot.
>
> Proposed starting date is April 6th.
>
>
>
> Would this be acceptable?
>
>
>
> Ciao
>
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. 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