[OAUTH-WG] OAuth 2.1 Sections 4.1.2.1. Error Response (Authorization Endpoint) and 5.2. Error Response (Token Endpoint)

[donald.coffin]

Section 5.2. Error Response for the Token Endpoint states:

 

The authorization server responds with an HTTP 400 (Bad Request)

status code (unless specified otherwise) and includes the following

parameters with the response:


"error":  REQUIRED.  A single ASCII [USASCII

] error code from the
Following:

(error list omitted for breviate)
 
Section 4.1.2.1. Error Response for the Authorization Endpoint contains the
Same error list but no direction about what HTTP status code should be
returned.
Wouldn't it be helpful in the OAuth 2.1 draft to enhance section 4.1.2.1.
Error
Response with the same or similar guidance regarding the current HTTP status
code
to return?

 





 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Crossing Suite E

Dunwoody, GA 30338-8221

 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[donald.coffin]

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:  (949) 636-8571

Email:   donald.cof...@reminetworks.com 
 

 

From: Dominick Baier  
Sent: March 25, 2019 10:39 AM
To: Hans Zandbelt 
Cc: IETF oauth WG ; Nov Matake ; 
vitto...@auth0.com
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 (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:

 

"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 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 
 ) 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 
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/.

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
 

  ) - got early feedback from

Re: [OAUTH-WG] OAuth Digest, Vol 124, Issue 61

[donald.coffin]

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
2335 Dunwoody Xing #E
Dunwoody, GA 30338-8221

Phone:  (949) 636-8571
Email:   donald.cof...@reminetworks.com

-Original Message-
From: OAuth  On Behalf Of oauth-requ...@ietf.org
Sent: February 18, 2019 04:55 PM
To: oauth@ietf.org
Subject: OAuth Digest, Vol 124, Issue 61

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of OAuth digest..."

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth