Skip to content

Document merging get() calls for multiple IDP usage - #351

Closed
cbiesinger wants to merge 1 commit into
w3c-fedid:mainfrom
cbiesinger:merge
Closed

Document merging get() calls for multiple IDP usage#351
cbiesinger wants to merge 1 commit into
w3c-fedid:mainfrom
cbiesinger:merge

Conversation

@cbiesinger

@cbiesinger cbiesinger commented Sep 23, 2022

Copy link
Copy Markdown
Collaborator

@npm1 npm1 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we integrate the changes into the existing processing logic in the spec?

Comment thread spec/index.bs Outdated
even with IDP SDKs that do not cooperate with each other. To make this
possible, the UA has to merge get() calls as follows:

1. If `navigator.credentials.get()` is called before or during onload the

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to clarify this is window onload

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated

1. If `navigator.credentials.get()` is called before or during onload the
UA saves the provided options and delays further processing until
immediately after onload.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear what immediately after means. Microtask/task/something else?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
processing until that microtask.
1. When resuming processing, the saved options from all calls to get are
combined as follows:
1. The provider arrays are concatenated

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if there are repeated configURLs?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
1. <a for=Promise>Resolve</a> |promise| with [undefined] and return |promise|.
</div>

<!-- ======================================================= -->

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting to see this PR being intermingled with the [[DiscoverFromExternalSource]] algorithm, rather than as a separate section.

Should we merge this with that?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be done, please take another look

Comment thread spec/index.bs Outdated
Note: the purpose of having a timer here is to avoid leaking the reason causing this
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we link to load event

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
Note: the purpose of having a timer here is to avoid leaking the reason causing this
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a link for fired? Also not entirely clear what 'currently being fired' means?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is
currently being fired, save the provided options and delay further

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use the variable name. "|options|". Also save it where?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
IDP. It is desirable to be able to show multiple IDPs together in the
account chooser even with IDP SDKs that do not cooperate with each
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Links missing here too

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that
microtask.
1. When resuming processing, the saved options from all calls to get are

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scope of the saving here is unclear since it's not clear where this is being saved...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that
microtask.
1. When resuming processing, the saved options from all calls to get are

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be a new function

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@cbiesinger cbiesinger left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take another look!

Comment thread spec/index.bs Outdated
Note: the purpose of having a timer here is to avoid leaking the reason causing this
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
Note: the purpose of having a timer here is to avoid leaking the reason causing this
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
method to return null. If there was no such timer, the developer could easily infer
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=].
1. If the load event on the window object has not fired yet, or is
currently being fired, save the provided options and delay further

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
IDP. It is desirable to be able to show multiple IDPs together in the
account chooser even with IDP SDKs that do not cooperate with each
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that
microtask.
1. When resuming processing, the saved options from all calls to get are

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs Outdated
other. This and the next step make this possible.
1. Otherwise, enqueue a microtask and delay further processing until that
microtask.
1. When resuming processing, the saved options from all calls to get are

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread spec/index.bs
1. All AbortSignals are saved and if any is aborted, all further
processing is aborted and the account chooser, if any, is closed.
(TODO: What is the desirable behavior here?)
1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0].

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this PR is combining the provider options but then throwing all-but-the-first away in this line?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes... I wanted to decouple this specific behavior of merging get calls from general multi-IDP support. Do you think I should change this PR to cover both?

Comment thread spec/index.bs
IDP. It is desirable to be able to show multiple IDPs together in the
account chooser even with IDP SDKs that do not cooperate with each
other. This and the next step make this possible.
1. [=Queue a global task=] where the global object is the current window

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of things are unclear to me in this PR:

(a) what happens to all of the promises that are in the |all_options| array that aren't picked? Do they get resolved? Failed? I think that, as specified, they never resolve? Is that deliberate?

(b) what happens to the AbortSignals that were passed? If one of the AbortSignals that was passed in the |all_options| gets aborted, does that get ignored?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a): See the paragraph starting at line 1119

For b): See the paragraph starting at line 1124.

@cbiesinger cbiesinger left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam, please see my responses below.

Comment thread spec/index.bs
1. All AbortSignals are saved and if any is aborted, all further
processing is aborted and the account chooser, if any, is closed.
(TODO: What is the desirable behavior here?)
1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0].

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes... I wanted to decouple this specific behavior of merging get calls from general multi-IDP support. Do you think I should change this PR to cover both?

Comment thread spec/index.bs
IDP. It is desirable to be able to show multiple IDPs together in the
account chooser even with IDP SDKs that do not cooperate with each
other. This and the next step make this possible.
1. [=Queue a global task=] where the global object is the current window

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a): See the paragraph starting at line 1119

For b): See the paragraph starting at line 1124.

@npm1 npm1 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm thinking about this more, it might actually be better to have a section for multiIDP that monkey patches the main sections because we are not fully confident on the design here yet and because Mozilla may want to implement the single IDP case like us for now, so having this in the main algorithm might cause some confusion.

Comment thread spec/index.bs
whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without granting permission to share the [=IDP=] account information with the [=RP=].
1. Let |all_options| be a list of pairs of {{CredentialRequestOptions}}
and {{Promise}} objects.
This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally how this is handled is that we add associated members to the relevant object. So here it would probably be "Each Window has an associated allOptions which is initially bla"

Comment thread spec/index.bs
and {{Promise}} objects.
This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}}
calls within the same global object.
1. Create a new promise and append (|options|, new promise) to |all_options|.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be clearer to name the new promise some var.

Comment thread spec/index.bs
a task has already been posted (step after next), return the promise.
1. If the document is not <a spec=HTML>completely loaded</a>, register
an [=event handler=] on the {{Window}} object for the
{{Window/load}} event. When the listener is called, proceed to the

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is just better to add new algorithm as the listener, and that algorithm is actually the 'next steps'

Comment thread spec/index.bs
This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}}
calls within the same global object.
1. Create a new promise and append (|options|, new promise) to |all_options|.
1. If a load event listener (next step) has already been registered or

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could use a boolean to track this more formally.

Comment thread spec/index.bs
task source</dfn> and steps is "go to the next step".
1. Let |options| be the result of running the [=combine CredentialRequestOptions=]
algorithm with |all_options|.
1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0].

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would need to not limit to the first one, and the "potentially create IdentityCredential" would need to allow an array of providers instead of a single one.

@cbiesinger

Copy link
Copy Markdown
Collaborator Author

I made #368 to support multi IDP in general, as a prerequisite for this PR.

@samuelgoto

Copy link
Copy Markdown
Collaborator

Two high level comments:

  • can we add a section with use cases / requirements (e.g. a table with "with vs without gesture" vs "single vs multiple")
  • can we add examples for each of these cases?
  • should we introduce a "mediation" flag to make these use cases more explicit?

I made #368 to support multi IDP in general, as a prerequisite for this PR.

I don't know if we should submit this PR right now.

@npm1

npm1 commented Jan 16, 2024

Copy link
Copy Markdown
Collaborator

This seems outdated and I am trying to clean up open pull requests so I'm closing. If you still wanted to work on this feel free to reopen.

@npm1 npm1 closed this Jan 16, 2024
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 this pull request may close these issues.

3 participants