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
My requirements for the Manifest for Web Applications
Hi, I am a mobile web developer and have some contributions to make regarding your current draft specification for “Manifest for web application”. My main feedback/concerns is that it is currently as inherently inflexible as the cache manifest file, rendering it useless in many use cases: Specification assumes that the entire app is self contained and requires a consistent display mode Most web apps will have both internal links (to other parts of the web app), and external links to elements outside of the web app. External links often do not contain a route back to the web app, so the preferred behaviour is either for it to a) launch in the web browser, or b) launch within the app, with a navigation element allowing users to return to the web app. Traditionally this has been hacked into web apps using an iFrame. But there are so many inherent problems with iFrames on mobile. Viewport settings permeate through to iframe document (e.g. pinch to zoom setting), width/height, scrolling, gestures, cross browser issues etc etc etc, the list goes on. So I don’t see this as a desirable/suitable solution. I would like to see this specification address this common use case. Specification assumes a simple application in one orientation Many web apps include mixed content, often from third-parties. In some cases, the content is delivered in mixed orientations. Imagine a list of widgets, each widget that can be launched may be better suited in a different orientation. And so it makes sense to allow the web app to define the orientation at any given moment in time, not just on initial load. Specification assumes combined use of cache manifest file? I can’t see any reference to a splash screen / loading sequence control. This is often the most difficult part of a web application. Different media is required based on many variables including device, screen size, browser, locale, language, other more specific variables. The only way to meet these requirements is to use Javascript, and once all of these required resources are identified and sourced can we display the app. The inherent inflexibilities in the cache manifest mechanism mean that it is not used by anyone i know. If your app is large, the cache manifest is too inflexible. If your app is small, it’s too small to need/benefit from a cache manifest. I would like to see this area addressed. How can the web developer ensure a smooth/seamless loading sequence for his/her dynamic web app when updated content is required. Can we determine if the manifest file has taken effect It is unclear to me whether the developer can determine if the manifest has been read, and which parts of the manifest definition have taken effect. This is useful in order to customise content. For example determining if the html is running in a web browser (and therefore no settings have taken effect), so orientation may need to be handled differently. There are other examples for display mode etc. Specification assumes that the content will always be served from the same location Most web apps are versioned. Often the url contains the version number, so many web apps will constantly change base url. Often a url is bookmarked by a user, but this is a redirect to the latest version of the application. In the case of the cache manifest file, this presents a problem, as each new release of the app is cached until the domain runs out of local cache. In this example, I would be concerned that the manifest file would not take effect properly due to the redirect. Will the web page run in the background? Can we request the app reloads every time it is reopened. Can we define whether it should run in the background, or be killed on minimise. Would the Web Audio API continue to play in the background when the app is minimised? Anyway, I hope these questions don’t seem too out-of-scope / noobie. They’re just some of the issues i’ve come across over the last couple of years and I think this is a good opportunity to perhaps address some of them. Regards Mark
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: [selection] Selection.setBaseAndExtent
This doesn't fully cover what setBaseAndExtent() does in WebKit/Blink: as you pointed out yourself, it acts like extend(), which allows programmatic creation of backwards selection by providing a focus (extent) that is earlier in the document than the anchor (base). Your text doesn't cover the backwards case. Borrowing from the spec text for extend() and minus all the links to definitions, how about: void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The setBaseAndExtent(baseNode, baseOffset, extentNode, extentOffset) method must run these steps: 1. Let base be the boundary point (baseNode, baseOffset) and extent be the boundary point (extentNode, extentOffset). 2. Let new range be a new range. 3. If base is equal to extent, set new range's start and end to (baseNode, baseOffset). 4. Otherwise, if base is before to extent, set new range's start to base, then set its end to extent. 5. Otherwise, set new range's start to extent, then set its end to base. 6. Set the context object's range to new range. 7. If extent is before base, set the context object's direction to backwards. Otherwise, set it to forwards. Tim On 5 August 2014 23:51, Ben Peters ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. *From:* Ben Peters *Sent:* Tuesday, May 20, 2014 11:37 AM *To:* Ben Peters; Ryosuke Niwa; public-webapps@w3.org *Subject:* RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 *From:* Ben Peters [mailto:ben.pet...@microsoft.com ben.pet...@microsoft.com] *Sent:* Monday, May 5, 2014 11:28 PM *To:* Ryosuke Niwa; public-webapps@w3.org *Subject:* [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
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: [selection] Selection.setBaseAndExtent
Focus and anchor are different concepts from base and extent. While the former always coincide with start and end, base and extent may be different from those two. In particular, when a user selects text by double clicking on a word, base and extent stays at where the user had clicked while focus and anchor will extend to the beginning and the end of the word like start and end. - R. Niwa On Aug 5, 2014, at 4:58 PM, James M. Greene james.m.gre...@gmail.com wrote: For consistent terminology with the rest of the API, shouldn't it be `setAnchorAndFocus`? Sincerely, James Greene Sent from my [smart?]phone On Aug 5, 2014 5:54 PM, Ben Peters ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. From: Ben Peters Sent: Tuesday, May 20, 2014 11:37 AM To: Ben Peters; Ryosuke Niwa; public-webapps@w3.org Subject: RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 From: Ben Peters [mailto:ben.pet...@microsoft.com] Sent: Monday, May 5, 2014 11:28 PM To: Ryosuke Niwa; public-webapps@w3.org Subject: [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
RE: [selection] Selection.setBaseAndExtent
I don't understand the difference. setBaseAndExtent would then set all 4 of these properties of selection? Do you have a definition to use for this? From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, August 6, 2014 12:43 PM To: James M. Greene Cc: Ben Peters; public-webapps Subject: Re: [selection] Selection.setBaseAndExtent Focus and anchor are different concepts from base and extent. While the former always coincide with start and end, base and extent may be different from those two. In particular, when a user selects text by double clicking on a word, base and extent stays at where the user had clicked while focus and anchor will extend to the beginning and the end of the word like start and end. - R. Niwa On Aug 5, 2014, at 4:58 PM, James M. Greene james.m.gre...@gmail.commailto:james.m.gre...@gmail.com wrote: For consistent terminology with the rest of the API, shouldn't it be `setAnchorAndFocus`? Sincerely, James Greene Sent from my [smart?]phone On Aug 5, 2014 5:54 PM, Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. From: Ben Peters Sent: Tuesday, May 20, 2014 11:37 AM To: Ben Peters; Ryosuke Niwa; public-webapps@w3.orgmailto:public-webapps@w3.org Subject: RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 From: Ben Peters [mailto:ben.pet...@microsoft.com] Sent: Monday, May 5, 2014 11:28 PM To: Ryosuke Niwa; public-webapps@w3.orgmailto:public-webapps@w3.org Subject: [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
Re: [selection] Selection.setBaseAndExtent
For what its worth, we plan to remove base and extent from Blink/Chromium ( https://code.google.com/p/chromium/issues/detail?id=230267). We've found that developers do not understand the difference between focus/anchor and base/extent, and since it is only supported by WebKit based browsers, it is not heavily used. On Wed, Aug 6, 2014 at 12:58 PM, Ben Peters ben.pet...@microsoft.com wrote: I don’t understand the difference. setBaseAndExtent would then set all 4 of these properties of selection? Do you have a definition to use for this? *From:* Ryosuke Niwa [mailto:rn...@apple.com] *Sent:* Wednesday, August 6, 2014 12:43 PM *To:* James M. Greene *Cc:* Ben Peters; public-webapps *Subject:* Re: [selection] Selection.setBaseAndExtent Focus and anchor are different concepts from base and extent. While the former always coincide with start and end, base and extent may be different from those two. In particular, when a user selects text by double clicking on a word, base and extent stays at where the user had clicked while focus and anchor will extend to the beginning and the end of the word like start and end. - R. Niwa On Aug 5, 2014, at 4:58 PM, James M. Greene james.m.gre...@gmail.com wrote: For consistent terminology with the rest of the API, shouldn't it be `setAnchorAndFocus`? Sincerely, James Greene Sent from my [smart?]phone On Aug 5, 2014 5:54 PM, Ben Peters ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. *From:* Ben Peters *Sent:* Tuesday, May 20, 2014 11:37 AM *To:* Ben Peters; Ryosuke Niwa; public-webapps@w3.org *Subject:* RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 *From:* Ben Peters [mailto:ben.pet...@microsoft.com ben.pet...@microsoft.com] *Sent:* Monday, May 5, 2014 11:28 PM *To:* Ryosuke Niwa; public-webapps@w3.org *Subject:* [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
RE: [selection] Selection.setBaseAndExtent
Interesting. I’ve noticed that setBaseAndExtent is used on gMail. Does it work basically like a ‘setAnchorAndFocus’ would (Base/Anchor and Extent/Focus are the same when set with this API, correct)? From: Julie Parent [mailto:jpar...@google.com] Sent: Wednesday, August 6, 2014 4:44 PM To: Ben Peters Cc: Ryosuke Niwa; James M. Greene; public-webapps Subject: Re: [selection] Selection.setBaseAndExtent For what its worth, we plan to remove base and extent from Blink/Chromium (https://code.google.com/p/chromium/issues/detail?id=230267). We've found that developers do not understand the difference between focus/anchor and base/extent, and since it is only supported by WebKit based browsers, it is not heavily used. On Wed, Aug 6, 2014 at 12:58 PM, Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote: I don’t understand the difference. setBaseAndExtent would then set all 4 of these properties of selection? Do you have a definition to use for this? From: Ryosuke Niwa [mailto:rn...@apple.commailto:rn...@apple.com] Sent: Wednesday, August 6, 2014 12:43 PM To: James M. Greene Cc: Ben Peters; public-webapps Subject: Re: [selection] Selection.setBaseAndExtent Focus and anchor are different concepts from base and extent. While the former always coincide with start and end, base and extent may be different from those two. In particular, when a user selects text by double clicking on a word, base and extent stays at where the user had clicked while focus and anchor will extend to the beginning and the end of the word like start and end. - R. Niwa On Aug 5, 2014, at 4:58 PM, James M. Greene james.m.gre...@gmail.commailto:james.m.gre...@gmail.com wrote: For consistent terminology with the rest of the API, shouldn't it be `setAnchorAndFocus`? Sincerely, James Greene Sent from my [smart?]phone On Aug 5, 2014 5:54 PM, Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote: I have added proposed text to this bug. Any objections to this? Proposed text, based on the text for collapse(): void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node extentNode, unsigned long extentOffset); The method must throw an IndexSizeError exception if offset is negative or longer than node's length ([DOM4]). Otherwise, it must create a new range, set ([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, extentOffset), and set the context object's range to the newly-created range. From: Ben Peters Sent: Tuesday, May 20, 2014 11:37 AM To: Ben Peters; Ryosuke Niwa; public-webapps@w3.orgmailto:public-webapps@w3.org Subject: RE: [selection] Selection.setBaseAndExtent I have filed a bug to track this issue [1]. Ben [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831 From: Ben Peters [mailto:ben.pet...@microsoft.com] Sent: Monday, May 5, 2014 11:28 PM To: Ryosuke Niwa; public-webapps@w3.orgmailto:public-webapps@w3.org Subject: [selection] Selection.setBaseAndExtent I noticed that some websites use selection.setBaseAndExtent [1]. According to what limited documentation I could find, it works similar to selection.extend. Is there any intention to standardize this, or is it made obsolete by selection.extend? Ben [1] http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
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:
