On 08/05/2019 11:57, Neil Madden 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 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 method, right?
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.
> — Neil
>
>> On 8 May 2019, at 08:51, Vladimir Dzhuvinov <vladi...@connect2id.com> 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 07/05/2019 12:16, Neil Madden 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 :-)
>>>
>>>
>>>> On 7 May 2019, at 09:48, Vittorio Bertocci <vitto...@auth0.com>
>>>> <mailto:vitto...@auth0.com> wrote:
>>>>
>>>> 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 <neil.mad...@forgerock.com
>>>> <mailto:neil.mad...@forgerock.com> <mailto:neil.mad...@forgerock.com>
>>>> <mailto:neil.mad...@forgerock.com>> wrote:
>>>> 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=40auth0....@dmarc.ietf.org
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>> 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 <hans.zandb...@zmartzone.eu
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu>> 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 <michael.jo...@microsoft.com
>>>>> <mailto:michael.jo...@microsoft.com> <mailto:michael.jo...@microsoft.com>
>>>>> <mailto:michael.jo...@microsoft.com>> 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 <hans.zandb...@zmartzone.eu
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu>>
>>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>>> To: Mike Jones <michael.jo...@microsoft.com
>>>>> <mailto:michael.jo...@microsoft.com> <mailto:michael.jo...@microsoft.com>
>>>>> <mailto:michael.jo...@microsoft.com>>
>>>>> Cc: George Fletcher <gffletch=40aol....@dmarc.ietf.org
>>>>> <mailto:gffletch=40aol....@dmarc.ietf.org>
>>>>> <mailto:40aol....@dmarc...ietf.org> <mailto:40aol....@dmarc...ietf.org>>;
>>>>> Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>
>>>>> <mailto:40auth0....@dmarc.ietf.org> <mailto:40auth0....@dmarc.ietf.org>>;
>>>>> IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>
>>>>> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>>
>>>>> 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 <michael.jo...@microsoft.com
>>>>> <mailto:michael.jo...@microsoft.com> <mailto:michael.jo...@microsoft.com>
>>>>> <mailto:michael.jo...@microsoft.com>> 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:
>>>>>
>>>>> 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 <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
>>>>> <mailto:oauth-boun...@ietf.org> <mailto:oauth-boun...@ietf.org>> On
>>>>> Behalf Of George Fletcher
>>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>>> To: Hans Zandbelt <hans.zandb...@zmartzone.eu
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu>>
>>>>> Cc: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>
>>>>> <mailto:40auth0....@dmarc.ietf.org> <mailto:40auth0....@dmarc.ietf.org>>;
>>>>> IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>
>>>>> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>>
>>>>> 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 <gffle...@aol.com
>>>>> <mailto:gffle...@aol.com> <mailto:gffle...@aol.com>
>>>>> <mailto:gffle...@aol.com>> 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=40auth0....@dmarc.ietf.org
>>>>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>
>>>>> <mailto:40auth0....@dmarc.ietf.org> <mailto:40auth0....@dmarc.ietf.org>>
>>>>> wrote:
>>>>>
>>>>> thank you Steinar and everyone else for the comments on this!
>>>>>
>>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
>>>>> Bertrand recommend using sub only for users. Martin would like to have
>>>>> the sub for app only flows as well. Hans is neutral.
>>>>>
>>>>> That does sound like the sub as user has more consensus, tho before
>>>>> changing it I'd wait for the people currently at IETF104 to have more
>>>>> time to comment as well.
>>>>>
>>>>> Clarification. If the goal is to be able to apply the logic "if there's a
>>>>> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
>>>>> of sub when that's not the case. Are all OK with it?
>>>>>
>>>>>
>>>>>
>>>>> Dave, the suggestion of having explicit typing for app only vs user only
>>>>> is interesting! For the purpose of putting together an interoperable
>>>>> profile, tho, I would suggest we table it for v1 in the interest of
>>>>> getting to something easy to adopt (hence with small delta vs existing
>>>>> implementations) faster.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <stei...@udelt.no
>>>>> <mailto:stei...@udelt.no> <mailto:stei...@udelt.no>
>>>>> <mailto:stei...@udelt.no>> wrote:
>>>>>
>>>>> Hi Vittorio, we (the national federation-gateway for the health services
>>>>> in norway - "HelseID") think his is a really valuable initiative!
>>>>>
>>>>> We also agree with Dominick concerning definition of the "sub" claim.
>>>>>
>>>>>
>>>>>
>>>>> <mvh>Steinar</mvh>
>>>>>
>>>>>
>>>>>
>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
>>>>> <dba...@leastprivilege.com <mailto:dba...@leastprivilege.com>
>>>>> <mailto:dba...@leastprivilege.com> <mailto:dba...@leastprivilege.com>>:
>>>>>
>>>>> >From an access token consumer (aka API) developer point of view, I
>>>>> >prefer this logic
>>>>>
>>>>>
>>>>>
>>>>> "If sub is present - client acts on behalf of a user, if not - not."
>>>>>
>>>>>
>>>>>
>>>>> Anything more complicated has a potential of going wrong.
>>>>>
>>>>>
>>>>>
>>>>> On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com
>>>>> <mailto:mat...@gmail.com> <mailto:mat...@gmail.com>
>>>>> <mailto:mat...@gmail.com>) wrote:
>>>>>
>>>>> Hi Vittorio,
>>>>>
>>>>>
>>>>>
>>>>> Yeah, I’m concerning user & client ids collision.
>>>>>
>>>>> I haven’t seen such implementations, but user-select username as sub, or
>>>>> incremental integer as sub & client_id will be easily collide.
>>>>>
>>>>>
>>>>>
>>>>> If you can enforce collision resistant IDs between user & client
>>>>> instances, it’ll works fine. I feel its overkill though.
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <vitto...@auth0.com
>>>>> <mailto:vitto...@auth0.com> <mailto:vitto...@auth0.com>
>>>>> <mailto:vitto...@auth0.com>> wrote:
>>>>>
>>>>> Hey Nov, Dominick, Hans-
>>>>>
>>>>> thanks for the comments. That was an area I was expecting to cause more
>>>>> discussion, and I am glad we are having this opportunity to clarify.
>>>>>
>>>>> The current language in the draft traces the etymology of sub to OpenID
>>>>> Connect core, hence Dominick observation is on point. However in the
>>>>> description I express something in line with 7519, which was in fact my
>>>>> intent.
>>>>>
>>>>>
>>>>>
>>>>> The idea was to provide an identifier of the calling subject that is
>>>>> guaranteed to be present in all cases- this would allow an SDK developer
>>>>> to use the same code for things like lookups and membership checks
>>>>> regardless of the nature of the caller (user in a delegated case, app in
>>>>> app-only grants). The information to discriminate between user and app
>>>>> callers is always available in the token (say, the caller is a user if
>>>>> sub!=client_id, where client_id is always guaranteed to be present as
>>>>> well) hence there's no loss in expressive power, should that difference
>>>>> be relevant for the resource server.
>>>>>
>>>>>
>>>>>
>>>>> Dominick, Hans- I probably missed the security issue you guys are
>>>>> thinking of in this case. Of course, if this would introduce a risk I
>>>>> completely agree it should be changed- I'd just like to understand better
>>>>> the problem. Could you expand it in a scenario/use case to clarify the
>>>>> risk?
>>>>>
>>>>> Nov- playing this back: is the concern that a user and a client might
>>>>> have the same identifier within an IDP? When using collision resistant
>>>>> IDs, as it is usually the case, that seems to be a remote possibility-
>>>>> did you stumble in such scenario in production?
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> V.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandb...@zmartzone.eu
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu>> wrote:
>>>>>
>>>>> I believe there are plenty of OAuth 2.0 only use cases out there... but
>>>>> nevertheless I agree with the potential confusion and thus security
>>>>> problems arising from that (though one may argue the semantics are the
>>>>> same).
>>>>>
>>>>>
>>>>>
>>>>> Hans.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dba...@leastprivilege.com
>>>>> <mailto:dba...@leastprivilege.com> <mailto:dba...@leastprivilege.com>
>>>>> <mailto:dba...@leastprivilege.com>> wrote:
>>>>>
>>>>> Yes I know - and I think in hindsight it was a mistake to use the same
>>>>> claim type for multiple semantics.
>>>>>
>>>>>
>>>>>
>>>>> All the “this is OIDC not OAuth” arguments are making things more
>>>>> complicated than they need to be - in my experience almost no-one (that I
>>>>> know) does OIDC only - nor OAuth only. They always combine it.
>>>>>
>>>>>
>>>>>
>>>>> In reality this leads to potential security problems - this spec has the
>>>>> potential to rectify the situation.
>>>>>
>>>>>
>>>>>
>>>>> Dominick
>>>>>
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandb...@zmartzone.eu
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu>) wrote:
>>>>>
>>>>> Without agreeing or disagreeing: OIDC does not apply here since it is not
>>>>> OAuth and an access token is not an id_token.
>>>>>
>>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2
>>>>> <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>:
>>>>>
>>>>>
>>>>>
>>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>>
>>>>> subject of the JWT. The claims in a JWT are normally statements
>>>>>
>>>>> about the subject. The subject value MUST either be scoped to be
>>>>>
>>>>> locally unique in the context of the issuer or be globally unique.
>>>>>
>>>>> The processing of this claim is generally application specific"
>>>>>
>>>>>
>>>>>
>>>>> which kind of spells "client" in case of the client credentials grant but
>>>>> I also do worry about Resource Servers thinking/acting only in terms of
>>>>> users
>>>>>
>>>>>
>>>>>
>>>>> Hans.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dba...@leastprivilege.com
>>>>> <mailto:dba...@leastprivilege.com> <mailto:dba...@leastprivilege.com>
>>>>> <mailto:dba...@leastprivilege.com>> wrote:
>>>>>
>>>>> IMHO the sub claim should always refer to the user - and nothing else.
>>>>>
>>>>>
>>>>>
>>>>> OIDC says:
>>>>>
>>>>>
>>>>>
>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>
>>>>>
>>>>>
>>>>> client_id should be used to identify clients.
>>>>>
>>>>>
>>>>>
>>>>> cheers
>>>>>
>>>>> Dominick
>>>>>
>>>>>
>>>>>
>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com
>>>>> <mailto:mat...@gmail.com> <mailto:mat...@gmail.com>
>>>>> <mailto:mat...@gmail.com>) wrote:
>>>>>
>>>>> Hi Vittorio,
>>>>>
>>>>>
>>>>>
>>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>>
>>>>>
>>>>>
>>>>> One feedback.
>>>>>
>>>>> The “sub” claim can include 2 types of identifier, end-user and client,
>>>>> in this spec.
>>>>>
>>>>> It requires those 2 types of identifiers to be unique each other in the
>>>>> IdP context.
>>>>>
>>>>>
>>>>>
>>>>> I prefer omitting “sub” claim in 2-legged context, so that no such
>>>>> constraint needed.
>>>>>
>>>>>
>>>>>
>>>>> thanks
>>>>>
>>>>>
>>>>>
>>>>> nov
>>>>>
>>>>>
>>>>>
>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci
>>>>> <vittorio.bertocci=40auth0....@dmarc.ietf.org
>>>>> <mailto:vittorio.bertocci=40auth0....@dmarc.ietf.org>
>>>>> <mailto:vittorio.bertocci=40auth0....@dmarc.ietf.org>
>>>>> <mailto:vittorio.bertocci=40auth0....@dmarc.ietf.org>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>>>>> tokens. You can find it in
>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/
>>>>> <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 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>
>>>>>
>>>>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>>>>
>>>>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip!
>>>>> The presentation was followed up by 1.5 hours of unconference discussion,
>>>>> which was incredibly valuable to get tight-loop feedback and incorporate
>>>>> new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten
>>>>> Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
>>>>> contributed generously to the discussion. Thank you!!!
>>>>> Note: if you were at OSW2019, participated in the discussion and didn't
>>>>> get credited in the draft, my apologies: please send me a note and I'll
>>>>> make things right at the next update.
>>>>> On my flight back I did my best to incorporate all the ideas and feedback
>>>>> in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes
>>>>> and above all Brian were all super helpful in negotiating the mysterious
>>>>> syntax of the RFC format and submission process.
>>>>> I was blown away by the availability, involvement and willingness to
>>>>> invest time to get things right that everyone demonstrated in the
>>>>> process. This is an amazing community.
>>>>>
>>>>> V.
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> | stei...@udelt.no <mailto:stei...@udelt.no> <mailto:stei...@udelt..no>
>>>>> <mailto:stei...@udelt..no> | h...@udelt.no <mailto:h...@udelt.no>
>>>>> <mailto:h...@udelt.no> <mailto:h...@udelt.no> | +47 955 21 620 |
>>>>> www.udelt.no <http://www.udelt.no/> <http://www.udelt.no/>
>>>>> <http://www.udelt.no/> |
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>>
>>>>> --
>>>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
>>>>> <mailto:hans.zandb...@zmartzone.eu> <mailto:hans.zandb...@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
>>>>> <http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
>>>>> <mailto:OAuth@ietf.org>
>>>>> 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>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf <https://www.ietf/>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
--
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
