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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
