Re: CredentialManagement

Hi Henry, thanks for your questions and review.

On Fri, Oct 2, 2015 at 4:41 PM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

> 1) What browser can I use to try this out? Is there some help for
> programmers on this?
>    That will help me play around, and hopefully answer other questions
> myself.
>

There's a mostly complete implementation in Chrome Canary,
behind chrome://flags/#enable-credential-manager-api.


> 2) In my single page application I don't necessarily want the person
> coming to my site
> to log in immediately. I would like them to be able to play around.


Sure. There's no reason to call the API right away if you don't want folks
to sign in yet. Calling the API in response to a particular user gesture
expressing intent (e.g. a click on a "sign in" button) is an excellent
thing to do in general.


> Even better: it would be nice if my single page application did not have
> to rely on any tie into the server. That is it should be able to help
> authenticate the user with only HTTP mechanims.


I don't understand what this means. How are HTTP mechanisms relevant if
you're not talking to a server?


> So I imagine the SPA fetches resources and some of these return HTTP
> headers requesting a number of authentication methods
>
>  • Basic or Digest Authentication
>    http://tools.ietf.org/html/rfc2617
>  • Web Signatures
>    https://tools.ietf.org/html/draft-cavage-http-signatures-04
>  • Does OpenID or Auth have similar 401 based WWW-Authenticate methods?
>
> The SPA must be able to capture the 401s then call the
> CredentialsManagement API requesting
> one of these options, and then retry the call.
>
>   Is this possible?
>

Anything's possible, but this isn't covered in the current draft.  I'm not
a huge fan of HTTP-based authentication in general (especially as
implemented in browsers today), so this hasn't really been something I'd
considered adding to the spec or to Chrome's implementation.

3) As above, but now the SPA would like to go across origin, and also
> authenticate the user.
>   Is there a way to ensure that a request can be made across origin
> without the SPA getting
>   that information?
>

What does "go across origin" mean? The API currently (and intentionally)
locks the authentication via `PasswordCredential` objects to same-origin
endpoints.


> 4) I have noticed that in the Federation protocol identity services are
> identified by origin. But what if a Identity Provider supports, OpenID,
> OAuth, BrowserID and other authentication mechanims? It seems to me that
> this means that identity services need more than an origin uri.
>

This is covered with the `protocol` attributes. That is,
`navigator.credentials.get({ federated: { 'protocols': [ 'whatever' ] } }
);`


> 5) The examples for Federated Credential
>
> https://w3c.github.io/webappsec/specs/credentialmanagement/#examples-federated-signin
>   show how the Relying Party (SPA) list the providers. I suppose from
> reading the mails its possible that the relying party  be able to accept
> any OpenId provider, to enable people to host their own IDP. But it should
> perhaps be made clearer at that point. There should be a case statement
> which just accepts any URL.
>

Sure, I can add a protocol based example.


> 7) I mention the credentials management in the SOP wiki.
> Let me know if I got something wrong there concerning that
> https://www.w3.org/Security/wiki/IG/a_view_on_SOP


1. "defines an Origin in a more flexible way" seems incorrect. The spec is
quite clear that `example.com` and `admin.example.com` are distinct
origins. The spec has no intentions of demolishing the SOP, and merely
bends its knee to the kinds of usage that we see for passwords in the wild,
where a form submission on one origin "means" signing into another origin
with the same registerable domain (e.g. `google.com` and `
accounts.google.com` is an example near and dear to my heart). Note also
that in no case do credentials cross the HTTPS->HTTP boundary,
registerable-domain match or not.

2. `FederatedCredentials` do not "go beyond SOP". They are, at the moment,
hints to an RP that a particular IDP should be queried to authenticate a
user. The credentials CG does indeed have ideas about other credential
types that would indeed "go beyond SOP", but those are not part of this
draft.

-mike