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

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 10:32:31 -0700

Hi all,
thanks for your patience during this month long hiatus, and thanks for the
comments.
Last week at IIW I had the opportunity to discuss this with many of the
people on the list. Here's a summary of where the discussion landaed on the
subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I
didn't check it back when we started the discussion. I do agree with the
people saying that we shouldn't violate existing specifications, hence it
looks like we do need to have sub also in the case in which we have
app-only tokens carrying claims about the app itself. I understand this
will cause some implementation to break, but unfortunately that's intrinsic
in the process of coming up with a common approach and standards compliance
is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality.
One of the main reasons that was brought up for including sub only for user
based ATs was to use it as heuristic for telling those tokens apart from
app-only ones. To that end, *Karl MCGuinness suggested that we include
grant_type as a return claim, which the RS could use to the same effect*. I
find the proposal very clever, and the people at IIW thought so as well.
What you think?
Note, *John Bradley* observed that in some cases this might lead to
ambiguous results if an extension grant is used (say an assertion profile)
but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <[email-masked]>
wrote:

> I also meant to say that (of course) the JWT standard doesn't say that the
> JWT is supposed to be about the client or about the resource owner, hence
> both are valid
>
> Hans.
>
> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked]>
> wrote:
>
>> 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 <[email-masked]>
>> *Sent:* Thursday, April 4, 2019 12:59 PM
>> *To:* Mike Jones <[email-masked]>
>> *Cc:* George Fletcher <gffletch=[email-masked]
>> <40aol.com@dmarc..ietf.org>>; Vittorio Bertocci <Vittorio=
>> [email-masked]>; IETF oauth WG <[email-masked]>
>> *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 <[email-masked]>
>> 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 <[email-masked]> *On Behalf Of *George Fletcher
>> *Sent:* Thursday, April 4, 2019 8:51 AM
>> *To:* Hans Zandbelt <[email-masked]>
>> *Cc:* Vittorio Bertocci <Vittorio=[email-masked]>; IETF
>> oauth WG <[email-masked]>
>> *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 <[email-masked]> 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=
>> [email-masked]> 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 <[email-masked]> 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 <
>> [email-masked]>:
>>
>> 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 ([email-masked]) 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 <[email-masked]> 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 <[email-masked]>
>> 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 <[email-masked]>
>> 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 ([email-masked])
>> 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 <[email-masked]>
>> 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 ([email-masked]) 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=[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> --
>>
>> [email-masked]
>>
>> ZmartZone IAM - www.zmartzone.eu
>>
>>
>>
>>
>> --
>>
>> [email-masked]
>>
>> ZmartZone IAM - www.zmartzone.eu
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> --
>>
>> Vennlig hilsen
>>
>>
>>
>> Steinar Noem
>>
>> Partner Udelt AS
>>
>> Systemutvikler
>>
>>
>>
>> | [email-masked] <steinar@udelt..no> | [email-masked]  | +47 955 21
>> 620 | www.udelt.no |
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> --
>>
>> [email-masked]
>>
>> ZmartZone IAM - www.zmartzone.eu
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> [email-masked]
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>
>> --
>>
>> [email-masked]
>>
>> ZmartZone IAM - www.zmartzone.eu
>>
>>
>>
>>
>>
>>
>> --
>>
>> [email-masked]
>>
>> ZmartZone IAM - www.zmartzone.eu
>>
>
>
> --
> [email-masked]
> ZmartZone IAM - www.zmartzone.eu
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 6 May 2019 22:16:39 +0300

On 06/05/2019 20:32, Vittorio Bertocci wrote:
> To that end, *Karl MCGuinness suggested that we include

The grant type is not something that the RS is really concerned with, or
should be. Introducing this parameter in the access token will create an
additional logical dependency, plus complexity - in the system of
client, AS and RS as a whole, as well as for RS developers. The grant
type, as a concept, is a matter between the client and AS, and IMO
should stay that way.

Clear language in the spec should suffice. For instance: "If the sub
value matches the client_id value, then the subject is the client
application".

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 6 May 2019 22:21:08 +0300

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2

In OpenID Connect the access token is consumed by the UserInfo endpoint.

Were there any suggestions to also spec parameter(s) for the claims
names (with optional locales) for release at the UserInfo endpoint?

Vladimir

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 12:22:23 -0700

It is true that the grant_type is a client side consideration. I did think
about the "client_id==sub" heuristic, but that's not always applicable:
many systems have their own rules for generating sub, and in case they want
to prevent tracking across RSes the sub might be generated ad-hoc for that
particular RS.
Would you prefer to have a dedicated claim that distinguish between user
and app tokens rather than reusing grant_type?

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 12:26:12 -0700

I am not following, Vladimir. What do you mean? Can you make some examples
to clarify?
The userinfo is always colocated with the AS, hence I would expect most
vendors not to use JWT for the ATs issued for userinfo access

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 6 May 2019 22:35:03 +0300

Hi Vittorio,

> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively == sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.

I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively == sub.

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 12:42:18 -0700

Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, e.g.
sub_type = [ resource_owner | client ] ?

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 6 May 2019 22:49:04 +0300

> vendors not to use JWT for the ATs issued for userinfo access

That's what I was curious about, if there are any deployments with the
UserInfo not being co-located.

OpenID Connect also has this exotic use case, called distributed claims:

https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample

If co-location is the common case, then there's really no need to spec a
JWT claim for that.

Vladimir

---

From: Karl McGuinness <[email-masked]>
Date: Mon, 6 May 2019 19:57:36 +0000

Makes sense that we don’t want to further couple AS and RS with grant types.  I’m OK if we want a dedicated claim to establish whether the token is resource owner delegated  vs client acting as itself.

Subject Type is already a concept in RISC.  Just making folks are aware of prior art.

https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1

-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=[email-masked]<mailto:Vittorio=[email-masked]>> wrote:

This message originated outside your organization.
________________________________
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, e.g. sub_type = [ resource_owner | client ] ?

On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Vittorio,

Vladimir

> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>
--
Vladimir Dzhuvinov

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Mon, 6 May 2019 16:48:00 -0400

In OpenID Connect, aggregated and distributed claims are ways for the 
OpenID Provider to reference claims issued by other entities (e.g. 
attribute provider or "Issuer" in the SSI sense). There is no 
requirement from a spec perspective that the /userinfo endpoint be 
co-located with the AS. It seems to me that whether a /userinfo endpoint 
uses opaque or structured tokens is orthogonal to the need for access 
token claim definition.

It may be useful reference the claims specifications in OpenID Connect 
as a reference for user claim values in addition to the claims defined 
in the JWT spec.

Thanks,
George

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 6 May 2019 21:48:36 +0100

I may be missing something but I'd argue that by requiring and comparing
both "sub" and "client_id" we achieve the same semantics without a
new/additional claim (barring name spacing)

Hans.

On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness=
[email-masked]> wrote:

> Makes sense that we don’t want to further couple AS and RS with grant
> types.  I’m OK if we want a dedicated claim to establish whether the token
> is resource owner delegated  vs client acting as itself.
>
> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
> Vittorio=[email-masked]> wrote:
>
> *This message originated outside your organization.*
> ------------------------------
> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
> [email-masked]> wrote:
>
>> Hi Vittorio,
>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 14:49:16 -0700

See below, Hans- the sub doesn’t have to be global, it could be something
generated just for this particular RS. Or the AS might have its own recipe
for generating sub values that different from the recipe used to generate
client_ids. It would be much easier for an AS to emit a claim making this
explicit statement than to change sub and client_id assignment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt <[email-masked]>
wrote:

>> Exploring the approach: would we want a bool claim or an enumeration,
>> e.g. sub_type = [ resource_owner | client ] ?
>>
>>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 6 May 2019 22:53:56 +0100

the scope and way of generating sub/client_id is orthogonal to the
semantics IMHO but if I'm the only one who thinks so, I'll rest my case

Hans.

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 15:06:15 -0700

I am not following. We want this to be adopted, right? :) if we provide
guidance that is sound but hard to implement we are going to fail.
Considerations on whether the guidance requires a big effort to be applied
are very much in scope for me.

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 6 May 2019 23:11:47 +0100

I'm suggesting that whichever "sub" and "client_id" the RS is receiving and
however it was generated, it must mean something to it in alignment with
the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; moreover,
if the "sub" has the same value as "client_id" it must be a client talking
to the RS on behalf of its own and the claims are associated with the
client; if the "sub" has a different value than the "client_id" it must be
a scenario where the client presents a token delegated by a Resource Owner
and the claims are about the Resource Owner. Problem solved?

Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <[email-masked]>
wrote:

>>> See below, Hans- the sub doesn’t have to be global, it could be
>>> something generated just for this particular RS. Or the AS might have its
>>> own recipe for generating sub values that different from the recipe used to
>>> generate client_ids. It would be much easier for an AS to emit a claim
>>> making this explicit statement than to change sub and client_id assignment
>>> logic.
>>>
>>>> I may be missing something but I'd argue that by requiring and
>>>> comparing both "sub" and "client_id" we achieve the same semantics without
>>>> a new/additional claim (barring name spacing)
>>>>
>>>> Hans.
>>>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 6 May 2019 15:22:00 -0700

Let me try a different angle. An AS might generate sub claims and client_id
identifiers using a different format/template. That means that there might
be a client with client_id X that gets assigned a sub value Y, despite the
client being the same, hence the check “sub==client_id” would fail.
The logic producing this might be hard for an AS to change as there has
never been any requirement on client_id or sub formats hence everyone was
free until now to use whatever logic they chose, including name spacing one
but not the other and any other variation, and changes might have ripple
effects downstream on systems that have nothing to do w this spec (eg
sharing of where clients are stored might depend on the internal structure
of the client_id). So in other words, an AS might have to touch pretty
fundamental stuff in its logic and potentially impact scenarios that have
no direct bearing with the JWT AT profile just for making that condition
true. On the other plate of the scale, there’s adding a new claim- which I
can literally already do in various commercial ASes via extensibility
points, without changing their code.

On Mon, May 6, 2019 at 15:11 Hans Zandbelt <[email-masked]>
wrote:

> I'm suggesting that whichever "sub" and "client_id" the RS is receiving
> and however it was generated, it must mean something to it in alignment
> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all;
> moreover, if the "sub" has the same value as "client_id" it must be a
> client talking to the RS on behalf of its own and the claims are associated
> with the client; if the "sub" has a different value than the "client_id" it
> must be a scenario where the client presents a token delegated by a
> Resource Owner and the claims are about the Resource Owner. Problem solved?
>
> Hans.
>

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 7 May 2019 08:07:40 +0100

I understand your legacy-breaking point (and do see a name spacing hurdle)
but:
a. I feel we're now painting ourselves into a corner ("soft doctors make
stinking wounds").
b. putting the client_id into the sub value would be something that any
product should be able to do, just like putting an extra claim in; I don't
think that is fundamental stuff

Hans.

On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci <[email-masked]>
wrote:

> Let me try a different angle. An AS might generate sub claims and
> client_id identifiers using a different format/template. That means that
> there might be a client with client_id X that gets assigned a sub value Y,
> despite the client being the same, hence the check “sub==client_id” would
> fail.
>>>>>>> Makes sense that we don’t want to further couple AS and RS with
>>>>>>> grant types.  I’m OK if we want a dedicated claim to establish whether the
>>>>>>> token is resource owner delegated  vs client acting as itself.
>>>>>>>
>>>>>>> Exploring the approach: would we want a bool claim or an
>>>>>>> enumeration, e.g. sub_type = [ resource_owner | client ] ?
>>>>>>>
>>>>>>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 7 May 2019 00:25:41 -0700

For many of the products I have been and I am working on, sub and client_id
can't be arbitrarily changed - the examples I provided aren't hypothetical:
in my research *all *the providers adding sub in their app only ATs (Azure
AD, Auth0, Ping Identity) had different values in sub and in the claim they
used to indicate the client identifier. For at least Auth0 and AAD you
can't use arbitrary client_ids/formats, you get them assigned by the system.
That's not really legacy, it's current practice - with no counter
indications, really. It's not that we are being soft, handling sub and
client_id differently isn't some kind of bad practice nor has any security
implications. It's an internal implementation detail.

I am not sure I see how having a specialized claim would paint us in a
corner more than imposing the constraint you are suggesting. That seems to
do the exact opposite: it helps ASes to provide the desired functionality
without imposing changes that will ripple across their codebase well beyond
this particular use case.

On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt <[email-masked]>
wrote:

>>>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>>>> >>> grant_type as a return claim, which the RS could use to the
>>>>>>>>> same
>>>>>>>>> >> effect*. I

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 7 May 2019 08:30:07 +0100

using 2 existing + 1 new (=3) claims to say the token is about the client
to me suggests something went sideways in the past and were unable to fix
it in a clean way

Hans.

On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci <[email-masked]> wrote:

> For many of the products I have been and I am working on, sub and
> client_id can't be arbitrarily changed - the examples I provided aren't
> hypothetical: in my research *all *the providers adding sub in their app
> only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and
> in the claim they used to indicate the client identifier. For at least
> Auth0 and AAD you can't use arbitrary client_ids/formats, you get them
> assigned by the system.
>> I understand your legacy-breaking point (and do see a name spacing
>> hurdle) but:
>>>>> I am not following. We want this to be adopted, right? :) if we
>>>>> provide guidance that is sound but hard to implement we are going to fail.

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 7 May 2019 00:50:30 -0700

It looks like we'll have to agree to disagree on this one :) to me we
aren't using 3 claims to say that the token is about the client. Sub and
client_id have their independent reasons to be in the token. Expressing the
fact that a token is about an app should not have the side effect of
forbidding a sub to be RS-specific, for example.

On Tue, May 7, 2019 at 12:30 AM Hans Zandbelt <[email-masked]>
wrote:

>>>>> I'm suggesting that whichever "sub" and "client_id" the RS is
>>>>> receiving and however it was generated, it must mean something to it in
>>>>> alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at
>>>>> all; moreover, if the "sub" has the same value as "client_id" it must be a
>>>>>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt <
>>>>>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci <
>>>>>>> [email-masked]> wrote:
>>>>>>>

---

From: Neil Madden <[email-masked]>
Date: Tue, 7 May 2019 09:37:29 +0100

I wasn’t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the “sub” for an AT obtained via client_credentials. If the client can register itself with a self-chosen client_id then it may deliberately chose a client_id that matches the user name of a privileged user. An RS that just blindly looks at the “sub” claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are probably just looking at the “sub” claim to identify the resource owner, I think the onus is on the AS to ensure that no such ambiguity can arise in the first place by ensuring that the space of “sub” values for client credentials is disjoint with the space for genuine users or by disallowing the client_credentials grant altogether.

This issue already arises in token introspection though, so maybe ought to be mentioned in the OAuth security topics draft rather than specific to the JWT AT draft?

— Neil

> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> Hi all,
> thanks for your patience during this month long hiatus, and thanks for the comments.
> Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended).
> 
> - It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that.
> - That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect. I find the proposal very clever, and the people at IIW thought so as well. What you think?
> Note, John Bradley observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence.
> 
> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <[email-masked] <mailto:[email-masked]>> wrote:
> I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid
> 
> Hans.
> 
> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> 
> Sent: Thursday, April 4, 2019 12:59 PM
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: George Fletcher <gffletch=[email-masked] <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=[email-masked] <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]>>
> 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 <[email-masked] <mailto:[email-masked]>> 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 <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 <[email-masked] <mailto:[email-masked]>> On Behalf Of George Fletcher
> Sent: Thursday, April 4, 2019 8:51 AM
> To: Hans Zandbelt <[email-masked] <mailto:[email-masked]>>
> Cc: Vittorio Bertocci <Vittorio=[email-masked] <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
> 
>  
> 
> 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
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 :)
> 
> 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=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!
> 
> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <[email-masked] <mailto:[email-masked]>>:
> 
> From an access token consumer (aka API) developer point of view, I prefer this logic
> 
>  
> 
> On 26. March 2019 at 01:34:53, Nov Matake ([email-masked] <mailto:[email-masked]>) wrote:
> 
> Hi Vittorio,
> 
>  
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 ([email-masked] <mailto:[email-masked]>) 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 <https://tools.ietf.org/html/rfc7519#section-4.1.2>:
> 
>  
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked] <mailto:[email-masked]>) wrote:
> 
> Hi Vittorio,
> 
>  
> 
> 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=[email-masked] <mailto:vittorio.bertocci=[email-masked]>> 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/ <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.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>  
> 
> --
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
> 
>  
> 
> --
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>  
> 
> --
> 
> Vennlig hilsen
> 
>  
> 
> Steinar Noem
> 
> Partner Udelt AS
> 
> Systemutvikler
> 
>  
> 
> | [email-masked] <mailto:steinar@udelt..no> | [email-masked] <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> | 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>  
> 
> --
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> 
> 
>  
> 
> --
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>  
> 
> 
> 
>  
> 
> --
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 7 May 2019 01:48:31 -0700

Thanks Neil, one more reason to avoid that.
TL;DR,
The context is the discussion we had pre-IIW about whether sub should be
included always or only for tokens issued to ROs. Some exiting
implementations rely on that heuristic.
Turns out that 7519 has language suggesting sub should be there for both
tokens issued for the RO and for apps (via client creds, etc).
We don't want to contradict 7519 but we also want to preserve the ability
for a RS to tell whether an AT was issued via RO auth or app auth, hence
the discussion. Suggestions ranged from adding a grant_type claim (Vlad
made a convincing argument against it), to relying to the client_id==sub
heuristic (which i pushed back on) to the introduction of a new claim (name
TBD given that sub_type is taken already) that can explicitly declare
whether the token has been issued authenticating th RO or via app
credentials.

On Tue, May 7, 2019 at 1:37 AM Neil Madden <[email-masked]>
wrote:

> There is a potential security issue if the client_id is used as the “sub”
> for an AT obtained via client_credentials. If the client can register
> itself with a self-chosen client_id then it may deliberately chose a
> client_id that matches the user name of a privileged user. An RS that just
> blindly looks at the “sub” claim may then erroneously let the client
> perform privileged actions.
>
> Given that there are a lot of RSes in existence, many of which are
> probably just looking at the “sub” claim to identify the resource owner, I
> think the onus is on the AS to ensure that no such ambiguity can arise in
> the first place by ensuring that the space of “sub” values for client
> credentials is disjoint with the space for genuine users or by disallowing
> the client_credentials grant altogether.
>
> This issue already arises in token introspection though, so maybe ought to
> be mentioned in the OAuth security topics draft rather than specific to the
> JWT AT draft?
>
> — Neil
>
> On 6 May 2019, at 18:32, Vittorio Bertocci <
> grant_type as a return claim, which the RS could use to the same effect*.
> I find the proposal very clever, and the people at IIW thought so as well.
> What you think?
>> I also meant to say that (of course) the JWT standard doesn't say that
>> the JWT is supposed to be about the client or about the resource owner,
>> hence both are valid
>>
>> Hans.
>>
>>> <40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=
>>> 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
>>> Hi Vittorio, we  (the national federation-gateway for the health
>>> services in norway - "HelseID")  think his is a really valuable initiative!
>>>
>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <
>>> [email-masked]> wrote:
>>>
>>> Without agreeing or disagreeing: OIDC does not apply here since it is
>>> not OAuth and an access token is not an id_token.
>>>
>>> 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 <
>>> [email-masked]> wrote:
>>>
>>>    - 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!).

---

From: Neil Madden <[email-masked]>
Date: Tue, 7 May 2019 10:16:43 +0100

Ah, that makes sense. Well, we already add a grant_type claim to our JWT-based access tokens, so I’m in favour of that solution :-)

> On 7 May 2019, at 09:48, Vittorio Bertocci <[email-masked]> wrote:
> 
> The context is the discussion we had pre-IIW about whether sub should be included always or only for tokens issued to ROs. Some exiting implementations rely on that heuristic.
> Turns out that 7519 has language suggesting sub should be there for both tokens issued for the RO and for apps (via client creds, etc).
> We don't want to contradict 7519 but we also want to preserve the ability for a RS to tell whether an AT was issued via RO auth or app auth, hence the discussion. Suggestions ranged from adding a grant_type claim (Vlad made a convincing argument against it), to relying to the client_id==sub heuristic (which i pushed back on) to the introduction of a new claim (name TBD given that sub_type is taken already) that can explicitly declare whether the token has been issued authenticating th RO or via app credentials.
> 
> On Tue, May 7, 2019 at 1:37 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]>> wrote:
>> 
>> Hi all,
>> 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!

---

From: Neil Madden <[email-masked]>
Date: Tue, 7 May 2019 10:18:14 +0100

Is it too late to add the observation below to the OAuth security topics BCP draft?

> Begin forwarded message:
> 
> From: Neil Madden <[email-masked]>
> Date: 7 May 2019 at 09:37:29 BST
> To: Vittorio Bertocci <Vittorio=[email-masked]>
> Cc: Hans Zandbelt <[email-masked]>, Karl McGuinness <[email-masked]>, John Bradley <[email-masked]>, IETF oauth WG <[email-masked]>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 May 2019 09:25:27 +0000

No, it is definitely not too late for your comment

From: OAuth <[email-masked]> On Behalf Of Neil Madden
Sent: Dienstag, 7. Mai 2019 11:18
To: IETF oauth WG <[email-masked]>
Subject: [OAUTH-WG] OAuth security topics

Begin forwarded message:

From: Neil Madden <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Date: 7 May 2019 at 09:37:29 BST
To: Vittorio Bertocci <Vittorio=[email-masked]<mailto:Vittorio=[email-masked]>>
Cc: Hans Zandbelt <[email-masked]<mailto:[email-masked]>>, Karl McGuinness <[email-masked]<mailto:[email-masked]>>, John Bradley <[email-masked]<mailto:[email-masked]>>, IETF oauth WG <[email-masked]<mailto:[email-masked]>>

— Neil

On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=[email-masked]<mailto:Vittorio=[email-masked]>> wrote:

Hi all,

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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 <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <[email-masked]<mailto:[email-masked]>> 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.

                                                                -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks,
George

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>:
From an access token consumer (aka API) developer point of view, I prefer this logic

On 26. March 2019 at 01:34:53, Nov Matake ([email-masked]<mailto:[email-masked]>) wrote:
Hi Vittorio,

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> 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.

Thanks
V.

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked]<mailto:[email-masked]>) 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:

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked]<mailto:[email-masked]>> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked]<mailto:[email-masked]>) wrote:
Hi Vittorio,

One feedback.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=[email-masked]<mailto:vittorio.bertocci=[email-masked]>> 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!

  *   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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked]<mailto:steinar@udelt..no> | [email-masked]<mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no<http://www.udelt.no/> |
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>

OAuth mailing list

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Neil Madden <[email-masked]>
Date: Tue, 7 May 2019 10:46:43 +0100

I notice that a few of my emails to the OAuth WG list have come through with the From field from “oauth-bounces”:

Is this normal? I checked my subscription status on mailman and I’m posting from the same email address that I subscribed from.

Cheers,

Neil

> On 7 May 2019, at 10:25, Hannes Tschofenig <[email-masked]> wrote:
> 
> From: Neil Madden <[email-masked] <mailto:[email-masked]>>
> To: Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]>>
> Cc: Hans Zandbelt <[email-masked] <mailto:[email-masked]>>, Karl McGuinness <[email-masked] <mailto:[email-masked]>>, John Bradley <[email-masked] <mailto:[email-masked]>>, IETF oauth WG <[email-masked] <mailto:[email-masked]>>
>  
> The JWT spec says inhttps://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2>:
>  
> 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!
> ZmartZone IAM -www.zmartzone.eu <http://www.zmartzone.eu/>
> 
>  
> --

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 7 May 2019 13:21:10 +0200

Hi Neil,

you raised a very important issue but the Security BCP does not talk about JWT content like the Access Token JWT BCP.

I therefore think the security advise should go into the security considerations section of the Access Token JWT BCP.

best regards,
Torsten.

> Am 07.05.2019 um 11:18 schrieb Neil Madden <[email-masked]>:
> 
>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <[email-masked]> wrote:
>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked]> wrote:
>>>>> From: Hans Zandbelt <[email-masked]> 
>>>>> To: Mike Jones <[email-masked]>
>>>>> Cc: George Fletcher <gffletch=[email-masked]>; Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth WG <[email-masked]>
>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <[email-masked]> wrote:
>>>>> 
>>>>> From: OAuth <[email-masked]> On Behalf Of George Fletcher
>>>>> To: Hans Zandbelt <[email-masked]>
>>>>> Cc: Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth WG <[email-masked]>
>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=[email-masked]> wrote:
>>>>> 
>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <[email-masked]>:
>>>>> 
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked]> wrote:
>>>>> 
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <[email-masked]> wrote:
>>>>> 
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked]) wrote:
>>>>> 
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked]> wrote:
>>>>> 
>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=[email-masked]> wrote:
>>>>> 
>>>>>  
>>>>> 
>>>>> Dear all,
>>>>> 
>>>>> 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!
>>>>> | [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no | 
>>>>>

---

From: Neil Madden <[email-masked]>
Date: Tue, 7 May 2019 12:23:11 +0100

The same issue applies to token introspection responses though.

> On 7 May 2019, at 12:21, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Neil,
> 
> Am 07.05.2019 um 11:18 schrieb Neil Madden <[email-masked] <mailto:[email-masked]>>:
>

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 7 May 2019 13:57:35 +0100

I agree with Vladimir: we don't want the RS to know about grant types since
these are extensible and there may be more than one grant type that has
client credentials like semantics [1]

Hans.

[1] I can think of a new "referred_client_credentials" grant type that
doesn't return its tokens directly from the token endpoint but refers to a
remote endpoint and hands out creds for the call to that endpoint

On Tue, May 7, 2019 at 10:16 AM Neil Madden <[email-masked]>
wrote:

> Ah, that makes sense. Well, we already add a grant_type claim to our
> JWT-based access tokens, so I’m in favour of that solution :-)
>
>
>> This issue already arises in token introspection though, so maybe ought
>> to be mentioned in the OAuth security topics draft rather than specific to
>> the JWT AT draft?
>>
>> — Neil
>>
>>>> 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
>>>> 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
>>>> 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.
>>>>
>>>>
>>>>
>>>> Dave, the suggestion of having explicit typing for app only vs user
>>>> only is interesting! For the purpose of putting together an interoperable
>>>> I haven’t seen such implementations, but user-select username as sub,
>>>> or incremental integer as sub & client_id will be easily collide.
>>>>
>>>>
>>>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 May 2019 08:22:03 -0500

> Is this normal? I checked my subscription status on mailman and I’m posting from the same email address that I subscribed from.

It's the latest iteration of trying to maintain DMARC compliance when
mailing list software redistributes your message.
The IETF (well, AMS, LLC) mail servers are presumably not listed as
authorized senders for your actual domain, so they rewrite to a From:
address they are authorized to send from.

-Ben

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 8 May 2019 10:51:15 +0300

grant_type would be horrible for RS developers to deal with, just to
find out whether "sub" effectively == "client_id".

Why?

  * RS developers will need to learn more OAuth stuff - there are better
    ways to motivate people than that :)
  * The OAuth grant types are unbounded. If at some point a new grant
    gets devised / implemented, RS developers will need to update the
    code that maps grant_types to ("sub" effectively == "client_id")
  * We have at least one grant - JWT assertion - where checking the
    grant type is not sufficient to determine if "sub" effectively ==
    "client_id"

I believe we should aim for a spec where RS developers shouldn't be
required to know more than how to process JWTs.

The AS has all the necessary information to indicate whether "sub"
effectively == "client_id". We don't need to push that logic to the RS.

Vladimir

On 07/05/2019 12:16, Neil Madden wrote:
> https://www.ietf

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 8 May 2019 10:55:57 +0300

On 07/05/2019 11:48, Vittorio Bertocci wrote:
> name
> TBD given that sub_type is taken already

Meaning that it cannot be used in a AT as JWT?

What spec is that?

Thanks,

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 8 May 2019 11:22:18 +0300

This is an excellent security point.

I also imagine that in "federated" cases an RS could have its own
subject scheme / namespace, distinct from the one at the AS, including
for clients acting on their own behalf.

Vladimir

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 May 2019 09:57:18 +0100

Why does the RS need to know if the subject is a client vs a user? I suspect the answers to that question are about as problematic as the RS needing to know about the grant type.

I’m not a fan of the client_credentials grant, better off using a real service account in most cases. Hopefully no new grants will be added that repeat that mistake.

Not sure I understand the point about JWT assertion grant type. If you use a JWT assertion for client authentication then that’s just the client_credentials grant again with a different token auth method, right?

— Neil

> On 8 May 2019, at 08:51, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> grant_type would be horrible for RS developers to deal with, just to find out whether "sub" effectively == "client_id".
> 
> Why?
> RS developers will need to learn more OAuth stuff - there are better ways to motivate people than that :)
> The OAuth grant types are unbounded. If at some point a new grant gets devised / implemented, RS developers will need to update the code that maps grant_types to ("sub" effectively == "client_id")
> We have at least one grant - JWT assertion - where checking the grant type is not sufficient to determine if "sub" effectively == "client_id"
> I believe we should aim for a spec where RS developers shouldn't be required to know more than how to process JWTs.
> 
> The AS has all the necessary information to indicate whether "sub" effectively == "client_id". We don't need to push that logic to the RS.
> Vladimir
> 
>>> On 7 May 2019, at 09:48, Vittorio Bertocci <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]> <mailto:Vittorio=[email-masked]> <mailto:Vittorio=[email-masked]>> wrote:
>>>> 
>>>> Hi all,
>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> From: Hans Zandbelt <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>> To: Mike Jones <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> Cc: George Fletcher <gffletch=[email-masked] <mailto:gffletch=[email-masked]> <mailto:40aol.com@dmarc...ietf.org> <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 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 <https://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2> is:
>>>> 
>>>> From: OAuth <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> On Behalf Of George Fletcher
>>>> To: Hans Zandbelt <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> Cc: Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>:
>>>> 
>>>> On 26. March 2019 at 01:34:53, Nov Matake ([email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>) wrote:
>>>> 
>>>> Hi Vittorio,
>>>> 
>>>>  
>>>> 
>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hey Nov, Dominick, Hans-
>>>> 
>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>) wrote:
>>>> 
>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2>:
>>>> 
>>>>  
>>>> 
>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> 
>>>> On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>) wrote:
>>>> 
>>>> Hi Vittorio,
>>>> 
>>>>  
>>>> 
>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=[email-masked] <mailto:vittorio.bertocci=[email-masked]> <mailto:vittorio.bertocci=[email-masked]> <mailto:vittorio.bertocci=[email-masked]>> 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/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
>>>> 
>>>> 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> <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!
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>>  
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> Vennlig hilsen
>>>> 
>>>>  
>>>> 
>>>> Steinar Noem
>>>> 
>>>> Partner Udelt AS
>>>> 
>>>> Systemutvikler
>>>> 
>>>>  
>>>> 
>>>> | [email-masked] <mailto:[email-masked]> <mailto:steinar@udelt..no> <mailto:steinar@udelt..no> | [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> <http://www.udelt.no/> <http://www.udelt.no/> | 
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>  
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>>>>  
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>  
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>> 
>>>> -- 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> https://www.ietf <https://www.ietf/>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 May 2019 14:14:08 +0200

An AS (and also an OP) MUST ensure uniqueness of any id that may end up in a “sub". OpenID Connect even states that explicitly. That way the recipient of the data (token, assertion, introspection response, …) does not need to know anything about account types. 

Having the same sub value for a user and a client (service account) violates that requirement.

> On 8. May 2019, at 10:57, Neil Madden <[email-masked]> wrote:
> 
>> 	• RS developers will need to learn more OAuth stuff - there are better ways to motivate people than that :)
>> 	• The OAuth grant types are unbounded. If at some point a new grant gets devised / implemented, RS developers will need to update the code that maps grant_types to ("sub" effectively == "client_id")
>> 	• We have at least one grant - JWT assertion - where checking the grant type is not sufficient to determine if "sub" effectively == "client_id"
>>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <
>>>> [email-masked] <mailto:neil.madden@forgerock..com>
>>>> > wrote:
>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=[email-masked] <mailto:Vittorio=[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>> Hi all,
>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <
>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > wrote:
>>>>> From: Hans Zandbelt <
>>>>> To: Mike Jones <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> >
>>>>> Cc: George Fletcher <
>>>>> gffletch=[email-masked] <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=[email-masked] <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]>
>>>>> >
>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > 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 <https://tools.ietf.org/html/rfc7519#section-4.1.2>
>>>>>  is:
>>>>> 
>>>>> From: OAuth <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > On Behalf Of George Fletcher
>>>>> To: Hans Zandbelt <
>>>>> Cc: Vittorio Bertocci <
>>>>> Vittorio=[email-masked] <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]>
>>>>> >
>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <
>>>>> Vittorio=[email-masked] <mailto:[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>> [email-masked] <mailto:dbaier@leastprivilege..com>
>>>>> >:
>>>>> 
>>>>> On 26. March 2019 at 01:34:53, Nov Matake (
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> ) wrote:
>>>>> 
>>>>> Hi Vittorio,
>>>>> 
>>>>>  
>>>>> 
>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>> Hey Nov, Dominick, Hans-
>>>>> 
>>>>> [email-masked] <mailto:dbaier@leastprivilege..com>
>>>>> > wrote:
>>>>> 
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (
>>>>> ) wrote:
>>>>> The JWT spec says in 
>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2>
>>>>> :
>>>>> 
>>>>>  
>>>>> 
>>>>> [email-masked] <mailto:dbaier@leastprivilege..com>
>>>>> > wrote:
>>>>> 
>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> ) wrote:
>>>>> 
>>>>> Hi Vittorio,
>>>>> 
>>>>>  
>>>>> 
>>>>> vittorio.bertocci=[email-masked] <mailto:vittorio.bertocci=[email-masked]>
>>>>> > 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/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>
>>>>> .
>>>>> 
>>>>> 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>
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> --
>>>>> 
>>>>> 
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> 
>>>>> | 
>>>>> [email-masked] <mailto:steinar@udelt..no> | [email-masked] <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/>
>>>>>  | 
>>>>> 
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> 
>>>>>  
>>>>> 
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> --
>>>>> 
>>>>> 
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 
>>>>> ZmartZone IAM - 
>>>>> www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 May 2019 14:15:20 +0200

You are right. May I ask you to propose text (threat description, advice, ...) to be included in the BCP? 

> On 7. May 2019, at 13:23, Neil Madden <[email-masked]> wrote:
> 
>>>>> 	• 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 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!!!
>>>>> 	• 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.

---

From: George Fletcher <[email-masked]>
Date: Wed, 8 May 2019 10:53:31 -0400

Maybe this is a dumb question, but why would an AS allow a client to 
register it's own client_id rather than issuing the client a client_id 
within the namespace of the AS?

Also, a client_id or sub should NEVER be treated as unique without the 
context of the issuer. In that regard, the AS (as Torsten pointed out) 
MUST ensure uniqueness within it's "issuer" context.

On 5/8/19 4:22 AM, Vladimir Dzhuvinov wrote:
>>> On 6 May 2019, at 18:32, Vittorio Bertocci<Vittorio=[email-masked]>  wrote:
>>>
>>> Hi all,
>>> 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 athttps://tools.ietf.org/html/rfc7519#section-4.1.2  <https://tools.ietf.org/html/rfc7519#section-4.1.2>  is:
>>>
>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it inhttps://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/  <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
>>>
>>> [email-masked]  <mailto:steinar@udelt..no>  [email-masked]  <mailto:[email-masked]>   | +47 955 21 620 |www.udelt.no  <http://www.udelt.no/>  |
>>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 8 May 2019 18:05:35 +0300

> Why does the RS need to know if the subject is a client vs a user? I suspect the answers to that question are about as problematic as the RS needing to know about the grant type.

I have the exact same question.

Could someone comment on that?

I cannot think of a good reason, unless perhaps for logging / audit.

> I’m not a fan of the client_credentials grant, better off using a real service account in most cases. Hopefully no new grants will be added that repeat that mistake.

What do you mean by service account in this context?

> Not sure I understand the point about JWT assertion grant type. If you use a JWT assertion for client authentication then that’s just the client_credentials grant again with a different token auth…

That was my point, that the JWT assertion grant as the client
credentials grant can be used by a client acting on its own behalf.

-- 
Vladimir Dzhuvinov

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 8 May 2019 13:56:56 -0700

One case I have seen back in the AAD days was when a RS wants to authorize
calls from specific clients. In there a client can act both as confidential
and as public client, and in the case of public client the client_id can be
reused by any app really - hence just looking at the client_id in the
incoming token doesn’t prove anything (even assuming that the RS knows
about the specific client_id, which might not always be the case). AAD had
a special claim saying whether the token was obtained from an authenticated
client, which would solve this particular scenario, but when I suggested
introducing such a claim in the initial proposal discussion that was
strongly discouraged hence I dropped it (tho I think I did add some
comments in the draft).
Having a sub_type (or whatever we’ll name it) would solve this for the most
obvious cases (client_crednetials, assertions representing clients).

Dominick mentioned that he uses the absence of sub in app token scenarios
to recognize the incoming tokens as such, hence he might have more
scenarios where the RS needs to be able to tell the difference.

On Wed, May 8, 2019 at 08:06 Vladimir Dzhuvinov <[email-masked]>
wrote:

> > Why does the RS need to know if the subject is a client vs a user? I
> suspect the answers to that question are about as problematic as the RS
> needing to know about the grant type.
>
> > I’m not a fan of the client_credentials grant, better off using a real
> service account in most cases. Hopefully no new grants will be added that
> repeat that mistake.
>
> > Not sure I understand the point about JWT assertion grant type. If you
> use a JWT assertion for client authentication then that’s just the
> client_credentials grant again with a different token auth method, right?
>
> >> The OAuth grant types are unbounded. If at some point a new grant gets
> devised / implemented, RS developers will need to update the code that maps
> grant_types to ("sub" effectively == "client_id")
> >> We have at least one grant - JWT assertion - where checking the grant
> type is not sufficient to determine if "sub" effectively == "client_id"
> >>>> The context is the discussion we had pre-IIW about whether sub should
> be included always or only for tokens issued to ROs. Some exiting
> >>>> Turns out that 7519 has language suggesting sub should be there for
> both tokens issued for the RO and for apps (via client creds, etc).
> >>>> We don't want to contradict 7519 but we also want to preserve the
> ability for a RS to tell whether an AT was issued via RO auth or app auth,
> hence the discussion. Suggestions ranged from adding a grant_type claim
> (Vlad made a convincing argument against it), to relying to the
> client_id==sub heuristic (which i pushed back on) to the introduction of a
> new claim (name TBD given that sub_type is taken already) that can
> explicitly declare whether the token has been issued authenticating th RO
> or via app credentials.
> >>>>
> >>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]>> wrote:
> >>>> There is a potential security issue if the client_id is used as the
> “sub” for an AT obtained via client_credentials. If the client can register
> >>>> This issue already arises in token introspection though, so maybe
> ought to be mentioned in the OAuth security topics draft rather than
> specific to the JWT AT draft?
> >>>>
> >>>> — Neil
> >>>>
> >>>>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=
> [email-masked] <mailto:Vittorio=[email-masked]>
> <mailto:Vittorio=[email-masked]> <mailto:Vittorio=
> [email-masked]>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> Last week at IIW I had the opportunity to discuss this with many of
> the people on the list. Here's a summary of where the discussion landaed on
> the subject of the sub (pun intended).
> >>>>>
> >>>>> - It seems that RFC 7519 has pretty clear language on the use of
> sub- I didn't check it back when we started the discussion. I do agree with
> the people saying that we shouldn't violate existing specifications, hence
> it looks like we do need to have sub also in the case in which we have
> >>>>> - That said, I am strongly committed to preserve existing
> functionality. One of the main reasons that was brought up for including
> sub only for user based ATs was to use it as heuristic for telling those
> tokens apart from app-only ones. To that end, Karl MCGuinness suggested
> that we include grant_type as a return claim, which the RS could use to the
> same effect. I find the proposal very clever, and the people at IIW thought
> so as well. What you think?
> >>>>> Note, John Bradley observed that in some cases this might lead to
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> wrote:
> >>>>> I also meant to say that (of course) the JWT standard doesn't say
> that the JWT is supposed to be about the client or about the resource
> owner, hence both are valid
> >>>>>
> >>>>> Hans.
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> wrote:
> >>>>> 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
> Mike
> >>>>> From: Hans Zandbelt <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>>
> >>>>> To: Mike Jones <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>>
> >>>>> Cc: George Fletcher <gffletch=[email-masked] <mailto:
> gffletch=[email-masked]> <mailto:40aol.com@dmarc...ietf.org>
> <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=
> [email-masked] <mailto:Vittorio=[email-masked]>
> <mailto:[email-masked]> <mailto:[email-masked]>>;
> IETF oauth WG <[email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>>
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> 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 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> is:
> >>>>>
> Mike
> >>>>> From: OAuth <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]> <mailto:[email-masked]>> On
> Behalf Of George Fletcher
> >>>>> To: Hans Zandbelt <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>>
> >>>>> Cc: Vittorio Bertocci <Vittorio=[email-masked] <mailto:
> Vittorio=[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]>>; IETF oauth WG <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
> >>>>> 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 <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>> 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
> [email-masked] <mailto:Vittorio=[email-masked]>
> <mailto:[email-masked]> <mailto:[email-masked]>>
> wrote:
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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?
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>> wrote:
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>>:
> >>>>>
> >>>>> On 26. March 2019 at 01:34:53, Nov Matake ([email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>)
> wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I haven’t seen such implementations, but user-select username as
> sub, or incremental integer as sub & client_id will be easily collide.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>> 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
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> 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
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> wrote:
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>) 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 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2>:
> >>>>>
> >>>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>> wrote:
> >>>>>
> >>>>> On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:
> [email-masked]>) wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=
> [email-masked] <mailto:vittorio.bertocci=
> [email-masked]> <mailto:vittorio.bertocci=
> [email-masked]> <mailto:vittorio.bertocci=
> [email-masked]>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dear all,
> >>>>>
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <
> 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
> >>>>> I asked several individuals from key products and services to share
> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
> (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
> <
> 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>
> <https://sec..
> uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
> >>>>> The presentation was followed up by 1.5 hours of unconference
> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
> contributed generously to the discussion. Thank you!!!
> >>>>> On my flight back I did my best to incorporate all the ideas and
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Vennlig hilsen
> >>>>>
> >>>>>
> >>>>>
> >>>>> Steinar Noem
> >>>>>
> >>>>> Partner Udelt AS
> >>>>>
> >>>>> Systemutvikler
> >>>>>
> >>>>>
> >>>>>
> >>>>> | [email-masked] <mailto:[email-masked]> <mailto:steinar@udelt..no>
> <mailto:steinar@udelt..no> | [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked]> <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no <
> http://www.udelt.no/> <http://www.udelt.no/> <http://www.udelt.no/> |
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>> --
> <mailto:[email-masked]> <mailto:[email-masked]>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>
> >>>

---

From: Neil Madden <[email-masked]>
Date: Tue, 28 May 2019 15:33:29 +0100

Hi Torsten,

Apologies for the late reply. Suggested text:

----
4.x Client Impersonation of Resource Owner

Resource servers may make access control decisions based on the identity of the resource owner as communicated in the "sub" claim returned by the authorization server in a token introspection response [RFC 7662] or other mechanism. If a client is able to choose its own client_id during registration with the authorization server, then there is a risk that it can register with the same "sub" value as a privileged user. A subsequent access token obtained under the client_credentials grant may be mistaken as an access token authorized by the privileged user if the resource server does not perform additional checks.

4.1.x Proposed Countermeasures

Authorization servers SHOULD NOT allow clients to influence their client_id or "sub" value or any other claim that might cause confusion with a genuine resource owner. Where this cannot be avoided, authorization servers MUST provide another means for the resource server to distinguish between access tokens authorized by a resource owner from access tokens authorized by the client itself.
----

Open to revisions/suggestions.

-- Neil

> On 8 May 2019, at 13:15, Torsten Lodderstedt <[email-masked]> wrote:
>