[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Phillip Hunt]

+1. I agree this is ready. PhilOn May 17, 2024, at 1:35 PM, Giuseppe De Marco  wrote:+1 for publicationIl giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef  ha scritto:All,This is a second WG Last Call for the OAuth 2.0 Protected Resource Metadata document (the previous one was for v03.).https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.htmlPlease, review this document and reply on the mailing list if you have any comments or concerns, by May 29.If you reviewed the document and you do not have any comments or concerns, it would be great if you can reply to this email indicating that.Regards,  Rifaat & Hannes
___
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___
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] Transaction Token Service deployment models

[George Fletcher]

I’ve opened a new issue to discuss Transaction Token Service deployment
models:

https://github.com/oauth-wg/oauth-transaction-tokens/issues/96


I’ve added one comment. Please consider adding different deployments models
(or comment on the one I added) as this will help determine if more text is
needed in the specification.


Thanks,

George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Aaron Parecki]

As a co-author of the draft, I believe we've addressed all the first WGLC
comments and that this is ready for publication. Thanks!

Aaron

On Wed, May 15, 2024 at 9:05 AM Michael Jones 
wrote:

> Having addressed the first WGLC comments in -04 and adding a pretty
> diagram in -05, I believe this is ready for publication.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Wednesday, May 15, 2024 7:11 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Second WGLC for OAuth 2.0 Protected Resource
> Metadata
>
>
>
> All,
>
> This is a *second* *WG Last Call* for the *OAuth 2.0 Protected Resource
> Metadata* document (the previous one was for v03.).
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html
>
>
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 29*.
>
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> Regards,
>   Rifaat & Hannes
> ___
> 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: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Giuseppe De Marco]

+1 for publication

Il giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> This is a *second* *WG Last Call* for the *OAuth 2.0 Protected Resource
> Metadata* document (the previous one was for v03.).
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 29*.
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> Regards,
>   Rifaat & Hannes
> ___
> 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.

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