Simon Willison's Weblog: rfc

Grant Negotiation and Authorization Protocol (GNAP)

2024-10-14T05:22:15+00:00

Grant Negotiation and Authorization Protocol (GNAP)

RFC 9635 was published a few days ago. GNAP is effectively OAuth 3 - it's a newly standardized design for a protocol for delegating authorization so an application can access data on your behalf.

The most interesting difference between GNAP and OAuth 2 is that GNAP no longer requires clients to be registered in advance. With OAuth the client_id and client_secret need to be configured for each application, which means applications need to register with their targets - creating a new application on GitHub or Twitter before implementing the authorization flow, for example.

With GNAP that's no longer necessary. The protocol allows a client to provide a key as part of the first request to the server which is then used in later stages of the interaction.

GNAP has been brewing for a long time. The IETF working group was chartered in 2020, and two of the example implementations (gnap-client-js and oauth-xyz-nodejs) last saw commits more than four years ago.

Via lobste.rs

Tags: oauth, rfc, security

RFC 7807: Problem Details for HTTP APIs

2022-11-01T03:15:05+00:00

RFC 7807: Problem Details for HTTP APIs

This RFC has been brewing for quite a while, and is currently in last call (ends 2022-11-03). I’m designing the JSON error messages for Datasette at the moment so this could not be more relevant for me.

Via Nicolas Fränkel

Tags: errors, http, json, mark-nottingham, rfc, standards

How to Read an RFC

2018-08-06T22:38:21+00:00

How to Read an RFC

An extremely useful guide to reading RFCs by Mark Nottingham. I didn’t know most of the stuff in here.

Tags: mark-nottingham, rfc

RFC5785: Defining Well-Known Uniform Resource Identifiers

2010-04-11T19:32:28+00:00

RFC5785: Defining Well-Known Uniform Resource Identifiers

Sounds like a very good idea to me: defining a common prefix of /.well-known/ for well-known URLs (common metadata like robots.txt) and establishing a registry for all such files. OAuth, OpenID and other decentralised identity systems can all benefit from this.

Via Mark Nottingham

Tags: oauth, openid, rfc, robots-txt, urls, wellknownurls

Quoting James Snell

2007-11-18T00:15:22+00:00

I think it is well established that HTTP Authentication needs a major kick in the ass and OpenID and OAuth may get us most of the way there. However, until I see RFC#s attached to both I'm hardly going to consider them to be complete. I propose the creation of an IETF WG on Identity and Authentication. The WG would be chartered to produce two RFCs covering each of the two areas. OpenID and OAuth could be used to seed the WG effort.

— James Snell

Tags: http, ietf, james-snell, oauth, openid, rfc, standardisation, standards

RFC 5023: The Atom Publishing Protocol

2007-10-09T10:17:52+00:00

RFC 5023: The Atom Publishing Protocol

It’s done!

Tags: atom, atompub, rfc

Proposed RFC for application/json

2006-08-01T21:29:17+00:00

Proposed RFC for application/json

Douglas Crockford is putting JSON through the IETF.

Via davidflanagan.com

Tags: douglas-crockford, ietf, json, rfc

Fighting RFCs with RFCs

2005-05-06T20:39:45+00:00

Google's recently released Web Accelerator apparently has some scary side-effects. It's been spotted pre-loading links in password-protected applications, which can amount to clicking on every "delete this" link - bypassing even the JavaScript prompt you carefully added to give people the chance to think twice.

"Aah," I hear you cry, "but RFC 2616 clearly states that you shouldn't perform state changing operations with a GET or HEAD method!"

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.

I'll see your RFC 2616 and raise you an RFC 2119:

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Hiding your dangerous delete links behind an authentication scheme is a perfectly acceptable compromise. Web Accelerator is B.A.D.

Update: Be sure to read the excellent discussion brewing in the comments. Hiding behind authentication may not be as acceptable a compromise as I had first thought.

Update 2: If you haven't been following the comments, I've had a change of heart. Even in the absence of Web Accelerator, hiding behind authentication leaves your application open to some very nasty security vulnerabilities (malicious pages can piggy-back your session and cause havoc making dangerous GET calls). I still think the RFC language covers people who thought long and hard before implementing a dangerous GET, but if you haven't thought about security and accelerating caching proxies such as Web Accelerator you haven't been thinking hard enough.

Update 3: So, it turns out using POST is no defence at all against CSRF attacks. I've been learning a whole bunch of interesting stuff this evening.

Tags: csrf, google, http, rfc, security, standards

RFC 1925: The Twelve Networking Truths

2004-11-20T21:26:10+00:00

RFC 1925: The Twelve Networking Truths

“This memo documents the fundamental truths of networking for the Internet community.”

Tags: rfc

RFC 3229: Delta encoding in HTTP

2004-09-13T23:09:39+00:00

RFC 3229: Delta encoding in HTTP

A solution to the RSS bandwidth problem?

Via As I May Think...: Using RFC3229 with Feeds.

Tags: http, rfc, rss