Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-04.txt

From: [email-masked]
Date: Wed, 03 Aug 2016 13:49:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

        Title           : OAuth 2.0 Authorization Server Metadata
        Authors         : Michael B. Jones
                          Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-discovery-04.txt
	Pages           : 23
	Date            : 2016-08-03

Abstract:
   This specification defines a metadata format that an OAuth 2.0 client
   can use to obtain the information needed to interact with an OAuth
   2.0 authorization server, including its endpoint locations and
   authorization server capabilities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Pedro Felix <[email-masked]>
Date: Fri, 5 Aug 2016 19:22:01 +0100

Hi,

What's the proper way to provide feedback on the "OAuth 2.0 Authorization
Server Metadata" spec?
In my opinion, section 3.2 is unnecessarily constraining the use of HTTP to
transfer the metadata representation by mandating ("MUST") a 200 status
code on a successful response. For instance, the server may support caching
and conditional requests, where a 304 (Not Modified) also represents
success. Another example is if the server wants to direct the client to a
different URL by using a 301, 302, 307 or 308. A return with any of these
codes does not represent failure. It just means that an additional request
is required.

IMO, the spec should focus on the format semantics and leave the transfer
semantics for HTTP.

Regards
Pedro

On Wed, Aug 3, 2016 at 9:49 PM, <[email-masked]> wrote:

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