Re: CredentialManagement

> On 5 Oct 2015, at 13:40, Mike West <mkwst@google.com> wrote:
> 
> Hi Henry, thanks for your questions and review.
> 
> On Fri, Oct 2, 2015 at 4:41 PM, henry.story@bblfish.net <mailto:henry.story@bblfish.net> <henry.story@bblfish.net <mailto: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?

Yes, my point was expressed too tersely, and needs a bit more detailed explanation.

The SoLiD (Social Linked Data) project's aim is to write WebApps that could be moved easily from one server to another as long as the server implements some basic RESTful protocol elements ( currently prototypically listed in  https://github.com/solid/solid-spec <https://github.com/solid/solid-spec> ) .  

It would allow the creation of a market for webapps that is orthogonal to a market for servers, meaning that web app writers would be able to have a much larger market to sell their work into. ( From my understanding most WebApps are tied to a particular server at present ).

This is a research project that is trying to push the boundaries of what can be done with WebApps, so it should be a good way of testing the many APIs being developer here. ( This is not tying anyone here to do things that way of course - it's just that one has to choose a path when exploring a landscape )


>  
> 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 <http://tools.ietf.org/html/rfc2617>
>  • Web Signatures
>    https://tools.ietf.org/html/draft-cavage-http-signatures-04 <https://tools.ietf.org/html/draft-cavage-http-signatures-04>
>  • Does OpenID or Auth have similar 401 based WWW-Authenticate methods?


Just to partially answer my own question here, I found something in OAuth about WWW-Authenticate
- OAUth 1.0 http://oauth.net/core/1.0/#auth_header <http://oauth.net/core/1.0/#auth_header>
- OAuth 2 https://tools.ietf.org/html/rfc6750 <https://tools.ietf.org/html/rfc6750>


> 
> 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.

Yes HTTP based authentication as implemented in Browsers today is pretty annoying. The W3C web site used to have this on some protected resources. On those resources popup would open up asking you for identity, and getting it wrong would end up in a long loop with little feedback. It just felt wrong from the UI perspective. 

But as I see it,  by adding JS to the mix one can use HTTP based authentication and get a nice user interface.
This is what I see the Credential Management spec as doing. 

So let's say I download my nice Single Page Application (SPA ) and install it on my server in one click - somehow . My SPA running in my user agent would then fetch data from my server following links and when it found resources that were protected using WWW-Authenticate it could, using Credential Management Level 1 JS API request to find out what password or OpenID identifier the user likes to use, and from there get the Credentials and then authenticate.  The JS could in fact group a number of 401 responses together to make just one request to the user, and so avoid 10s of successive pop ups.

Of course capturing the 401 requests is not something that is left to the Credential Management API but
as I understand is something for the ServiceWorker API

https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/ <https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/>

( They are seeking feedback as posted earlier to this group )

https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0145.html <https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0145.html>

Mind you if I just take the PasswordCredential case, and from a quick perusal of the spec 
http://w3c.github.io/webappsec-credential-management/#dom-passwordcredential-toformdata <http://w3c.github.io/webappsec-credential-management/#dom-passwordcredential-toformdata>
I see that this has a method toFormData which returns an "opaque FormData object".

What would be useful if this PasswordCredential could then be used for the following HTTP Authorisation
response as specified in 
http://tools.ietf.org/html/rfc7235#section-4.2 <http://tools.ietf.org/html/rfc7235#section-4.2>

Similarly it would be useful if one could do the same with either OpenId or OAuth ( assuming their specs are written well enough to enable this )

This would allow one to build beautifully user friendly WebApps that did not need to know what
the structure of the web site was, but to just work with HTTP primitives, the same that other servers could user when connecting to that service.The problem with a formis that each site can have forms at different locations, with different attribute names for the username and password. It also is less resource centric.

I'd rather one use the HTTP primitives where one can.

( So one advantage of a research project like the one we are working on is it really helps tie together how
all these new JS APIs could be used)


> 
> 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.

yes, cross origin would make no sense for PasswordCredentials. Well it make no sense if the JS calling the credentials api is allowed to get to see the password, which as I understand it is not - that's I suppose what is meant by an opaque FormData object.

http://w3c.github.io/webappsec-credential-management/#dom-passwordcredential-toformdata <http://w3c.github.io/webappsec-credential-management/#dom-passwordcredential-toformdata>

It would be worth exploring what the issues are here. I wonder what actually happened in traditional browsers when  a page make a request for a WWW-Authenticate protected resource ( and image ) perhaps on another site. My guess is that the browser asks for authentication. It certainly does for TLS-Client certificates .
So it seems that again if the Credentials Object could be passed to the XMLHTTPRequest object, so that
it was not spoofable by the JS ( assuming this is thought through carefully with CORS ), one could allow
cross site authorized requests. This would allow one SPA to fetch data on remote SPAs without going through CORS proxies. It would mean also that the browser would be more the hub of the web experience.

It requires some more thinking through, but it could help make a big improvement over the current
situation if done right.

>  
> 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' ] } } );` 

Thanks. Is there a registry of such protocols?

>  
> 5) The examples for Federated Credential
>   https://w3c.github.io/webappsec/specs/credentialmanagement/#examples-federated-signin <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.

great :-)

>  
> 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 <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 <http://example.com/>` and `admin.example.com <http://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 <http://google.com/>` and `accounts.google.com <http://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.

To be precise what I wrote there is:
> So here again as with FIDO and cookies, there is pressure from the usability requirements to move beyond a simply syntactic definition of an origin, to one that defines an Origin in a more flexible way as the referent of a set of URIs. 

The key is "simply syntactic definition of an origin"

Your definition is more flexible than the simple JS way of using origins, where the notion of origin is limited to 
only the protocol:domain:port triple. Some people on this list were adamant that this is the only 
way to think of SOP. Clearly there are either two slightly different but equally reasonable ways of thinking of SOP, or there is only one way of thinking of SOP and the other is a reasonable extension.  I am not sure which is the best way to phrase this yet. It would be good to be able to come to consensus on these terms.

I tried to look at this in more detail here:
  https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0244.html <https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0244.html>

I could make this distinction further up in the wiki, and then use those defintions throughout, so it is clearer.

In any case you are in good company with FIDO here.

And of course the aim is not at all to "demolish SOP", but to make sure that notions that you deploy in your
spec such as User Mediation are given the space they deserve to breath, and flourish. My guess is that there is both overwhelming consensus on the notion of user mediation not being incompatible but complimentary to SOP. 

http://www.w3.org/TR/credential-management-1/#user-mediation <http://www.w3.org/TR/credential-management-1/#user-mediation>

Also I want to be sure that we actually agree on the importance of user mediation. Because I'd like to build on that.

One way of thinking of User Mediation, is to think of the User as an Origin. Human users are slow Origins, but that does not mean that they are not an important actor in the web. So the Human is through a User Interface or Policy given to make access control decisions on what other data origins can exchange. Some theory along those lines would help defuse tensions.

> 
> 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.

I have improved the language here to state that "it may seem to go beyond SOP", but it actually does not because of user mediation.

https://www.w3.org/Security/wiki/IG/a_view_on_SOP#WebAppSec_Credential_Management <https://www.w3.org/Security/wiki/IG/a_view_on_SOP#WebAppSec_Credential_Management>

Henry

> 
> -mike