Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Hans Zandbelt <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt <[e-mail]>
> *Cc:* Vittorio Bertocci <Vittorio=[e-mail]>; IETF oauth
> WG <[e-mail]>
> *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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]> 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 <
> [e-mail]>:
>
> 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 ([e-mail]) 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 ([e-mail])
> 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 <[e-mail]>
> 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 ([e-mail]) 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=[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> [e-mail]
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> --
>
> [e-mail]
>
> ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> Vennlig hilsen
>
>
>
> Steinar Noem
>
> Partner Udelt AS
>
> Systemutvikler
>
>
>
> | [e-mail] <steinar@udelt..no> | [e-mail]  | [phone] |
> www.udelt.no |
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> [e-mail]
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> --
>
> [e-mail]
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu