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
> > > > 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
> > > >
> > htt
Re: My requirements for the "Manifest for Web Applications"
Hi Mark,
On August 6, 2014 at 5:22:01 AM, Mark Taylor (mark.s...@base88.com) wrote:
> 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
True for v1 :( Trying to fix this in v2.
> 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.
True.
> 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,
True.
> or b) launch within the app, with a navigation element allowing users to
> return to the
> web app.
True. I guess by navigation element you mean:
1. iframe
2. window.open()
3.
> 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.
Ok, these are either browser bugs or developer bugs tho - so, we have to assume
those will be fixed. But you are correct nonetheless.
> I would like to see this specification address this common use case.
So, part of this is addressed by the "scope" property.
See:
https://github.com/w3c-webmob/installable-webapps/issues/48
tl;dr: it defines what URLs are part of the app (and implies which are not). So:
```JSON
{
"scope": "//foo.com/myapp/"
}
```
So, everything in the "https://foo/com/myapp/"; directory is my app. Open
everything else in the browser.
If you navigate from foo.com/myapp/, to bar.com, then bar.com will have its own
display mode (and you'll be jumping to a new app, if bar.com is installed). If
bar.com doesn't have a display mode, then bar.com is just shown with browser
chrome.
> 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.
Interesting, would like to see some concrete examples of this.
> 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.
This is already supported. As the spec says:
"Once the web application is running, other means can change the orientation of
a top-level browsing context (such as via [SCREEN-ORIENTATION] API). "
Thus, you can change the orientation to whatever the device supports after.
Unlocking returns you back to what is defined in the manifest.
The more serious problem the spec has is that it assumes one particular
orientation for all screen sizes. See:
https://github.com/w3c/manifest/issues/168
Basically, we need to be able to do this to support tablets/phones properly:
{
"orientation": "any",
"some-condition-device-width-or-watevas": {
"orientation": "portrait"
}
}
> Specification assumes combined use of cache manifest file?
>
> I can’t see any reference to a splash screen / loading sequence control.
True about splash screen. We are still debating if we want to support that.
See:
https://github.com/w3c/manifest/issues/9
> 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.
Correct. We are working on various other specs to deal with that. For example,
Resource Hints:
https://igrigorik.github.io/resource-hints/
And Resource Priorities:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
There are other specs in the works too... like Client Hints:
https://github.com/igrigorik/http-client-hints
> 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.
My friend:D you are in luck! let me introduce you to the service worker. It's
everything you asked for and so much more:
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
In the manifest, you will be able to declare a ser
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
> `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
Re: [selection] Selection.setBaseAndExtent
One possible reason for that is that there is no documentation for it anywhere. At least, none that I've ever been able to find, and I'm more interested than the average developer. This goes too for other WebKit extensions such as range.expand(). Tim On 7 August 2014 00:43, Julie Parent wrote: > 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 > 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 >> 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" 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 >> >> >
