Re: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

Just want to add my voice to the chorus suggesting that there is overlap between what WebAppSec wants to provide using their Credentials API and the focus of the Credentials CG.

Not that Wikipedia is the ultimate authority on all things, but their definition [1] of Credential does seem more closely aligned with the goals of the CG, whereas the Use Cases of the WebAppSec credential are focused on login flows (obviously, this is in the charter of the WG), which aren’t mentioned in the Wikipedia definition. To reduce confusion in the general developer community that both of these groups are addressing, I think it is important that any Credentials API be, at least conceptually, inclusive of a broader use of the term Credentials.

Manu said:

> In the "Future Work" section, the spec suggests that perhaps this API
> could be used to mediate the relationship between people, identity
> providers, and websites. However, all credentials are stored locally in
> the browser, effectively limiting the "identity provider" to a very
> small set of super providers and then cutting them out from being able
> to provide more useful credential data.

I agree that any FPWD needs to take into consideration uses of credential beyond login, and “Future Work” should be consistent with the CG use cases, if not describe them directly. Specific storage may be too narrow a concern, but to the degree that the API is predicated on direct user agent access to this information (as would seem to be indicated by the restrictions on a promise), then the API footprint may need some room for ping-pong like flows requiring a callback.

Mike said:

>  I don't think anything in the proposed API would prevent interested folks from defining
> a `HotNewCredential` type, and offering it to developers. 

This works when there are a relatively few different types of credentials, but the use cases promoted by the CG consider an unbounded set of different credential types. An extension mechanism should probably start from an abstract credential definition, and consider a more strictly bounded login/password of federated login as instances of this.

Wendy said:

> As I see it, the chief inquiry here before FPWD is whether the proposed
> credential management spec in WebAppSec is incompatible with other
> technologies in use or in development, not whether there are bigger and
> greater things that could also be done.

I think the bigger issue is the conceptual space carved out by the use of the term “Credential”, particularly when it doesn’t align with one well-known definition [1].


Brian said:

> From my Outsider position, it appears that there is not a tremendous amount of conflict here.
> There are two groups doing good work that, at a minimum, bump into each other or
> will at least appear to publicly. I encourage the groups to collaborate and perpetuate the
> thoughtful and problem-solving perspective. I acknowledge that will take at least a
> short extra amount of time to find the overlap and opportunities to produce a superior
> set of standards, but I believe it will be worth it.

Big +1

Dave said:

> There are a number of other details, some decided, some TBD, but below are some basic idea
> that I believe need to be known so that we can work together to future proof the Credentials Management API:

> 1. We use Linked Data for extending credentials.
> 2. We expect credentials to be stored by third party IdPs and the mechanism for fetching them to be standardized.
> 3. Once credentials have been authorized, they are typically authorized for use at a particular domain …
> 4. We'll need to consider that "credentials" aren't just "for login".

+1’s, particularly on points 1) and 4).

> As you mentioned earlier, I do think we could resolve these conflicts by renaming the spec to
> "Password Management API". Though, I think changing the name "Credential" to "Identity” would
> still cause conflict with the Credentials CG as we also use that term (something else would likely> 
> be fine). That being said, I agree with Adrian that there could be a much greater upside if we work
> together to make minimal changes to the API and fill out the future work section in the spec with
> some of what the Credentials CG is working on (at least at a high level).

I can definitely see the case for renaming the WebAppSec from Credentials to Login or Password Management, but I think there is a great opportunity to create room for more traditional uses of credentials as envisaged by the CG; this should explicitly provide for an extension mechanism.

Dave also said in issue #256 [2]:

> One possible minimal change to future proof the API would be to make the Credential base class
> more generic and create a new LoginCredential class that extends it. That LoginCredential class
> is then the base class for LocalCredential and FederatedCredential. In the future, there would be
> something like LinkedDataCredential that extends Credential. Then, in order to select which path
> (legacy or future) you want to work with, you include that when making a call to navigator.credentials.get()

+1 create a more generic class of Credential and make LoginCredential a subclass of that; this leaves API space for a LinkedDataCredential (or whatever) that the CG’s work can hang off of without running into technical or conceptual incompatibility.

In summary, I think the publication of the FPWD should be delayed until these issues have been addressed to the minimum degree necessary to allow for the CGs work. As the CG moves to become a WG in it’s own right, there needs to be some way to either hand-off the work at the end of the WebAppSec, or ensure that the spec supports extensions by other specificaitons

Gregg

[1] http://en.wikipedia.org/wiki/Credential
[2] https://github.com/w3c/webappsec/issues/256#issuecomment-93427814

Received on Wednesday, 15 April 2015 18:04:54 UTC