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

[Bron Gondwana <[e-mail]>]

Yeah - the discussion has wandered into the weeds (and I'm largely responsible for this) about whether the way JMAP was proposing doing Authentication was the right way, rather than the meta topic which started this which was "my impression on joining the IETF was that OAuth working group was toxic and unwelcoming to new work, and taking anything there was a sure-fire way to make sure nothing got progressed".

And my experience of being a tourist in the OAuth face-to-face meetings was consistent with that impression.  There was an awfully large amount of talking and an awfully small amount of listening going on - with the IETF102 Thursday meeting being particularly bad (I had a clash for Tuesday's meeting, so I don't know how that one went).

Maybe it's a completely different place now - but one of two things must be true:

a) the OAuth group is insular and unwelcoming; or
b) there's a false impression of the OAuth group that's been circulating for years, at least within the applications area which is where I spend most of my time.

Back on the specifics...

I do want to quote this: *"The challenge therefor becomes one of deployment and configuration rather than implementation."* because that's part of the impression that I got of OAuth. I come from a world where deployment and configuration are major hurdles, and in fact OAuth interoperability is a major mess because it's such a flexible toolkit.  Just this week I've run into issues where Yahoo's SMTP "XOAUTH2" is behaving differently from Google's and we had delivery issues for authenticated sending.

If every client and every server needs to implement "*all the popular mechanisms*" then that's not such a big deal when you're shipping the client code for your own server as part of a website, but it's a big deal if you're trying to create a general client and don't want to have to hard-code the specific magic for each server provider.

So the reason to encode the authentication mechanism into JMAP was precisely to reduce the number of possibilities.

Bron.

On Wed, Feb 24, 2021, at 07:02, Phil Hunt wrote:
> 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
> [e-mail]
> 
> 
> 
>> On Feb 23, 2021, at 7:09 AM, Brian Campbell <bcampbell=[e-mail]> 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/
>> 
>> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad <wparad=[e-mail]> 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 <[e-mail]> 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
>>>>   [e-mail]
>>>> 
>>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]