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

[Vittorio Bertocci <[e-mail]>]

Hi Dave,
either a type check or a lookup for client_id together with absence of sub
are going to be new logic- the latter seems to be more economical in term
of moving parts, without loss of expressive power.
I am not really committed to one model or the other, I just want to capture
the approach that gets the most consensus. Let's see if more
people/products chime in with perspectives on this

On Tue, Mar 26, 2019 at 9:57 AM Dave Tonge <[e-mail]>
wrote:

> Hi Vittorio
>
> My understanding from Rob and others is that `sub` is already used for
> tokens issued via the client credentials grant (in fact looking at the
> tables from your presentation, most examples used `sub` for both user
> identity and client identity). Given the desire for a spec that doesn't
> break existing implementations, perhaps a new claim indicating the type of
> access token would allow for better interoperability.
>
> Dave
>
> On Tue, 26 Mar 2019 at 17:48, Vittorio Bertocci <Vittorio=
> [e-mail]> wrote:
>
>> thank you Steinar and everyone else for the comments on this!
>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
>> Bertrand recommend using sub only for users. Martin would like to have the
>> sub for app only flows as well. Hans is neutral.
>> 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
>>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: [phone]
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial
> Technology is registered in England & Wales, company registration number
> 06909772 .
> Moneyhub Financial Technology Limited 2018 ©
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>