Proposal: Credentials Retrieve Requests must not request disjoint authentication domains

[dxslly]

Background

Currently the OpenYolo specification allows clients to request credentials that are disjoint from the caller's authentication domain.

The set of authentication domains specified in the request may be disjoint from the set of domains known to be related to the requester (via its package name): such requests would allow trusted intermediaries (e.g. keyboard apps, mail clients, etc.) to request credentials that they do not directly own. It is the responsibility of the credential provider to determine whether to permit such requests. Typically, requests should only be permitted for an authentication domain that is provably associated with to the requester, or if the app has been explicitly whitelisted (by the user or provider) to request credentials outside its equivalence class.

Motivation

• The motivation to support requesting disjoint authentication domains appears to be an edge case and opens a path for a regression in good identity practices. Retrieving these credentials allows for a 3P to impersonate a user and circumvent good authorization practices. I believe that any client that wishes to request a disjoint authentication domain should instead forward their request to the given requested authentication domain which then may use OpenYolo if they choose.
• This change will reduce the complexity of the API and SPI resulting in less work for both credential providers and credential requesters implementing OpenYolo.

Proposal

Remove the ability for clients to request a set of authentication domains in credential retrieve requests. In its place only the implied authentication domain as determined by the caller's package and signature must be used.

Interested in everyone's thoughts. Is there a motivating use case to support it?

[iainmcgin]

@smarkovik and @StanKocken were the originators of this idea, it would be good to hear their perspective. I think I support removing this for the initial release and more carefully think about the use cases for "masquerading" as another app for credential retrieval. The most prominent use case (keyboard integration) should have no UI, so that may actually deserve it's own API methods for direct credential retrieval.

[smarkovik]

At last some chatter on openYolo. I must say it's refreshing to reply on a thread in this repo.

I believe this is quite an important feature in a final api, as it would allow any app to request any credential, which is the sole purpose of a credential manager To manage your credentials. like any browser can open any protocol (ftp, file etc.. ), not only http/s.
True, the. usage is a bit of an edge case, if you're thinking of Google, facebook twitter and linkedin, as they're the BIG authentication domains. which provide a clear entry point however if you think about the wider use case, like, zoom requires my company account to work, same with outlook, even gmail, may reqiure a non-gmail credential to work. So it's an edge case in the Big world but out of 200+ which i have in my account only 10 of them are in the Google Facebook etc. list.

however, I also agree this is a feature we can surely postpone for a future release. Even more to the point, you don't all have to share my opinion, and if everyone here thinks it's obsolete or not required I would agree as there needs to be consensus.

So in short, I am all in favor of postponing it, but I believe it's a feature which has merit.
your thoughts?

[StanKocken]

A concret example can be a third-party app like Tinder. You can (at least was the case few years ago) use only a Facebook credential. What to do in this case? Tell the developers of this app "you cannot use OpenYolo" or we have to find an alternative solution.
I'm good with the first answer for now, maybe think about the second later?
The way we wanted to do that, as a Password Manager, was to say "This is not the Facebook app, are you sure to provide your Facebook credential".

[iainmcgin]

I think the case you describe for Tinder is actually OK - Tinder can request a credential hint, and specify that it supports Facebook as an authentication method. The user can then select their Facebook account from the hint list, and Tinder uses this hint to begin Facebook authorization for that account. If authorization succeeds, Tinder saves a credential with authentication method "https://www.facebook.com" for future retrieval.

The scope of what @dxslly is discussing is the ability to ask for saved credentials for other apps and domains. The use case I remember discussing with @smarkovik was for an email app to be able to ask for the ID and password for your Google account in order to automatically configure POP3 / SMTP. It is currently the responsibility of the credential provider to decide what to do with such a request:

• The provider must correctly identify that the app does not belong to the Google authentication domain equivalence class. This shouldn't be too difficult, using Digital Asset Links, but it's a likely source of security critical bugs.

• The provider must decide what to do with such a request. In the Smart Lock for Passwords implementation, we ignore any requests for credentials from authentication domains the app is not provably associated to. Others may instead with to display a picker with a modified, scarier prompt to try and make sure the user understands what they are consenting to.

Both steps are a cause for concern, which is why I think that more careful consideration of this feature is required. A different API method for this case, with much more clearly defined semantics, may be better.

[nerdyverde]

I would also be in favour of a cautious approach here. The example of providing Google credentials to an email app definitely highlights an edge-case that users and third-party apps might want supported. Whether it should be supported is something that I think warrants more discussion though, for the reasons that @dxslly and @iainmcgin have highlighted above. With that in mind, I would be happy to see support for requesting disjoint authentication domains removed for now.

[smarkovik]

+1 <http://www.contentsquare.com/> Stanojko Tancho Markovikj <https://data.sigilium.com/signatures/rcevuJOOuCK6-0hyNCIuGCIISRCzQrc/link?element=name> Mobile Engineering Manager <https://data.sigilium.com/signatures/rcevuJOOuCK6-0hyNCIuGCIISRCzQrc/link?element=job> +33 6 51 17 53 54 <https://data.sigilium.com/signatures/rcevuJOOuCK6-0hyNCIuGCIISRCzQrc/link?element=mobile> stanojko.markovik@contentsquare.com 50 avenue Montaigne - 75008 Paris <https://data.sigilium.com/signatures/rcevuJOOuCK6-0hyNCIuGCIISRCzQrc/link?element=map_marker> <https://www.facebook.com/ContentSquareGlobal> <https://twitter.com/ContentSquare> <https://www.youtube.com/user/Weballwin1> <https://www.linkedin.com/company/contentsquare> <https://data.sigilium.com/signatures/rcevuJOOuCK6-0hyNCIuGCIISRCzQrc/redirect_link>

…

On Wed, Mar 1, 2017 at 10:32 PM, Michael Verde ***@***.***> wrote: I would also be in favour of a cautious approach here. The example of providing Google credentials to an email app definitely highlights an edge-case that users and third-party apps might want supported. Whether it *should* be supported is something that I think warrants more discussion though, for the reasons that @dxslly <https://github.com/dxslly> and @iainmcgin <https://github.com/iainmcgin> have highlighted above. With that in mind, I would be happy to see support for requesting disjoint authentication domains removed for now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8OPeIhzydF4WLlCiaHe2I-BIAHNtllks5rheP6gaJpZM4MOtrz> .

[WilliamDenniss]

"The example of providing Google credentials to an email app definitely highlights an edge case"

Actually there is nothing the email app can do with your Google password, we don't allow IMAP authentication via Google passwords (anymore). Such apps need to use OAuth (via OAuth for Native Apps).

[iainmcgin]

The same principle applies to accessing ISP controlled mail servers (e.g. Comcast) and other smaller regional players, though.

Anyway, it sounds like we're all in agreement that we can drop this feature from the spec for the implementor's draft, and reintroduce it later with specific treatment if desired.

[ve7jtb]

For reference it is RFC7628 in combination with Oauth best practices for native apps https://tools.ietf.org/html/draft-ietf-oauth-native-apps (AppAuth is the OIDF SDK name).

Email apps taking passwords is one of the largest security threats we have as it stops people from being able to do multifactor everyware.

Microsoft and apple have proprietary versions of RFC7628 that they support. It would be good to move email apps on to the newer model where they would query for a hint and use that to do OAuth to Google or other Mail provider to get a access token for IMAP/SMTP.

That is the pattern that I prefer to promote.

[iainmcgin]

Code changes to finalize this made in #11.