I get that existing practice is likely to be all over the map, but if we’re to
create a JWT access token standard, it’s reasonable to require that the claims
usage comply with the JWT standards.
-- Mike
From: Hans Zandbelt <hans.zandb...@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: George Fletcher <gffletch=40aol....@dmarc.ietf.org>; Vittorio Bertocci
<Vittorio=40auth0....@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
the definition of RFC 7519 is actually "petitio principii" and a lot of
deployments put claims about the Resource Owner in the access token (as a
Resource Server implementer I've suffered a lot from this)
Hans.
On Thu, Apr 4, 2019 at 9:48 PM Mike Jones
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote:
I agree with George that the subject of a token must be the principal of that
token. That what the JWT “sub” claim is for. Indeed, the first sentence of
the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal that is the subject of the
JWT.
If an access token uses “sub”, its usage must comply with the definition from
RFC 7519.
-- Mike
From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt
<hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>>
Cc: Vittorio Bertocci
<Vittorio=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>>; IETF
oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
The more I think about this the more I land in the "No" camp.
The subject of a token should be the principal of that token. It shouldn't
matter whether that is a machine, a user, or a device. Trying to separate out
"humans" as a special class will just make things more complicated. If we need
a claim to identify the subject is a "human" then why not just add that. This
doesn't break anything and makes it easy for people to detect this case in
those use cases where it's required.
Thanks,
George
On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in the
typical use case of onboarding client accounts in the same
directory/OU/namespace as user accounts and we don't need to cater for that.
Hans.
On Wed, Apr 3, 2019 at 10:48 PM George Fletcher
<gffle...@aol.com<mailto:gffle...@aol.com>> wrote:
I agree that this will break a lot of existing flows... especially those using
any form of the client_credentials flow. In that sense I'm not completely on
board yet :)
On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but I do
like the rigidness of it all: it is very explicit, cannot misinterpreted and
thus prevents failure (which is really what Dominick is after); I'm on board
Hans.
On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci
<Vittorio=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand
recommend using sub only for users. Martin would like to have the sub for app
only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it
I'd wait for the people currently at IETF104 to have more time to comment as
well.
Clarification. If the goal is to be able to apply the logic "if there's a sub,
it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub
when that's not the case. Are all OK with it?
Dave, the suggestion of having explicit typing for app only vs user only is
interesting! For the purpose of putting together an interoperable profile, tho,
I would suggest we table it for v1 in the interest of getting to something easy
to adopt (hence with small delta vs existing implementations) faster.
On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem
<stei...@udelt.no<mailto:stei...@udelt.no>> wrote:
Hi Vittorio, we (the national federation-gateway for the health services in
norway - "HelseID") think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.
<mvh>Steinar</mvh>
tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
<dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>>:
From an access token consumer (aka API) developer point of view, I prefer this
logic
"If sub is present - client acts on behalf of a user, if not - not."
Anything more complicated has a potential of going wrong.
On 26. March 2019 at 01:34:53, Nov Matake
(mat...@gmail.com<mailto:mat...@gmail.com>) wrote:
Hi Vittorio,
Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or
incremental integer as sub & client_id will be easily collide.
If you can enforce collision resistant IDs between user & client instances,
it’ll works fine. I feel its overkill though.
Sent from my iPhone
On Mar 26, 2019, at 8:51, Vittorio Bertocci
<vitto...@auth0.com<mailto:vitto...@auth0.com>> wrote:
Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect
core, hence Dominick observation is on point. However in the description I
express something in line with 7519, which was in fact my intent.
The idea was to provide an identifier of the calling subject that is guaranteed
to be present in all cases- this would allow an SDK developer to use the same
code for things like lookups and membership checks regardless of the nature of
the caller (user in a delegated case, app in app-only grants). The information
to discriminate between user and app callers is always available in the token
(say, the caller is a user if sub!=client_id, where client_id is always
guaranteed to be present as well) hence there's no loss in expressive power,
should that difference be relevant for the resource server.
Dominick, Hans- I probably missed the security issue you guys are thinking of
in this case. Of course, if this would introduce a risk I completely agree it
should be changed- I'd just like to understand better the problem. Could you
expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have the
same identifier within an IDP? When using collision resistant IDs, as it is
usually the case, that seems to be a remote possibility- did you stumble in
such scenario in production?
Thanks
V.
On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt
<hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>> wrote:
I believe there are plenty of OAuth 2.0 only use cases out there... but
nevertheless I agree with the potential confusion and thus security problems
arising from that (though one may argue the semantics are the same).
Hans.
On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier
<dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim
type for multiple semantics.
All the “this is OIDC not OAuth” arguments are making things more complicated
than they need to be - in my experience almost no-one (that I know) does OIDC
only - nor OAuth only. They always combine it.
In reality this leads to potential security problems - this spec has the
potential to rectify the situation.
Dominick
On 25. March 2019 at 14:58:56, Hans Zandbelt
(hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>) wrote:
Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth
and an access token is not an id_token.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
"The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a JWT are normally statements
about the subject. The subject value MUST either be scoped to be
locally unique in the context of the issuer or be globally unique.
The processing of this claim is generally application specific"
which kind of spells "client" in case of the client credentials grant but I
also do worry about Resource Servers thinking/acting only in terms of users
Hans.
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier
<dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> wrote:
IMHO the sub claim should always refer to the user - and nothing else.
OIDC says:
"Subject - Identifier for the End-User at the Issuer."
client_id should be used to identify clients.
cheers
Dominick
On 25.. March 2019 at 05:13:03, Nov Matake
(mat...@gmail.com<mailto:mat...@gmail.com>) wrote:
Hi Vittorio,
Thanks for the good starting point of standardizing JWT-ized AT.
One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in this
spec.
It requires those 2 types of identifiers to be unique each other in the IdP
context.
I prefer omitting “sub” claim in 2-legged context, so that no such constraint
needed.
thanks
nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci
<vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:vittorio.bertocci=40auth0....@dmarc.ietf.org>>
wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens.
You can find it in
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
remotely). I look forward for your comments!
Here's just a bit of backstory, in case you are interested in how this doc came
to be. The trajectory it followed is somewhat unusual.
* Despite OAuth2 not requiring any specific format for ATs, through the
years I have come across multiple proprietary solution using JWT for their
access token. The intent and scenarios addressed by those solutions are mostly
the same across vendors, but the syntax and interpretations in the
implementations are different enough to prevent developers from reusing code
and skills when moving from product to product.
* I asked several individuals from key products and services to share with
me concrete examples of their JWT access tokens (THANK YOU Dominick Baier
(IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft),
Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and
differences.
* I put together a presentation summarizing my findings and suggesting a
rough interoperable profile (slides:
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx<https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
) - got early feedback from Filip Skokan on it. Thx Filip!
* The presentation was followed up by 1.5 hours of unconference discussion,
which was incredibly valuable to get tight-loop feedback and incorporate new
ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,
Nat Sakimura, Hannes Tschofenig were all there and contributed generously to
the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get
credited in the draft, my apologies: please send me a note and I'll make things
right at the next update.
* On my flight back I did my best to incorporate all the ideas and feedback
in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and
above all Brian were all super helpful in negotiating the mysterious syntax of
the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest
time to get things right that everyone demonstrated in the process. This is an
amazing community.
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
--
hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Vennlig hilsen
Steinar Noem
Partner Udelt AS
Systemutvikler
| stei...@udelt.no<mailto:stei...@udelt..no> |
h...@udelt.no<mailto:h...@udelt.no> | +47 955 21 620 |
www.udelt.no<http://www.udelt.no/> |
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
--
hans.zandb...@zmartzone.eu<mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
