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

Enforce cross sub domain credential sharing #62

Open
tjwudi opened this Issue Mar 11, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@tjwudi

tjwudi commented Mar 11, 2017

MAY use the Public Suffix List [PSL] to determine the effective scope of a credential by comparing the registerable domains of the credential’s [[origin]] with the origin in which get() is called. That is: credentials saved on https://admin.example.com/ and https://example.com/ MAY be offered to users when get() is called from https://www.example.com/.

I propose we should change the "MAY" to "MUST", so that enforces the implementation of cross subdomain credential sharing.

Reasonings:

  • Many websites breaks themselves into different sub websites each having a sub domain. For sites implemented single point authentication, they usually have a standalone sub domain for that. If user agent doesn't implement cross sub domain credential sharing, this API will not work for those sites.
  • Many websites have a separate mobile site apart from their desktop site, which usually have different sub domains. By enforcing credential sharing across sub domains, user experiences are reinforced because they always get seamless sign-in workflow between desktop browser and mobile browser.
@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 11, 2017

Member

I think it's reasonable to give user agents the ability to make a decision here consistent with their user base and developer feedback. If we end up discovering that every user agent implements this, then turning it into a MUST might be reasonable for passwords.

However, this also depends in large part upon the properties of the credential type that we're talking about. It might not be possible to offer a federated credential if the IDP scopes its permission grant to a specific origin, for example. If we end up moving https://w3c.github.io/webauthn/ into this API as well, that would be another argument against a MUST, as the hardware tokens that spec defines are likewise origin-bound.

Member

mikewest commented Mar 11, 2017

I think it's reasonable to give user agents the ability to make a decision here consistent with their user base and developer feedback. If we end up discovering that every user agent implements this, then turning it into a MUST might be reasonable for passwords.

However, this also depends in large part upon the properties of the credential type that we're talking about. It might not be possible to offer a federated credential if the IDP scopes its permission grant to a specific origin, for example. If we end up moving https://w3c.github.io/webauthn/ into this API as well, that would be another argument against a MUST, as the hardware tokens that spec defines are likewise origin-bound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment