Re: Proposal for User Agent Augmented Authorization

----- Original Message -----
> From: "Mike West" <mkwst@google.com>
> Hey Sam, this looks interesting indeed!

Thanks for the very helpful comments. My main takeaway is that I have failed to communicate the use cases we are trying to solve. I really appreciate your getting down into the weeds of my proposal; you would have had less work to do if I had put clear user stories up front. I will remedy that.
 
> It's not clear to me how this proposal interacts with the credential
> management proposal I sent out last week. Does the following more or less
> describe the integration you're thinking about, or have I completely
> misunderstood the proposal?

I haven't thought of a specific integration yet, but to be crystal clear: I am not proposing a *replacement* for Credentials Management as you have defined it. It may be that UAA is a vague, handy-wavy, redundant abstraction of what you've so specifically laid out with CM. Or it may be that CM is a one specific path through the general functionality I'm trying to enable. See below.

> ```
> navigator.credentials.request({ federations: ['https://idp1.net/', '
> https://idp2.net' ] }).then(function(c) {
>   // If the user picks a supported IDP, authenticate:
>   if (c && c instanceof FederatedCredential) {
>     navigator.auth.authenticate({
>       authURL: ...,
>       returnURL: ...
>     });
>   }
> });
> ```
> 
> I was hoping that we could find a way to hide some of that magic behind the
> initial call to `.request()`. If the user picks a stored credential from
> IDP #1, it seems like we'd be able to come up with a system that returned
> whatever IDP-specific tokens directly as part of resolving the promise.
> That is, rather than popping up one picker, then resolving the promise,
> returning control to the website, and then popping up some additional UI,
> we could handle the IDP-side authentication process in the browser before
> returning a credential.

"Identity" and "authentication" are coarser, higher-level concepts than "credentials", and HTTP requests are coarser, high-level objects than Javascript promises. Most of all, "user agent" is a coarser, higher-level term than "browser." You are correct that my proposal does not fit the specific CM-in-browser-with-promises flow that you put forth -- it's not meant to. It's also not meant to compete with it :-). We may just need a little time to figure out how they fit together, or nest, or at worst coexist happily side-by-side. Let me add specific user stories to my repo, and then we can both ponder the situation.

> We could, for instance, remove the need for parameters to `authenticate` by
> defining suitable attributes in an IDP manifest, as sketched out at
> http://projects.mikewest.org/credentialmanagement/spec/#identity-provider-manifest

Generally I like the idea of *augmenting* functionality with manifests. I think that *requiring* IdPs to implement manifests adds a hurdle for IdP support, and the benefit ought to match the cost. Since lack of support from an IdP is a "game-over" cost for a chunk of the web, the benefit of requiring manifests ought to be similarly high. Much higher than "removing the need for parameters" seems to me, though maybe I am mistaken. Of course, if we must require a manifest for other reasons, then by all means let's add all the invariant fields we can to them.
 
> -mike
> 
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> 
> 
> On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose <spenrose@mozilla.com> wrote:
> 
> > We think that users could be well served by providing simple ways for user
> > agents and authentication protocols (specifically Oauth, we hope others) to
> > support each other:
> >
> >   https://github.com/SamPenrose/ua-augmented-auth
> >
> > Web apps suffer particularly due to non-http URIs and cookie segregation.
> > We would like feedback on the specific APIs suggested, as well as the
> > overall problem framing. Thank you for your consideration.
> >
> > -- Sam
> >
> >
> >
>

Received on Wednesday, 6 August 2014 17:53:20 UTC