3 ms·

Since OIDC is a layer on top of OAuth 2, it inherits its complexity. OAuth 2.1 (currently draft) will help bring some sanity. GNAP - https://oauth.net/gnap/ htt

Since OIDC is a layer on top of OAuth 2, it inherits its complexity. OAuth 2.1 (currently draft) will help bring some sanity. GNAP - https://oauth.net/gnap/ https://oauth.net/gnap/ - will, one day, tie everything.

mooreds 2y ago
GNAP was just codified to be an RFC: https://www.rfc-editor.org/rfc/rfc9635.html https://www.rfc-editor.org/rfc/rfc9635.html When I looked at it a few years ago[0] it seemed like a modernization of OAuth (which still uses form posts(?!?)). But I'm worried about uptake, myself. Haven't had a single client request it or bring it up. 0: https://fusionauth.io/blog/gnap-next-gen-oauth https://fusionauth.io/blog/gnap-next-gen-oauth
- rapnie 2y ago
  I see that the GNAP WG has been closed [0]. I don't know how this works with IETF, but is anyone caring for the spec and its adoption atm? [0] https://mailarchive.ietf.org/arch/msg/txauth/uEXUsdk43TbPllsh1pcXXzgvMzk/ https://mailarchive.ietf.org/arch/msg/txauth/uEXUsdk43TbPlls...
  - jricher 2y ago
    The working group was closed because the core specification is published as a finished RFC: https://www.rfc-editor.org/rfc/rfc9635.html https://www.rfc-editor.org/rfc/rfc9635.html The group's other major work, the GNAP RS specification, has passed IESG final review and is in the queue with the RFC editor. This means that it's finished except for some final text edits and will be a final RFC soon too: https://www.rfc-editor.org/current_queue.php#draft-ietf-gnap-resource-servers https://www.rfc-editor.org/current_queue.php#draft-ietf-gnap... The group closed because it didn't have any more work to do. As for adoption, we've seen it implemented in a handful of spaces around the internet, most of them in places where there are core problems with the OAuth model or GNAP offers cleaner support for some key feature like ephemeral clients or key management.
rapnie 2y ago
PS. I submitted GNAP RFC separately: https://news.ycombinator.com/item?id=42105487 https://news.ycombinator.com/item?id=42105487

mooreds 2y ago

GNAP was just codified to be an RFC: https://www.rfc-editor.org/rfc/rfc9635.html https://www.rfc-editor.org/rfc/rfc9635.html When I looked at it a few years ago[0] it seemed like a modernization of OAuth (which still uses form posts(?!?)). But I'm worried about uptake, myself. Haven't had a single client request it or bring it up. 0: https://fusionauth.io/blog/gnap-next-gen-oauth https://fusionauth.io/blog/gnap-next-gen-oauth

rapnie 2y ago
I see that the GNAP WG has been closed [0]. I don't know how this works with IETF, but is anyone caring for the spec and its adoption atm? [0] https://mailarchive.ietf.org/arch/msg/txauth/uEXUsdk43TbPllsh1pcXXzgvMzk/ https://mailarchive.ietf.org/arch/msg/txauth/uEXUsdk43TbPlls...
- jricher 2y ago
  The working group was closed because the core specification is published as a finished RFC: https://www.rfc-editor.org/rfc/rfc9635.html https://www.rfc-editor.org/rfc/rfc9635.html The group's other major work, the GNAP RS specification, has passed IESG final review and is in the queue with the RFC editor. This means that it's finished except for some final text edits and will be a final RFC soon too: https://www.rfc-editor.org/current_queue.php#draft-ietf-gnap-resource-servers https://www.rfc-editor.org/current_queue.php#draft-ietf-gnap... The group closed because it didn't have any more work to do. As for adoption, we've seen it implemented in a handful of spaces around the internet, most of them in places where there are core problems with the OAuth model or GNAP offers cleaner support for some key feature like ephemeral clients or key management.

rapnie 2y ago

PS. I submitted GNAP RFC separately: https://news.ycombinator.com/item?id=42105487 https://news.ycombinator.com/item?id=42105487