1156047 - (credman) Implement the W3C WebAppSec Credential Management API

Status: NEW

(Core :: DOM: Credential Management, enhancement, P3)

Description

[Axel Nennker]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150403141925

Steps to reproduce:

Implement the W3C WebAppSec Credential Management API
http://w3c.github.io/webappsec/specs/credentialmanagement/

Extend navigator to have navigator.credentials


Actual results:

new api


Expected results:

have navigator.credentials

Initial webidl and implementation is here:
https://github.com/AxelNennker/firefox_credentials/

Comment 1

[Daniel Veditz [:dveditz]]

Note there are a number of open issues with the spec so be prepared to be flexible (or leave the areas with open issues for last):
https://github.com/w3c/webappsec/issues?q=is%3Aissue+CREDENTIAL%3A+is%3Aopen

Comment 2

[Axel Nennker]

New push to https://github.com/AxelNennker/firefox_credentials which is a step forward but ...
Next steps: 
- implement GetParentObject (if it is really needed - if yes what is the parent: contentdocument?)
- reintroduce LocallyStoredCredential
- what about NoInterfaceObject on Credential while being a parameter of store?
  http://w3c.github.io/webappsec/specs/credentialmanagement/#interfaces-credential-manager
- set origin on object creation
- UI
- LoginManager?

Help and advise (Push Requests) welcome.

-axel

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I absolutely think that we should implement this. I'm sure there are problems to solve and I'm happy to help with that, but need someone that's prepared to step up and implement on at least Fennec and Desktop.

Comment 4

[Axel Nennker]

What's needed here https://github.com/AxelNennker/firefox_credentials/ is user consent UI 
Wrapper cache stuff is in the works but I am on vacation now.
Feel free to implement whatever you want next.
Or discuss here if you would like to implement it differently 
Axel

Comment 5

[Matthew N. [:MattN]]

FWIW, I'm not a fan of the LocallyStoredCredential aspect of the spec since it duplicates functionality provided by requestAutocomplete with autocomplete="(username/new-password/current-password)" and didn't seem to be adding value over them last time I looked as the spec (last year). We already have all of the foundation for requestAutocomplete implemented in https://mxr.mozilla.org/mozilla-central/source/toolkit/components/formautofill/

The federated login portions seemed much more interesting as it's something the browser currently doesn't help the user with.

Comment 6

[Anne (:annevk)]

Matthew, could you please file an issue here: https://github.com/w3c/webappsec/issues/new That seems like good feedback to give. Federated login is unfortunately not complete enough to be interesting I think. When I talked with someone from GitHub it sounded like it wasn't really meeting their needs.

Comment 7

[Matthew N. [:MattN]]

(In reply to Anne (:annevk) from comment #6)
> Matthew, could you please file an issue here:
> https://github.com/w3c/webappsec/issues/new That seems like good feedback to
> give.

Done: https://github.com/w3c/webappsec/issues/445

Comment 8

[Axel Nennker]

The current editor's draft moved away from having a method "send" on PasswordCredential but use Fetch instead as described here:
https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch

That would need (I think) a change to Fetch as described here:
https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-4

I am not a member of the W3C's webappsec WG and found no discussion on the public mailing list on this nor in the github issues.
https://lists.w3.org/Archives/Public/public-webappsec/
https://github.com/w3c/webappsec-credential-management/issues

Would you consider implementing this in Fetch? 

Axel

P.s.:

Credentialmanagement is still WIP and I am not sure I like the suggested change:
3.3.4. RequestInit dictionary
Change the RequestInit dictionary’s body member to be of the union type (BodyInit or Credential).
Note: The RequestInit parameter to Request is the only piece of the Fetch infrastructure that accepts a Credential. In particular, neither Response nor XMLHttpRequest's send() method accept Credential objects.

Not everybody needs Credential.type nor Credential.id.
The main feature of this change is to get same-origin protection through Fetch if the body is a Credential and a protection of the password leaking to content javascript and from there to other origins. I would prefer to have a OriginBoundSharedSecret type with fields "secretName" and [[secretValue]]

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Anne, should this be integrated with the fetch spec better before implementing?  I'm not sure I like the current proposal.

In particular, I'm unsure about adding the opaque flag to Request.  That seems a bit odd to me:

1) Its not observable by script so they have no idea they can't call body consuming methods.
2) For Response with have a wrapping opaque response type, but for Request we would have an opaque flag.  This difference seems inconsistent and a bit confusing.
3) This feels like another attempt to add opaque streams as previously discussed.

Also, I find it quite unexpected that any Request containing a Credentials body ends up bypassing the service worker.

I think I would rather see a system where we can mark the Request to automatically get the credential attached as its body.  This attachment would happen at the same time as other cookie credentials.

Comment 10

[Anne (:annevk)]

Any issues with this specification should really be filed at https://github.com/w3c/webappsec-credential-management/issues/new so Mike can have a look.

1) Script did end up passing the PasswordCredential object, but it might be reasonable to expose this somehow.
2) I'm not sure the same concept works here, but maybe?
3) It's definitely similar to opaque streams I suppose.

They could maybe end up in the service worker I think if we keep the opaque flag. Not sure why the service worker is bypassed.

I suppose your alternative system could work with this being a parameter to fetch() only. That could be an interesting approach, although in that case you'd have to bypass the service worker or keep the opaque flag thingie.

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Anne (:annevk) from comment #10)
> 1) Script did end up passing the PasswordCredential object, but it might be
> reasonable to expose this somehow.

Someone handed a Request, like library code, has no way to inspect if they can access the body without triggering an exception with the current spec design.

> I suppose your alternative system could work with this being a parameter to
> fetch() only. That could be an interesting approach, although in that case
> you'd have to bypass the service worker or keep the opaque flag thingie.

The idea is its not attached yet, so there is no need to throw on body access.  Its basically just like trying to inspect cookie credentials, they simply don't show up.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

I'll file my comments on the github repo.

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

I wrote up my thoughts in the github repo here:

  https://github.com/w3c/webappsec-credential-management/issues/11

Comment 14

[Daniel Veditz [:dveditz]]

I have no answers for Axel. webappsec github issues or public-webappsec mail threads are probably the best way to handle it.

Comment 15

[Mike West]

Hi! Glad to see interest in the spec!

@Axel: The conversation that lead to the current design happened mostly on IRC: http://logs.glob.uno/?c=freenode%23whatwg&s=10+Nov+2015&e=12+Nov+2015#c973976. Apologies if that was exclusionary, that wasn't the intent.

@Ben: I've responded to your suggestions https://github.com/w3c/webappsec-credential-management/issues/11. I think we can work something out. I'd appreciate doing so quickly, as we're planning to ship a first pass at the API in Chrome ~51 (https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/E7YWD1KrDQAJ was the intent to ship, with a few Mozilla folks CC'd). We totally have time to make changes, but we're talking to developers who would like to start using this API, and I'd like to reduce the amount of churn they go through in their experimental deployments.