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

[<[e-mail]>]

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

 

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

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




 

--

[e-mail] <mailto:[e-mail]> 

ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>