Yes, and: protocol names should be part of the scope names, but I can imagine so many use cases for finer-grained access. Many clients might want read-only access to something like calendar or email data, and the user might find it safer to grant read-only access than full access. As always, there's a tradeoff between options and complexity!
The OAuth resource metadata approach does not work for feature advertisement in the non-HTTP server use cases. There are still mail servers that don't support HTTP! CalDAV, however, it would work fine for. Lisa On Thu, Jul 25, 2024 at 11:18 PM Emelia Smith <emelia= 40brandedcode....@dmarc.ietf.org> wrote: > Hi Neil, > > I mentioned in the zulip chat that I rather like the idea of using > protocol names as scopes, but that maybe you'd want them to be finer > grained. > > On second pass, I'm wondering if it'd make sense to expose a list of > supported resources & protocols for the authorization server, not just > relying on scopes? > > Maybe through using Protected Resources Metadata? > https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-07.html > > Yours, > Emelia > > On 26. Jul 2024, at 07:48, Neil Jenkins <neilj= > 40fastmailteam....@dmarc.ietf.org> wrote: > > > Hi George, > > Thanks for the feedback. > > Section 1.1 > * is there a reason that only email address based login identifiers are > supported? It seems like this profile could be used for other use cases as > well. > > > No, this should just be username. (It is of course likely to be an email > address, but you're right: there's no reason it has to be for the purposes > of this document.) > > Section 1.2 > * I would recommend this document be more generic and then a specific > profile for say IMAP can be defined that then also defines the scopes > required for use with an IMAP server. > * This document can just say that scopes required are out of scope (pun > intended) > > > As mentioned at the IETF meeting this week, it's definitely an open > question whether scopes should be part of this document or a separate one. > I can certainly see an advantage to leaving it out of this profile and then > having another document that pulls it all together (referencing an > autodiscovery RFC, OAuth profile RFC, and listing the scopes). > > Section 2.1 > * Recommend changing the last sentence to... The rest of this document > describes in detail each of the above steps. > > > Sure, that reads better. > > Section 2.2 > * I recognize that Security Considerations will be filled out in a future > version. A topic that needs to be present is the potential implications of > proceeding with the flow when not all the required metadata fields are > present. I suspect most authorization servers do not have a > 'registration_endpoint' URL in their metadata configuration :) > > > If the server's metadata doesn't conform to this profile, then clients > supporting the profile are likely to abort. The point of this profile is to > say "if you implement this as a client you will be able to authenticate > with any server that implements this" and vice versa. If you don't > implement it, you're not following the profile, and there is no > interoperability guaranteed. > > * Can you clarify why the 'token_endpoint_auth_methods_supported' MUST > include "none"? If the client is dynamically registering, then it can > receive it's own instance specific client_id and client_secret which allows > it to authenticate to the token endpoint. Not requiring client > authentication seems dangerous. > * Similar comment for 'revocation_endpoint_auth_methods_supported' > > > We made this none, because the RFC7591 > <https://www.rfc-editor.org/rfc/rfc7591> refers to the client secret as > only "used by confidential clients", which open native clients running on > the user's machine are not. I guess my main question is what does this gain > us? I would rather reduce options wherever possible to increase > interoperability and security while keeping complexity to a minimum. If we > presume there is no security difference in how the client stores the > refresh token and any client secret, what does the client secret add in > this case? > > Section 2.3 > * I do not think the developer should be able to do the registration. > Instead, this should be required to be completed by the client. This will > be the expectation of the Authorization Server if it supports Dynamic > Client Registration. > > > Agreed. > > * There are security implication with using a custom scheme. Best practice > for mobile apps is to use claimed URIs rather than custom schemes. If > custom schemes are the only option in certain cases the risk need to be > clearly called out in the Security Considerations section. > > > This profile is intended for native apps only, which is enforced by only > allowing localhost or private-use schemes for the redirect_uri. Being > able to dynamically register like this to do the OAuth flow would make it > too easy for a phishing site to get the user to grant them access to their > mail/contacts/calendars etc. — with a native app, it could already fake a > browser window and phish the user undetectably, so we're not making the > security situation worse. If the user's downloaded something malicious, > they've already lost. > > * I'm strongly against allowing the 'token_endpoint_auth_method' to be > "none". There is no reason that the default of 'client_secret_basic' can't > be used (as far as I understand the profile). I recommend that the > registration response from the Authorization Server also include a > 'client_secret'. The client can then store the secret appropriately on the > device. This secret is instance specific and hence the device must be > compromised to extract that secret and impersonate the user. > > Section 2.5 > * I believe the client should authenticate itself via some mechanism and > not just present the client_id > > > As above, I'm happy to change this if there's a security advantage. I'm > just trying to understand why the client would be able to store the client > secret securely but not the refresh token (which is also needed to > impersonate the user). And if it can store both the same, how the client > secret adds any extra security? > > 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 mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
