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

[Hans Zandbelt <[e-mail]>]

great summary! this will hurt quite a few existing m2m deployments but I do
like the rigidness of it all: it is very explicit, cannot misinterpreted
and thus prevents failure (which is really what Dominick is after); I'm on
board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=
[e-mail]> wrote:

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


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