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

To borrow a term from ML, I think the "aud", "scope", and resource indicator-related text is overfitted to a specific set of deployment scenarios, and a specific way of using scopes and resource indicators. Consider the following: 1. There may be no "scope" parameter The "scope" parameter is OP

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

Thanks Nikos! You are right that the goals of the two specs are different; however the current spec reflects in large part both what was observed in the proprietary JWT ATs in existing systems (hence making interop more likely/meeting a need that seems widespread) and the current practice of abu

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

Thanks George for the super thorough review and feedback! Inline > Section 1. Introduction ��� second line: scenario should be plural --> scenarios ��� second sentence: "are not ran by" --> "are not run by" �� cofidentiality --> confidentiality Fixed. Thanks! >

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

Just a general comment, OIDC has been designed for a specific reason (“identity layer on top of the OAuth 2.0”) whereas JWT access tokens are used for more applications. Since the goal of this specification is to “provide a standardized and interoperable profile as an alternative to the propriet

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

I think one of the problems we have in being super specific about how the JWT access token is constructed is that is means it's not possible for many organizations to follow. How scopes are implemented is very varied across deployments which means that some may conform to the perspective of the

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

You are too fast 😊 I am still replying to your other comments! 😃 Yes, it is possible for resource servers to define sub-resource specific scopes, but it cannot be mandated- and it can be extremely problematic when your AS is multitenant. The resource identifier in those scenarios can be a LONG U

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

Focusing just on this comment... This assumes the system uses a specific implementation of scopes values (e.g. 'read', 'write', 'delete'). It is very possible that in the context of a calendar services and an inbox service... the system defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' i

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

Hi Takahiko, thank you for reviewing and taking the time to write down your feedback! Inline [..] apparently conflicts with RFC 8707. I'm afraid vendors that support > RFC 8707 won't support this draft unless the requirement is loosened, for > example from MUST to SHOULD. I don't think this can

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

Hi Nikos, thanks for taking the time to review and write down your feedback! Inline - In Section 2.2 why nbf claim ( > https://tools..ietf.org/html/rfc7519#section-4.1.5) > is not considered? I > can imagine some interesting applications of this

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

Feedback on the spec... Section 1. Introduction ��� second line: scenario should be plural --> scenarios ��� second sentence: "are not ran by" --> "are not run by" Section 2.2.1 Authentication Information Claims ��� I'm not sure that this definition of `auth_time` allows for th

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

Ad 1) the language is tricky but it does not say forbid the client from sending in two resource values to the authorization endpoint, it says that when access token is issued (i.e. the authorization_code grant at the token endpoint) one of the granted resource values must be part of the request or

Re: [OAUTH-WG] Call for Adoption: DPoP

+1 tir. 17. mar. 2020 kl. 13:21 skrev Rifaat Shekh-Yusef : > All, > > As per the conclusion of the PoP interim meeting, this is a call for > adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the > Application Layer (DPoP)* document: > https://datatracker.ietf.org/doc/draft-fett-