Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model

Bron,

I notice that JMAP is a protocol built on top of HTTP.  Like JMAP, when the SCIM WG was developing SCIM (RFC7643/7644) we had a lot of participants wanting to define authentication within SCIM too.  This in part came from the popular use of the LDAP “bind” feature as a general purpose authentication database.  “Bind” was never intended to be used this way, it just happened.  In the HTTP world, we recognized we were building on top of HTTP with an already diverse set of authentication schemes.

The trade-off is that you ignore all of the schemes built on top of HTTP (RFC7230) *and* you loose any natural agility in the spec as HTTP and authentication techniques evolve over time.  One limitation of IETF specs is that “versioning” specs is difficult. They are intended to reflect long-term stabilized practices after a period of agile-like ID spec iteration.  

The downside to saying “any HTTP mechanism” is usable is that it does create point-in-time interop challenges as parties have to agree on authentication schemes. However, this is less of an implementation problem as one might think. Most platforms (e.g. Spring, Quarkus) offer all of the popular mechanisms. The challenge therefor becomes one of deployment and configuration rather than implementation.

As an example, as OAuth evolves, the libraries pick up the changes and dependent systems like SCIM pick it up transparently. This speaks to some of the “existing applications” concerns that Hannes mentioned.

So yes, you could narrowly define authentication in JMAP but it’s lifespan will become severely limited as authentication requirements and risks evolve over time.  Case in point. the OAuth WG has had to maintain a sustained evolution of specs and best practices. Why bog JMAP down with such a huge domain as authentication?

Hope this helps.

Phil Hunt
@independentid
phil.hunt@independentid.com

> On Feb 23, 2021, at 7:09 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
> 
> Just to add a little context - this is an offshoot of a discussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/ <https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/>
> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org <mailto:40rhosys.ch@dmarc.ietf.org>> wrote:
> I admit I haven't been present that long in this group, however it might help to start at the beginning. So far I see rfc8620 <https://tools.ietf.org/html/rfc8620> already exists, is there a draft or something else you want to discuss?
> 
> Are you hoping to introduce a new authentication protocol?
> 
> Any additional information would be appreciated.
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
> 
> 
> On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana <brong@fastmailteam.com <mailto:brong@fastmailteam.com>> wrote:
> On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
>> Hey Bron,
>> 
>> (caveat: I only skimmed the other conversation)
>> 
>> I'm trying to figure out how best to digest your message. I feel like I'm missing context in your message, is there something about JMAP required authentication that you're asking to be considered in OAuth. Help me figure out what I'm missing.
> 
> We were told at the time "if you're doing an authentication protocol over HTTP, it's going have to go to OAuth group".
> 
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com <mailto:brong@fastmailteam.com>
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth