Re: Proposal for User Agent Augmented Authorization

Probably a naive comment, but I'm curious and interested in learning since
it's one thing that's been missing from browsers:

Does your last comment mean that you'd be baking in dependency on a certain
auth standard in the user agent? What happens when the part of the
authentication model that is outside the user-agent has a breaking change
but not every website updates to that version? By "augmented" do you mean
it's an additional optional layer?




On Wed, Aug 6, 2014 at 7:02 PM, Sam Penrose <spenrose@mozilla.com> wrote:

> I wrote some user stories for RPs and IdPs with your comments in mind, and
> it feels like I may have taken the initial cut of the API too far from HTTP
> semantics:
>
>   https://github.com/SamPenrose/ua-augmented-auth/issues/9
>
> It also feels like the API and stories need a second protocol, or at least
> a second Oauth implementation, to firm them up. I'm going to look at
> $MAJOR_SOCIAL_NETWORK_FEDERATED_AUTH. If anyone can suggest specific
> HTTP-based protocols to consider*, I'd be much obliged. Expect a revised
> proposal after a couple clock days of work; calendar ETA TDB.
>
> * IndieAuth was suggested here:
> https://github.com/SamPenrose/ua-augmented-auth/issues/1
>
> ----- Original Message -----
> > From: "Sam Penrose" <spenrose@mozilla.com>
> > To: "Mike West" <mkwst@google.com>
> > Cc: "Webapps WG" <public-webapps@w3.org>
> > Sent: Wednesday, August 6, 2014 10:52:52 AM
> > Subject: 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
> > > >
> > > >
> > > >
> > >
> >
> >
>
>