Subject: [OAUTH-WG] Error Registry Consensus Call

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 May 2012 01:48:16 +0300

Hi all, 

there is an open issue concerning draft-ietf-oauth-v2-bearer-19 that may impact draft-ietf-oauth-v2-26 (depending on it's resolution) and we would like to get feedback from the working group about it. 

Here is the issue: When a client makes an access to a protected resources then things may go wrong and an error may be returned in response. draft-ietf-oauth-v2-bearer talks about this behavior. 

That's great but these error codes need to be registered somewhere. Note that the registry can be created in one document while the values can be registered by many documents. 

So, where should the registry be?

There are two choices. 

a) A new OAuth errors registry goes into draft-ietf-oauth-v2-bearer.

b) draft-ietf-oauth-v2 expands the scope of the existing OAuth Errors registry to encompass errors returned from resource servers.

Currently, draft-ietf-oauth-v2 creates registries for error codes only for the exchanges from A-to-D (symbols used from Figure 1 of draft-ietf-oauth-v2), but excludes registration of errors from flows E-F.

We must create a registry for error codes from flows E-F.  In which document do we want to create this registry?

So, give us your feedback whether you have a preference by the end of the week. 

Ciao
Hannes & Derek

---

From: Mike Jones <[email-masked]>
Date: Mon, 7 May 2012 22:55:30 +0000

b) - a single OAuth errors registry for all of exchanges A-F of the protocol

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, May 07, 2012 3:48 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Error Registry Consensus Call

Hi all, 

There are two choices. 

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer <[email-masked]>
Date: Mon, 7 May 2012 23:06:51 +0000

A.

For the following reasons (all extensively discussed on this list before):

1. The OAuth core specification has nothing to do with HTTP authentication schemes.
2. The bearer specification is a general purpose HTTP Auth scheme and defining such a registry needs to be defined within those boundaries - that is, either specific to Bearer to generic to all HTTP Auth scheme opting into the error parameter.
3. There wasn't strong consensus that the error parameter was even necessary or useful to begin with. Limiting it to bearer reflects the wider IETF consensus on the matter (based on feedback received at the time from the HTTPbis WG).
4. It would be odd for someone using the bearer scheme outside of OAuth to use the OAuth error registry (and take over values that will be helpful for the core specification).
5. There is no overlap in functionality or values between the protected resource endpoint (which is part of the proprietary API namespace) and the OAuth endpoint for which the registry was created. To piggyback the OAuth registry just because it is slightly easier would be wrong. There is no interop value accomplished.

This is not simply a question of where to stick the registry. Adding this to the OAuth registry would be a fundamental change in architecture and philosophy and a significant change at this point. Adding it to the bearer specification is the only viable option.

I would request that such a change go through another IETF LC if this was the WG consensus but hope we can avoid it.

EH

> there is an open issue concerning draft-ietf-oauth-v2-bearer-19 that may
> impact draft-ietf-oauth-v2-26 (depending on it's resolution) and we would
> like to get feedback from the working group about it.
> 
> Here is the issue: When a client makes an access to a protected resources
> then things may go wrong and an error may be returned in response. draft-
> ietf-oauth-v2-bearer talks about this behavior.
> 
> That's great but these error codes need to be registered somewhere. Note
> that the registry can be created in one document while the values can be
> registered by many documents.
> 
> b) draft-ietf-oauth-v2 expands the scope of the existing OAuth Errors
> registry to encompass errors returned from resource servers.
> 
> Currently, draft-ietf-oauth-v2 creates registries for error codes only for the
> exchanges from A-to-D (symbols used from Figure 1 of draft-ietf-oauth-v2),
> but excludes registration of errors from flows E-F.
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 7 May 2012 23:12:17 +0000

The bearer spec is not intended as a general purpose HTTP Auth scheme.  Note that it includes a "scope" response, which firmly anchors it to use with OAuth, where it provides flows E-F which follow flows A-D that are specified in the framework spec - thus completing the end-to-end OAuth protocol usage flows.

These are OAuth-specific errors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Monday, May 07, 2012 4:07 PM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Error Registry Consensus Call

A.

EH

> there is an open issue concerning draft-ietf-oauth-v2-bearer-19 that 
> may impact draft-ietf-oauth-v2-26 (depending on it's resolution) and 
> we would like to get feedback from the working group about it.
> 
> Here is the issue: When a client makes an access to a protected 
> resources then things may go wrong and an error may be returned in 
> response. draft- ietf-oauth-v2-bearer talks about this behavior.
> 
> That's great but these error codes need to be registered somewhere. 
> Note that the registry can be created in one document while the values 
> can be registered by many documents.
> 
> Currently, draft-ietf-oauth-v2 creates registries for error codes only 
> for the exchanges from A-to-D (symbols used from Figure 1 of 
> draft-ietf-oauth-v2), but excludes registration of errors from flows E-F.
> 
> We must create a registry for error codes from flows E-F.  In which 
> document do we want to create this registry?
>

---

From: John Bradley <[email-masked]>
Date: Mon, 7 May 2012 19:19:45 -0400

b)  Unless we remove the OAuth specific errors from bearer it should be in  oath-v2.   

One registry is preferable. 

John B.

---

From: Eran Hammer <[email-masked]>
Date: Mon, 7 May 2012 23:20:40 +0000

Errors that have nothing to do with the core spec. There is not overlap in functionality between the two documents and their use cases.

EH

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, May 07, 2012 4:12 PM
> To: Eran Hammer; Hannes Tschofenig; [email-masked] WG
> Subject: RE: [OAUTH-WG] Error Registry Consensus Call
> 
> The bearer spec is not intended as a general purpose HTTP Auth scheme.
> Note that it includes a "scope" response, which firmly anchors it to use with
> OAuth, where it provides flows E-F which follow flows A-D that are specified
> in the framework spec - thus completing the end-to-end OAuth protocol
> usage flows.
> 
> 2. The bearer specification is a general purpose HTTP Auth scheme and
> defining such a registry needs to be defined within those boundaries - that is,
> either specific to Bearer to generic to all HTTP Auth scheme opting into the
> error parameter.
> 3. There wasn't strong consensus that the error parameter was even
> necessary or useful to begin with. Limiting it to bearer reflects the wider IETF
> consensus on the matter (based on feedback received at the time from the
> HTTPbis WG).
> 4. It would be odd for someone using the bearer scheme outside of OAuth to
> use the OAuth error registry (and take over values that will be helpful for the
> core specification).
> 5. There is no overlap in functionality or values between the protected
> resource endpoint (which is part of the proprietary API namespace) and the
> OAuth endpoint for which the registry was created. To piggyback the OAuth
> registry just because it is slightly easier would be wrong. There is no interop
> value accomplished.
> 
> This is not simply a question of where to stick the registry. Adding this to the
> OAuth registry would be a fundamental change in architecture and
> philosophy and a significant change at this point. Adding it to the bearer
> specification is the only viable option.
>

---

From: Eran Hammer <[email-masked]>
Date: Mon, 7 May 2012 23:22:53 +0000

Why? What's the gain here? The only purpose of the registry is to avoid namespace collision. There can be no collision between the core specification and the bearer specification. They are describing completely different things. IANA does all the work anyway, and they two registry CAN share one review mailing list.

EH

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Bradley
> Sent: Monday, May 07, 2012 4:20 PM
> To: Hannes Tschofenig
> Cc: [email-masked] WG

---

From: William Mills <[email-masked]>
Date: Mon, 7 May 2012 16:39:41 -0700 (PDT)

I am in favor of making it part of the base Oauth 2 spec, rather than defining this in a single token draft.  It seems something that SHOULD be part of the framework.

There's a 3rd option which would be to have a separate doc, but that seems a kludge.

-bill

>________________________________
> From: Hannes Tschofenig <[email-masked]>
>To: "[email-masked] WG" <[email-masked]> 
>Sent: Monday, May 7, 2012 3:48 PM

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 May 2012 01:55:42 +0200

I prefer single repository.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: George Fletcher <[email-masked]>
Date: Mon, 07 May 2012 19:56:17 -0400

I agree that one registry is desired!

On 5/7/12 7:19 PM, John Bradley wrote:
>> Hannes&  Derek

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 8 May 2012 06:07:33 +0000

Agree on a single registry

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Monday, May 07, 2012 4:56 PM
To: Hannes Tschofenig
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Error Registry Consensus Call

John B.

Hi all,

There are two choices.

Ciao

Hannes & Derek

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>