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
