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
<https://www.iana.org/assignments/jmap/jmap.xhtml#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
