All,
You can find this meeting minutes at the following link:
https://datatracker.ietf.org/doc/minutes-interim-2020-oauth-04-202004131200/
Thanks to *Jared Jennings *for taking these notes.
Regards,
Rifaat & Hannes
On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary
wrote:
> The Web Authorizati
;oauth@ietf.org"
Subject: RE: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting:
2020-04-13
> the AS could issue the 'sub' value as "urn:anonymous:"
> and create a new value with every token that is issued
But it those cases it would be better to omit “s
> the AS could issue the 'sub' value as "urn:anonymous:"
> and create a new value with every token that is issued
But it those cases it would be better to omit "sub", instead of sending a
per-token value (we have "jti" as a per-token id). That at least avoids other
parties misinterpreting these
Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting:
2020-04-13
Hi Denis,
If the same token is used (within a session) for multiple API calls then all
those API calls can be correlated together even if the token does not have a
'sub' claim because the token itsel
Hi Denis,
If the same token is used (within a session) for multiple API calls then
all those API calls can be correlated together even if the token does
not have a 'sub' claim because the token itself is the correlating
identifier (same is true for the session identifier).
In regards to the
George,
I disagree with you:
The 'sub' claim must be unique (local to the issuer or globally)
with every issued token.
In addition, inter-API correlation prevention does not necessarily
require a unique token for every API call,
since in many cases a session can be opened and one JWT can
On 4/14/20 10:23 AM, Denis wrote:
Unfortunately, this is not possible since RFC 7519 (4.1.2) states:
The subject value MUST either be scoped to be *locally unique
in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents t
Vittorio, one comment in line.
It’s certainly possible to conceive ATs without subs, but I think the
profile would be way less useful for SDK developers.
On the objections:
The sub doesn’t have to be a user, if you look at the earlier
discussions the case in which the token has been issued for
Vittorio, some comments in line:
> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking
about just parsing the sub value if it’s present or not surfacing it
in an object model if it’s not- i think about reliably o
> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking about
just parsing the sub value if it’s present or not surfacing it in an object
model if it’s not- i think about reliably offering the higher level jobs to
be d
An SDK is going to support "sub" wether it is required or optional.
On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci
wrote:
> “Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P
>
> On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci
> wrote:
>
>> It’s certainly possible t
“Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P
On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci wrote:
> It’s certainly possible to conceive ATs without subs, but I think the
> profile would be way less useful for SDK developers.
> On the objections:
> The sub doesn’t
It’s certainly possible to conceive ATs without subs, but I think the
profile would be way less useful for SDK developers.
On the objections:
The sub doesn’t have to be a user, if you look at the earlier discussions
the case in which the token has been issued for an application via client
creds (he
This is a good point, I often use the hotel key analogy as well. The room
door is the RS, the key is the access token, the door does not need to know
who the user is in order to know if it’s okay to unlock given a particular
key.
If sub is required, then this profile is limited in use to cases whe
Why does the "sub" need to be required?
An access token is to prove authorization. The RS may not need "sub" to
constrain fulfilling the client request.
For example, it the access token has the same properties as a movie ticket,
the RS does not need to have any identifier for who purchased the mo
Hello,
More on privacy about "JWT Profile for Access Tokens".
The current document REQUIRES the claim names *sub* and *client_id*.
* sub REQUIRED - as defined in section 4.1.2 of [RFC7519].
* client_id REQUIRED - as defined in section 4.3 of [RFC8693]
*1) **sub REQUIRED*
RFC 7519 states:
I have uploaded the second presentation for today's session, the JWT
Profile for Access Tokens.
https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
Regards,
Rifaat
On Fri, Apr 10, 2020 at 9:35 AM Rifaat Shekh-Yusef
wrote:
> The following is a link to the coming interim me
The following is a link to the coming interim meeting materials:
https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
It has the chairs and Nested JWT slides.
Will upload the JWT Profile for AT slides as soon as I get it.
Regards,
Rifaat
On Tue, Apr 7, 2020 at 1:52 PM IESG
The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 America/Toronto
(16:00 to 17:00 UTC).
Agenda:
1. Nested JWT
https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt
2. JWT Profile for Access Tokens
https://data
19 matches
Mail list logo
