CREDENTIAL: Support 3rd party credential storage and retrieval protocol

[dlongley]

The Credentials CG and Web Payments IG expect credentials to be stored by third party IdPs and the mechanism for fetching them to be standardized.

This doesn't preclude browsers from being IdPs themselves or from simply caching credentials, but there's an expectation that people will want to store their credentials in a way that makes them accessible from a number of different devices/user agents. These credentials aren't simply "login credentials", they may be long-lived pieces of information about them (eg: driver's license, work permits, etc.). Such credentials may have only been issued after a lengthy verification process. It's a very different scenario from "You're using a new browser, so just enter your username and password again and we'll store the credential in this one, too." That approach is untenable for a whole variety of credentials.

Communicating with third party IdPs should be integral to the API. There should be a standardized protocol to allow the browser to communicate with IdPs to transport credentials. If we unify how credentials are passed around, relying parties don't have to use a different SDK and work flow for every possible credential provider. There should be one way to receive a set of credentials and they should arrive in a standard format. The API may not need to support this feature outright to begin with, but it should be listed as future work so that it's clear that it will eventually be built in to the API -- and the current API should be future proofed to support it.

[annevk]

It seems this is largely orthogonal to what this document is about. There's nothing that prevents such a thing from being deployed.

[dlongley]

The current API presumes that credentials are only stored in the browser. The only way around this is to implement a browser plugin. Third party storage support should be, at a minimum, mentioned as desirable in future work.

Assumptions about what credentials are and how they are issued, stored, and used also play into the core design in ways that may limit extensibility. See #256.

[annevk]

No, it assumes they're stored in a user agent, asynchronously. Anything else is out of scope as is normal for API documents.

[dlongley]

@annevk, I believe this is related to #256. I understand that the API simply specifies that the user agent does X and then resolves a promise when it's finished. However, it seems like state management might be an issue when the user agent needs to potentially leave the page to store/fetch credentials.

[annevk]

If the user agent wanted to implement such a model it could do that through a dialog or in the background, no?

[jmajnert]

Communicating with third party IdPs should be integral to the API.

I disagree. This API doesn't need to communicate to IdPs.

[mikewest]

We can future-proof the API to ensure that this kind of thing isn't made difficult/impossible, but it's not something I think we can or should explicitly mandate with normative language in the spec.

Are there API-level requirements here that you're not already covering with the suggestions in #256?

Marking as "future".

[dlongley]

Are there API-level requirements here that you're not already covering with the suggestions in #256?

No, I don't think so, other than that whatever requirements we have for the .get() method, in terms of potentially leaving the page, we would also have for the .store() method. I think we can cover most of this discussion over in #256.

[dlongley]

If the user agent wanted to implement such a model it could do that through a dialog or in the background, no?

It may be better stated that it would be forced to implement it that way if leaving the page isn't possible. Either that or some postMessage/iframe magic (which is how a polyfill would need to implement it, I'd think).