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: , returnURL: , 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"
> > From: "Marc Fawzi"
> > 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 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"
> > > > To: "Mike West"
> > > > Cc: "Webapps WG"
> > > > Sent: Wednesday, August 6, 2014 10:52:52 AM
> > > > Subject: Re: Proposal for User Agent Augmented Authorization
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Mike West"
> > > > > 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
> > > >
Re: Proposal for User Agent Augmented Authorization
> From: "Marc Fawzi"
> 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 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"
> > > To: "Mike West"
> > > Cc: "Webapps WG"
> > > Sent: Wednesday, August 6, 2014 10:52:52 AM
> > > Subject: Re: Proposal for User Agent Augmented Authorization
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Mike West"
> > > > 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
> > > >
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 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"
> > To: "Mike West"
> > Cc: "Webapps WG"
> > Sent: Wednesday, August 6, 2014 10:52:52 AM
> > Subject: Re: Proposal for User Agent Augmented Authorization
> >
> >
> >
> > - Original Message -
> > > From: "Mike West"
> > > 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
>
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"
> To: "Mike West"
> Cc: "Webapps WG"
> Sent: Wednesday, August 6, 2014 10:52:52 AM
> Subject: Re: Proposal for User Agent Augmented Authorization
>
>
>
> - Original Message -
> > From: "Mike West"
> > 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
> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255
Re: Proposal for User Agent Augmented Authorization
> From: "Anne van Kesteren" > On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose wrote: > > 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. > > One problem I have with OAuth or perhaps the implementation thereof by > services around the web is that it is typically all-or-nothing. E.g. > currently I can visit Google Maps and opt to not share my location. > But I cannot login to some services without giving them access to post > on my Facebook wall. > > I guess there is not much that can be done about this other than > encouraging services to provide such granularity. We absolutely should try to encourage granularity! The Chrome identity API for web apps (which I should have cited as influential prior art -- fix coming) allows adding scopes. I created an issue in the repo: https://github.com/SamPenrose/ua-augmented-auth/issues/8 Thanks for the reminder!
Re: Proposal for User Agent Augmented Authorization
- Original Message -
> From: "Mike West"
> 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
> 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 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
> >
> >
> >
>
Re: Proposal for User Agent Augmented Authorization
Hey Sam, this looks interesting indeed!
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?
```
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.
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
.
-mike
--
Mike West
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 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
>
>
>
Re: Proposal for User Agent Augmented Authorization
On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose wrote: > 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. One problem I have with OAuth or perhaps the implementation thereof by services around the web is that it is typically all-or-nothing. E.g. currently I can visit Google Maps and opt to not share my location. But I cannot login to some services without giving them access to post on my Facebook wall. I guess there is not much that can be done about this other than encouraging services to provide such granularity. -- http://annevankesteren.nl/
Proposal for User Agent Augmented Authorization
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
