Re: Proposal for User Agent Augmented Authorization

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 02:03:10 UTC