Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should mediation be defaulted at all? #256

Open
marcoscaceres opened this issue Aug 23, 2024 · 6 comments · May be fixed by #258
Open

Should mediation be defaulted at all? #256

marcoscaceres opened this issue Aug 23, 2024 · 6 comments · May be fixed by #258

Comments

@marcoscaceres
Copy link
Member

marcoscaceres commented Aug 23, 2024

While working on WICG/digital-credentials#149 it occurred to me that perhaps we should let mediation be nullable and make null the default - changed my mind... let's remove the default value entirely.

The rationale is that a credential interface determines what its mediation requirements (and could determine its own default value), as per steps 8.1:

  1. For each interface of interfaces:
    8.1 If options.mediation is conditional and interface does not support conditional user mediation, return a promise rejected with a "TypeError" DOMException.

So, for example, for Digital Credential, a missing value (null) could be treated as "required". And the DC API could also define the allowed values in a backwards compatible / extensible way.

The problem right now for DC API is that mediation is always required, so that means every call to .get() must include {"mediation": "required"}, which is annoying from a developer point of view. It should just default to "required" when the credential type is DigitalCredential instead.

@marcoscaceres marcoscaceres changed the title Should mediation be nullable? Should mediation be defaulted at all? Aug 23, 2024
@marcoscaceres
Copy link
Member Author

Ok, so, now that I gave this more thought and drank some coffee.... yeah, dropping the default value entirely and letting the Credential Type determine the default value would be best... if it doesn't provide a default type, it defaults to "conditional".

@samuelgoto
Copy link

Something that occurs to me as I read this is that if we allowed different credential types to pick different defaults, than we would corner ourselves from asking more than one at a time (eg. Which default do you use?).

@marcoscaceres
Copy link
Member Author

marcoscaceres commented Aug 23, 2024

My thinking is that the stronger default applies... the strongest being "required", so if any require "required" it always wins.

In the PR I asked if there was ever a case for any other enum value other than "required" and "conditional". If not, then specs just declare mediation is required and that wins, because UI must be shown no matter what possibly for both.

In cases where mediation is not required simultaneously, then N requests could just be made one after the other.

@samuelgoto
Copy link

In the PR I asked if there was ever a case for any other enum value other than "required" and "conditional".

Isn't optional the other that is most common?

@marcoscaceres
Copy link
Member Author

Yes, sorry, I got confused and thought “conditional” was the default - my apologies. However, the definition of “optional” is still problematic, though the spec does provide guidance:

If credentials can be handed over for a given operation without user mediation, they will be. If user mediation is required, then the user agent will involve the user in the decision.

The issue stands though in that for the DC API, developers would still need to explicitly say it’s “required”.

My recommendation of letting the each credential type dictate its own default stands.

@nsatragno
Copy link
Member

I don't understand how the default mediation is a problem for DC 🤔

DigitalCredential overrides DiscoverFromExternalSource, not CollectFromCredentialStore. Regardless of the mediation parameter, the user is supposed to choose the DigitalCredential interface (in practice, since there's only one credential type, this is done automatically and there's no UI to choose DigitalCredential). Then, DigitalCredential can do whatever it wants with the mediation parameter on its implementation of DiscoverFromExternalSource, including ignoring it.

mediation is only ever treated in credman for credential types that override CollectFromCredentialStore (and in the case of conditional mediation, to avoid returning an error). I don't think this has ever been a problem for WebAuthn, which treats every request as mediation = required unless it's specified as conditional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants