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 spenr...@mozilla.com
From: Marc Fawzi marc.fa...@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 spenr...@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 spenr...@mozilla.com
To: Mike West mk...@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 mk...@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
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 spenr...@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 spenr...@mozilla.com
To: Mike West mk...@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 mk...@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 mk...@google.com
Google+: https://mkw.st/+, Twitter
Re: Proposal for User Agent Augmented Authorization
From: Marc Fawzi marc.fa...@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 spenr...@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 spenr...@mozilla.com
To: Mike West mk...@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 mk...@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
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
Re: Proposal for User Agent Augmented Authorization
On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose spenr...@mozilla.com 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/
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 mk...@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 spenr...@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
Re: Proposal for User Agent Augmented Authorization
- Original Message -
From: Mike West mk...@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 mk...@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 spenr...@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
Re: Proposal for User Agent Augmented Authorization
From: Anne van Kesteren ann...@annevk.nl On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose spenr...@mozilla.com 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
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 spenr...@mozilla.com
To: Mike West mk...@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 mk...@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 mk...@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 spenr...@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
