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

[Vittorio Bertocci <[e-mail]>]

Thanks Don for your perspective on this!

On Mon, Mar 25, 2019 at 10:13 AM <[e-mail]> wrote:

> Dominick,
>
>
>
> While you assumption of how OIDC and OAuth are used may apply to Federated
> solutions, the North American Energy Standards Board (NAESB) Energy Service
> Provider Interface (ESPI) REQ.21, which defines the data transmission
> standard for Energy utilities (electricity, gas, and water) to use in
> providing consumer’s and Third Party applications information about their
> customer’s energy consumption only allows OAuth 2.0 opaque ATs.
>
> The Green Button Alliance, is reviewing how to update the standard to
> utilize the various IETF standards associated with OIDC this coming year,
> but currently the standard does NOT support a mixture of OIDC and OAuth.  I
> am very happy to see the IETF attempting to standardize the content and
> usage of JWT based OAuth ATs.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone:      [phone]
>
> Email:       [e-mail]
>
>
>
> *From:* Dominick Baier <[e-mail]>
> *Sent:* March 25, 2019 10:39 AM
> *To:* Hans Zandbelt <[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]>; Nov Matake <[e-mail]>;
> [e-mail]
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> 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
>
>