[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Neil Jenkins]

On Fri, 17 May 2024, at 15:04, Aaron Parecki wrote:
> I agree this is a useful profile for this ecosystem. I would be happy to help 
> with this document, as well as help prepare a presentation on this at the 
> next IETF meeting.

Thanks Aaron, that would be much appreciated.

On Sat, 18 May 2024, at 09:11, Lisa Dusseault wrote:
> […] is it the intent that the HTTP-based protocols MUST use DPoP or is that 
> really a RECOMMENDED for HTTP-based servers ?  Ie. did you intend "RECOMMEND 
> use DPop" to mean  "MUST if you can but not if you can't" ? 

My current intention was to leave it at RECOMMENDED, but it could be upgraded 
to a MUST. It's clearly a security/implementation difficulty trade-off. I'd 
want to talk to some more server implementers on their plans, and see the OAuth 
community's thoughts.

> I know your document says that a separate document will define the scopes, 
> but if you pull the scopes into this document ISTM it will really be a 
> complete solution to many use cases. Without the scopes this does not stand 
> alone and implementable and interoperable, whereas I think that just adding 
> scopes will make it so. 

Agreed. To be clear, we discussed the scopes problem at the mailbox-providers 
conference and came to a tentative conclusion of using the JMAP capabilities 
 as scopes 
to represent the data types being accessed, regardless of protocol (so you 
would use the `urn:ietf:params:jmap:mail` scope for access to mail whether via 
JMAP or IMAP — it's the same data and same security capability).

Where this should be documented I'm not sure, which is why I omitted it from 
this document for now. The 3 pieces of the puzzle are autodiscovery (there's 
still a lot of discussion to be had there about the best approach), the OAuth 
profile, and the set of scopes. It might be nice if all of this were in one 
document, or they could be separate with perhaps a brief extra document that 
says to use all of them together for interoperability. I don't know.

On Sun, 19 May 2024, at 20:55, Vladimir Dzhuvinov wrote:
> The dynamic client registration (DCR) will probably need implementers to 
> consider measures against DoS attacks. One such measure could be the 
> automatic expiration of client registrations that remain unused or where the 
> client doesn't receive a token within a certain time.

Yes. I have discussed this with a number of people and that's certainly one of 
the mitigations we should recommend in the security considerations.

Cheers,
Neil.___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Vladimir Dzhuvinov]

Interesting draft. Having standard defined scopes for the most common operations of the underlying protocols is crucial, as Lisa points out. In OpenID Connect this was indispensable in making the whole thing complete, useful and interoperable. But where should these scopes get defined, if this is a spec for a general open public profile, and not email specific? ( as implied by the title )The dynamic client registration (DCR) will probably need implementers to consider measures against DoS attacks. One such measure could be the automatic expiration of client registrations that remain unused or where the client doesn't receive a token within a certain time.On 18 May 2024, at 1:12, Lisa Dusseault  wrote:Hi Neil,Thanks for publishing this, it's really great and will be most helpful.  The explanation of when the server uses DPoP and therefore when the client uses DPoP is pretty clear, but is it the intent that the HTTP-based protocols MUST use DPoP or is that really a RECOMMENDED for HTTP-based servers ?  Ie. did you intend "RECOMMEND use DPop" to mean  "MUST if you can but not if you can't" ? I know your document says that a separate document will define the scopes, but if you pull the scopes into this document ISTM it will really be a complete solution to many use cases. Without the scopes this does not stand alone and implementable and interoperable, whereas I think that just adding scopes will make it so.  (Also, I don't think the autodiscovery document will need to be a dependency but I may be wrong. ). You've clearly already thought about whether the scopes should be in this document or not,  can you expand on that?  I would love it if this went to the Standards Track.  Lisa DusseaultOn Thu, May 16, 2024 at 8:56 PM Neil Jenkins 40fastmailteam@dmarc.ietf.org> wrote:Hello all,I have published a draft document I'd like to introduce to the working group to consider: OAuth Profile for Open Public Clients.BackgroundI work for Fastmail, and we organised a conference at the end of last year with a bunch of the other major mailbox providers to work on interoperability and improving the open ecosystem. The topic most on everyone's minds was authentication.Unlike all the walled garden messaging systems, email remains to a large extent open. There are standard protocols (IMAP [RFC9051], SMTP [RFC5321], and more recently JMAP [RFC8620][RFC8621]) so you can have clients and servers built by different vendors, with no pre-existing relationship. Indeed, there are probably thousands of clients, and hundreds of thousands of servers out there. The situation is similar with contacts and calendars.Most server providers (and indeed many client authors) would like to move to a more secure authentication system, but at the moment basic auth is the only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft OAuth flows (as those companies are big enough to force them to do so!), but this does not scale. At the conference we worked on building an OAuth profile that we believe can significantly increase security compared to the current status quo, to allow native Email/Contacts/Calendar clients to authenticate with an arbitrary server.I have talked to a few of you individually at the last couple of IETF meetings, and have finally had time to write up our proposal.Next stepsFirst of all, hopefully the working group can agree that this is a problem space that is significant, and worth addressing. If so, I hope it chooses to adopt this document as  a good starting point. I am not sure whether this should be a BCP rather than Standards Track — it deliberately does not introduce anything new, just combines a lot of existing standards in a specific way suitable for this use case.I will not be in Vancouver in person, but will join remotely. I do plan to be in Dublin. My current understanding is there are vendors such as Apple looking to start implementing something in this space in the nearish future, and obviously we would all like an agreed profile to ensure interoperability! They may be able to send someone to Vancouver.I would be very happy to bring on a co-author (or indeed largely pass it over to them, as I am very busy with other work at the moment, hence the delay in getting this draft together). I will certainly remain involved in any discussions around this area of course.I look forward to your feedback.Cheers,Neil.___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___OAuth mailing list -- oauth@ietf.orgTo unsubscribe send an email to oauth-le...@ietf.org

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Lisa Dusseault]

Hi Neil,

Thanks for publishing this, it's really great and will be most helpful.
The explanation of when the server uses DPoP and therefore when the client
uses DPoP is pretty clear, but is it the intent that the HTTP-based
protocols MUST use DPoP or is that really a RECOMMENDED for HTTP-based
servers ?  Ie. did you intend "RECOMMEND use DPop" to mean  "MUST if you
can but not if you can't" ?

I know your document says that a separate document will define the scopes,
but if you pull the scopes into this document ISTM it will really be a
complete solution to many use cases. Without the scopes this does not stand
alone and implementable and interoperable, whereas I think that just adding
scopes will make it so.  (Also, I don't think the autodiscovery document
will need to be a dependency but I may be wrong. ). You've clearly already
thought about whether the scopes should be in this document or not,  can
you expand on that?

I would love it if this went to the Standards Track.

Lisa Dusseault

On Thu, May 16, 2024 at 8:56 PM Neil Jenkins  wrote:

> Hello all,
>
> I have published a draft document I'd like to introduce to the working
> group to consider: OAuth Profile for Open Public Clients
> .
>
> *Background*
>
> I work for Fastmail , and we organised a
> conference at the end of last year with a bunch of the other major mailbox
> providers to work on interoperability and improving the open ecosystem. The
> topic most on everyone's minds was authentication.
>
> Unlike all the walled garden messaging systems, email remains to a large
> extent open. There are standard protocols (IMAP [RFC9051]
> , SMTP [RFC5321]
> , and more recently JMAP
> [RFC8620] [RFC8621]
> ) so you can have clients
> and servers built by different vendors, with no pre-existing relationship.
> Indeed, there are probably thousands of clients, and hundreds of thousands
> of servers out there. The situation is similar with contacts and calendars.
>
> Most server providers (and indeed many client authors) would like to move
> to a more secure authentication system, but at the moment basic auth is the
> only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft
> OAuth flows (as those companies are big enough to force them to do so!),
> but this does not scale. At the conference we worked on building an OAuth
> profile that we believe can significantly increase security compared to the
> current status quo, to allow native Email/Contacts/Calendar clients to
> authenticate with an arbitrary server.
>
> I have talked to a few of you individually at the last couple of IETF
> meetings, and have finally had time to write up our proposal.
>
> *Next steps*
>
> First of all, hopefully the working group can agree that this is a problem
> space that is significant, and worth addressing. If so, I hope it chooses
> to adopt this document as  a good starting point. I am not sure whether
> this should be a BCP rather than Standards Track — it deliberately does not
> introduce anything new, just combines a lot of existing standards in a
> specific way suitable for this use case.
>
> I will not be in Vancouver in person, but will join remotely. I do plan to
> be in Dublin. My current understanding is there are vendors such as Apple
> looking to start implementing something in this space in the nearish
> future, and obviously we would all like an agreed profile to ensure
> interoperability! They may be able to send someone to Vancouver.
>
> I would be very happy to bring on a co-author (or indeed largely pass it
> over to them, as I am very busy with other work at the moment, hence the
> delay in getting this draft together). I will certainly remain involved in
> any discussions around this area of course.
>
> I look forward to your feedback.
>
> Cheers,
> Neil.
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Kai Lehmann]

What an awesome coincidence. We at GMX and WEB.DE are currently working on 
OAuth support for our mail servers as well and already see the issue in getting 
the clients to properly configure and connect with mail servers via OAuth. We 
will definitely look into the proposal and are happy to give feedback and 
contribute to this work.

Kai


From: Aaron Parecki 
Date: Friday, 17. May 2024 at 07:06
To: Neil Jenkins 
Cc: OAuth WG 
Subject: [OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

Thanks for writing this up! I remember talking about this with you at a past 
IETF meeting.

I agree this is a useful profile for this ecosystem. I would be happy to help 
with this document, as well as help prepare a presentation on this at the next 
IETF meeting.
---
Aaron Parecki



On Thu, May 16, 2024 at 8:56 PM Neil Jenkins 
mailto:40fastmailteam@dmarc.ietf.org>>
 wrote:
Hello all,

I have published a draft document I'd like to introduce to the working group to 
consider: OAuth Profile for Open Public 
Clients<https://www.ietf.org/archive/id/draft-jenkins-oauth-public-00.html>.

Background

I work for Fastmail<https://www.fastmail.com/>, and we organised a conference 
at the end of last year with a bunch of the other major mailbox providers to 
work on interoperability and improving the open ecosystem. The topic most on 
everyone's minds was authentication.

Unlike all the walled garden messaging systems, email remains to a large extent 
open. There are standard protocols (IMAP 
[RFC9051]<https://www.rfc-editor.org/rfc/rfc9051.html>, SMTP 
[RFC5321]<https://datatracker.ietf.org/doc/html/rfc5321>, and more recently 
JMAP 
[RFC8620]<https://datatracker.ietf.org/doc/html/rfc8620>[RFC8621]<https://datatracker.ietf.org/doc/html/rfc8621>)
 so you can have clients and servers built by different vendors, with no 
pre-existing relationship. Indeed, there are probably thousands of clients, and 
hundreds of thousands of servers out there. The situation is similar with 
contacts and calendars.

Most server providers (and indeed many client authors) would like to move to a 
more secure authentication system, but at the moment basic auth is the only 
interoperable mechanism. Many clients have hardcoded Gmail/Microsoft OAuth 
flows (as those companies are big enough to force them to do so!), but this 
does not scale. At the conference we worked on building an OAuth profile that 
we believe can significantly increase security compared to the current status 
quo, to allow native Email/Contacts/Calendar clients to authenticate with an 
arbitrary server.

I have talked to a few of you individually at the last couple of IETF meetings, 
and have finally had time to write up our proposal.

Next steps

First of all, hopefully the working group can agree that this is a problem 
space that is significant, and worth addressing. If so, I hope it chooses to 
adopt this document as  a good starting point. I am not sure whether this 
should be a BCP rather than Standards Track — it deliberately does not 
introduce anything new, just combines a lot of existing standards in a specific 
way suitable for this use case.

I will not be in Vancouver in person, but will join remotely. I do plan to be 
in Dublin. My current understanding is there are vendors such as Apple looking 
to start implementing something in this space in the nearish future, and 
obviously we would all like an agreed profile to ensure interoperability! They 
may be able to send someone to Vancouver.

I would be very happy to bring on a co-author (or indeed largely pass it over 
to them, as I am very busy with other work at the moment, hence the delay in 
getting this draft together). I will certainly remain involved in any 
discussions around this area of course.

I look forward to your feedback.

Cheers,
Neil.
___
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Aaron Parecki]

Thanks for writing this up! I remember talking about this with you at a
past IETF meeting.

I agree this is a useful profile for this ecosystem. I would be happy to
help with this document, as well as help prepare a presentation on this at
the next IETF meeting.

---
Aaron Parecki



On Thu, May 16, 2024 at 8:56 PM Neil Jenkins  wrote:

> Hello all,
>
> I have published a draft document I'd like to introduce to the working
> group to consider: OAuth Profile for Open Public Clients
> .
>
> *Background*
>
> I work for Fastmail , and we organised a
> conference at the end of last year with a bunch of the other major mailbox
> providers to work on interoperability and improving the open ecosystem. The
> topic most on everyone's minds was authentication.
>
> Unlike all the walled garden messaging systems, email remains to a large
> extent open. There are standard protocols (IMAP [RFC9051]
> , SMTP [RFC5321]
> , and more recently JMAP
> [RFC8620] [RFC8621]
> ) so you can have clients
> and servers built by different vendors, with no pre-existing relationship.
> Indeed, there are probably thousands of clients, and hundreds of thousands
> of servers out there. The situation is similar with contacts and calendars.
>
> Most server providers (and indeed many client authors) would like to move
> to a more secure authentication system, but at the moment basic auth is the
> only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft
> OAuth flows (as those companies are big enough to force them to do so!),
> but this does not scale. At the conference we worked on building an OAuth
> profile that we believe can significantly increase security compared to the
> current status quo, to allow native Email/Contacts/Calendar clients to
> authenticate with an arbitrary server.
>
> I have talked to a few of you individually at the last couple of IETF
> meetings, and have finally had time to write up our proposal.
>
> *Next steps*
>
> First of all, hopefully the working group can agree that this is a problem
> space that is significant, and worth addressing. If so, I hope it chooses
> to adopt this document as  a good starting point. I am not sure whether
> this should be a BCP rather than Standards Track — it deliberately does not
> introduce anything new, just combines a lot of existing standards in a
> specific way suitable for this use case.
>
> I will not be in Vancouver in person, but will join remotely. I do plan to
> be in Dublin. My current understanding is there are vendors such as Apple
> looking to start implementing something in this space in the nearish
> future, and obviously we would all like an agreed profile to ensure
> interoperability! They may be able to send someone to Vancouver.
>
> I would be very happy to bring on a co-author (or indeed largely pass it
> over to them, as I am very busy with other work at the moment, hence the
> delay in getting this draft together). I will certainly remain involved in
> any discussions around this area of course.
>
> I look forward to your feedback.
>
> Cheers,
> Neil.
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org