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

[Vittorio Bertocci <[e-mail]>]

Thank you, Martin! RFC7523 was the reason for which i had the sub in the
first JWT AT profile draft the way I did. The proposal of requiring it only
for user flows and disallowing it otherwise is not in alignment with
RFC7523, which does not sound like a good thing, but ultimately the
function of JWT as assertion isn't the same as the function of an AT, and
might even prevent an AT to be used for that purpose (tho I know that's
what some ASes do today.
Ultimately I'd like this profile to reflect the desires of as many ASes as
possible, and if in-market usage differs, as long as there's no direct
violation of existing specs (doesn't seem to be the case here given tha
assertion!=AT) and there are no security/privacy issues coming with that, I
won't push back

On Tue, Mar 26, 2019 at 10:00 AM Schanzenbach, Martin <
[e-mail]> wrote:

>
>
> > On 26. Mar 2019, at 17:48, 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.
>
> I am also neutral to this change in general. I was just noting that in
> RFC7523 in combination with client credentials + JWT bearer token grant,
> the JWT MUST contain a "sub" claim with the client_id.
>
> So, imo it is a little inconsistent if the JWT access token does not
> contain a "sub" claim with client ID when it contains claims for the client
> (as there is no user context).
> Hans also pointed out the JWT spec which supports this logic.
>
> In other words, if you think that the use of "sub" is consistent across
> RFC7523 and your draft, it is fine with me and we will adopt our use
> accordingly eventually.
>
> > 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
> ) - 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] | [e-mail]  | [phone] | www.udelt.no |
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> Martin Schanzenbach
> Fraunhofer AISEC
> Department Service & Application Security
> Parkring 4, 85748 Garching near Munich (Germany)
> Tel: [phone]
> [e-mail]
> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
>
>