Re: Proposal for User Agent Augmented Authorization

In response to feedback, I have tightened the purpose of the API to:

  1) making Oauth-based authentication work better for web apps by
  2) augmenting existing redirect and cookie policies so as to
  3) enable single sign on and
  4) enable identity management interfaces in user agents.

To that end, I put forward the following strawman API for RPs:

  - navigator.auth.authenticate(providerOne, providerTwo=null, ...)
  - onSignInChanged.addListener(function(accountObject, isSignedIn=false){})

authenticate() takes a non-empty sequence of objects (one for each IdP the RP wishes to support) holding Oauth URIs:
    
  - {authURL: <string>, returnURL: <string>, interactive: true}

and a third optional property "interactive", defaulting to true (following Chrome's Identity API). If interactive is false, then no login UX will be triggered, and the returnURL will only be called if the user is already signed in. onSignInChanged, also following the Chrome Identity API, MAY be fired by the user agent on sign out.

Here is a strawman API for IdPs:

  - Account = {} // Opaque to user agent; properties per IdP.
  - navigator.auth.getAccounts() // Currently signed in accounts for this IdP.
  - navigator.auth.addAccount(account) // A newly signed in Account.
  - navigator.auth.signOut(accountIdPropertyName, accountIdValue, rpURL=null)

signOut walks the sequence returned by getAccounts looking for exactly one blob with the specified property/value pair. If it is found, then for the optionally specified RP or for all RPs, the user agent should fire onSignInChanged. Note that the user agent can't force the RP to comply, though the IdP can of course invalidate its token.

I have also provided a strawman API for user agent identity management UIs; it seems shakier to me. Expect updates. Feedback welcome via list or:

  https://github.com/SamPenrose/ua-augmented-auth/issues

Thanks,
Sam

----- Original Message -----
> From: "Sam Penrose" <spenrose@mozilla.com>
> > 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 Tuesday, 12 August 2014 05:18:13 UTC