[mooreds]

This document just graduated to the full WG[0][1]. So this isn't a full fledged, ready to implement, draft.

I've been doing some research on this for an upcoming presentation and it seems this was a union of the design ideas of two draft documents TxAuth and OAuth.xyz, which means there's a few issues that need to be resolved. I'm sure they'd welcome respectful feedback.

From the WG's charter[2], they are looking for feedback and comments and expect last call for the core protocol in July 2021.

It's still very much a work in progress. I counted the TBDs and "Editor's notes" and found an average of one of these "TODO" markers per page of the draft.

I'm excited about the more modern developer ergonomics (using JSON is a step up from using form params), the ability for an RC to request user info at the same time (folding in some of OIDC), and fact they've explicitly built interaction extensions into the model. OAuth2 often assumes a browser with redirect capabilities and there are some inelegant solutions that arise from that[3]. Still a lot of things to iron out, for sure, though.

That said, I think OAuth2 will still be common 3 years from now, and if OAuth2 satisfies your needs, you aren't forced to move on to this new, explicitly not backward compatible[4], auth protocol.

[0]: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protoco...

[1]: https://mailarchive.ietf.org/arch/msg/txauth/UkvrBXkMk9YMl7m...

[2]: https://datatracker.ietf.org/wg/gnap/about/

[3]: https://fusionauth.io/blog/2020/08/19/securing-react-native-... shows that you have to have a redirect with a custom scheme for a mobile app. Seems weird to me.

[4]: "Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible." - https://datatracker.ietf.org/wg/gnap/about/

[will4274]

> using JSON is a step up from using form params

Why? It seems to me that I'm either writing Json.Serialize(loginParams) or HttpForms.Serialize(loginParams). Both are human readable and weakly typed. From a developer perspective, these seem almost exactly equivalent, just different.

[mooreds]

Ah, in my opinion, it's better to be able to build an object then serialize it, rather than have to jam object semantics into form parameters (and then serialize them).

Here's a grant request from the draft:

   {
       "resources": [
           {
               "type": "photo-api",
               "actions": [
                   "read",
                   "write",
                   "dolphin"
               ],
               "locations": [
                   "https://server.example.net/",
                   "https://resource.local/other"
               ],
               "datatypes": [
                   "metadata",
                   "images"
               ]
           },
           "dolphin-metadata"
       ],
       "client": {
         "display": {
           "name": "My Client Display Name",
           "uri": "https://example.net/client"
         },
         "key": {
           "proof": "jwsd",
           "jwk": {
                       "kty": "RSA",
                       "e": "AQAB",
                       "kid": "xyz-1",
                       "alg": "RS256",
                       "n": "kOB5rR4Jv0GMeL...."
           }
         }
       },
       "interact": {
           "redirect": true,
           "callback": {
               "method": "redirect",
               "uri": "https://client.example.net/return/123455",
               "nonce": "LKLTI25DK82FX4T4QFZC"
           }
       },
       "capabilities": ["ext1", "ext2"],
       "subject": {
           "sub_ids": ["iss-sub", "email"],
           "assertions": ["id_token"]
       }
   }

(Not all of the object keys are required, FYI). The ability to have resources be a rich object (as opposed to a string) and to support multiple resources in one grant request seems to me to be a good thing(tm).