Re: Proposal for User Agent Augmented Authorization

> From: "Marc Fawzi" <marc.fawzi@gmail.com>
> 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?

Great question. My goal is to avoid that category of breakage as much as feasible. Per the comment you were responding to, I'm going to propose that the best way to do that is to stick with HTTP objects (URIs, cookies), but allow the User Agent to augment the result with contextual knowledge unavailable via GET and SET-COOKIE. Expected an updated proposal, and thanks again to all of you who have responded.

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

Received on Thursday, 7 August 2014 23:34:30 UTC