openid/OpenYOLO-Android

Proposal: Disable/Enable credential providers at runtime

dxslly opened this issue · 4 comments

dxslly commented

Goals

  • Disable/enable credential providers at run time
  • Bonus: Allow credential providers to enable/disable based on the calling client

Background

Credential providers declare there capabilities via marked Android manifest entries. Clients discover credential providers by querying for the canonical entries via the PackageManager. For the Save/Hint flows there are no additional "handshakes" and the client will then assume the credential provider is capable of handling their request.

Of course credential providers are free to decide to not handle a hint/save request once it sent, but this is not ideal as it interferes with credential provider choice logic.

Possible Solutions:

1. Enable/disable OpenYOLO components via PM.setComponentEnabledSetting().

Pros:

  • Keeps the spec simple

Cons:

  • Can not filter based on client.
  • Credential providers do not have the opportunity enable/disable in response to discovery.

2. BBQ handshake

Pros:

  • Credential providers are able to enable/disable in response to discovery and can filter per client.

Cons:

  • Complicates the spec.
  • BBQ requests introduce a sizable latency (~2 secs per request is the current timeout)
iainmcgin commented

I think the ability to disable providers at runtime is going to be a short term problem, while OpenYOLO is still not fully baked. That said, providing some guidelines as to how to do this, preferably without changing the protocol, would be wise. I would opt for option 1 from your possible solutions.

StanKocken commented

We did get the same issue on our end. If a user is not logged in, we didn't want to propose ourself as a possibility for save or hint.
But as you mentioned on the option 2, the latency is huge and I don't think it's worth it.
For now I think we are going to handle option 1 by either propose of the user to logged in (but it will break the flow of the third party app) or by just saying "We cannot do that until you logged in yourself".

dxslly commented

It seems worth considering client/spi versioning (i.e. is my client compatible with a given credential provider) when thinking about this issue. The two problems are very similar and may share a solution.

dxslly commented

I believe solution 1: Enable/disable OpenYOLO components via PM.setComponentEnabledSetting(), should be the approach recommended.